Project Summary (Build III)
For this final tutorial in the Peg Puzzle series, we will now extend the level play from the previous tutorial in Build II into a multi-level game which will highlight the extensibility of our Defold game design developed over the past two tutorials, demonstrate the ease with which we can extend the logic within our scripts to accommodate different geometries across these levels – and in the process, develop a game which poses some real challenges to a player. This final tutorial highlights a straight-forward process for readily transitioning from a single-level to a multi-level game.
I: PEG PUZZLE - BUILD III
Our next iteration in building a Peg Puzzle game will be to extend the functions and variable structures within the previous Build II to support multiple game levels, across very different geometries. The following illustration shows the configuration of the pegs and pegHoles for each of the four levels in this final build.
Several quick observations about the peg geometries that will comprise our game levels:
That’s a good starting point for kicking off this description of our approach to expand the variables we’ve used for the number of PegHoles, locations, and hop paths as discussed in Tutorial 2 — to quickly convert to this multi-level design.
Here’s what the final Build III Peg Puzzle looks like:
BUILD III PROJECT FILES
Here’s the full project for Build III within a zipfile. As I recommend in each of our tutorials, go ahead and download/extract the files into a work folder, then open it up using the Defold Editor (v2) in order to follow along with the walk-through of the structure of this initial build.
II: PEG PUZZLE BUILD III: DESIGN HIGHLIGHTS
- MULTI-DIMENSIONAL LUA TABLES SUPPORTING GAME OBJECT LOCATIONS AND POTENTIAL HOP PATHS, BY LEVEL – Working from the one-dimensional tables used for a single game level – this build expands those tables to 2 dimensions to accommodate using ‘level’ as a key index.
- SUCCESS BASED TRANSITIONS TO HIGHER LEVELS– The game is now designed to constrain access to higher (more challenging) game levels – dependent upon successful completion of a previous level.
Build III is a close derivative of our Build II project. All changes to support expansion into a multi-level Peg Puzzle Defold game are going to be constrained to the controller.script and mainMenu.gui_script files. Importantly, the main.collection structure and mainMenu structures remain the same, the graphicAssets and textAssets atlases remain the same and the render, font and module components also remain the same. The next section provides a detailed comparison of the new Build III source code as compared with the Build II (single game level) code.
III: BUILD III: SCRIPT ENHANCEMENTS
At this point, I'm going to modify the scripts developed in Build II to accommodate each of the four geometric patterns that reflect the play levels. You should already have the new script source file available from the previous zipfile you downloaded at the top of this Part 3. To help you better understand them -- I'm providing two things -- (a) a table for each script which highlights the primary new functions...followed by (b) a popup iframe that shows a comparison between the Build II version and the Build III version of each of the scripts.
controller.script
The revised controller.script for this final build of the Peg Puzzle Defold Game performs several important primary functions:
- It sets GLOBAL variables for (1) maximum number of levels, (2) maximum number of locations and (3) maximum number of hop paths
- It defines a new local variable for the location of the empty pegHole at the beginning of play for each of the four levels
- The variable phXCoord is expanded to two-dimensions: [level] and [location]; similarly, phYCoord is expanded as well. Geometries for each of the levels are populated into these Lua Tables.
- Similarly, startingPos, middlePos and endingPos (which define the potential hop paths that a peg can take) is expanded into two-dimensional Lua Tables as well.
- All For/Next loops that iterate through these tables have been modified to accommodate the level index reference
Click the following thumbnail to view a file comparison which highlights each of the line changes made between Build II and Build III. PS: I’m using the online service DiffNow to conduct these script file comparisons – it’s a pretty handy free utility.
mainMenu.gui_script
The revised mainMenu.gui_script for this final build of the Peg Puzzle Defold Game performs several important primary functions:
- A new local variable (remainingPegsToPass) is declared – which defines how many pegs must be remaining on the board to consider the player to have passed that level. Note – these can be adjusted to either make play easier, or harder.
- All For/Next loops that iterate through each of the levels have been modified to reflect the global variable NUM_LEVELS
- Logic has been included to determine if a player has passed a level – aka, is now able to play the next level in the game
The following file comparison highlights each of the line changes made.
That’s it – really not that many modifications required – the most difficult aspect was probably working through each of the x/y coordinates for the peg holes in each of the level scenarios and also determining each of the possible hop paths that would need to be evaluated.
IV: COMPLETION OF PEG PUZZLE
Whew – we’ve covered a lot of ground, but hopefully, the structure of the Defold game project and the three step approach made sense. The Peg Puzzle isn’t quite a market-ready product – but it gets close.
I hope the abbreviated descriptions during this three-part tutorial made it easier to digest all the material. If you think I should add more detail related to any piece of this tutorial – or if you have a question on how it works — please drop me a note in the comment box below. I’ll get right back to you. Also – please let me know if you find these tutorials helpful. I look forward to your feedback.
All the best - Dave
Go to Part 1 Go to Part 2 Go to Part 3