t has been a LONG time since my last Leapfrog development blog. I spent a lot of time between now and then planning and enjoying my trip to the United States, but now I have returned and settled in, I am ready to get back to the project. While I am very early into the project, the time away did give me a lot of time to stockpile a juicy list of ideas on how to tackle all the little issues and ideas I face.
For the past two weeks I have been working on the project slowly and quietly, so let us get stuck into what I have been up to:
Planning:
First of all, I set myself some objectives to achieve within this 2 week period. Just a list of things I would like to work on achieving. I did this by considering what I'd like my minimum viable product to be. In short, this included:
- Creating 8-15 complete levels using my level setting tools depending on individual level complexity.
-Create a range of hazards, with a target of 3.
-Polish the grapple/jump system then add a walking system for micro-adjusting player position.
I was overly ambitious thinking I could achieve everything within two weeks, and honestly spent a while just getting back into the flow of developing after my time away. What I did manage to complete, was 5 levels, the main menu, a simple hazard system, as well as polishing the players movement, walking system included.
Level development:
Naturally, the first step to creating levels is designing them in the first place. The first thing I wanted to do was introduce mechanics one at a time in a simple manner, so my first level teaches players to jump without risk, then makes players take a leap of faith so they can learn not to fear falling (no fall damage), then players have a ledge to hop where the player can fail, so they can learn of checkpoints and hazards. Finally, a jump that requires the grapple to be used is introduced. With this, all the core mechanics are introduced and the player can move on to the next level.
I whiteboarded this level with a pen and paper, but after this I moved to sketching levels digitally. here you can see the level below.
Here are 5 further level designs I created to either teach, a single mechanic, or require the player to apply the grapple in an interesting way. Unfortunately due to software errors, I lost this file, so it's lucky I screenshotted it earlier!
The key is:
black boarder/Brown fill = floor, redline = player path, yellow = hazard & hazard path, skull = killing barrier
Stepping back to the first level, a key issue came up immediately after blocking it out in unity, creating the levels was very difficult because I didn't have a standardised scale to build levels with, the scale was strange. I was just using randomly scaled blocks.
After thinking about how to solve this, I very quickly came to the decision to use a tilemap. Which involved a lot of extra asset development... As time-consuming as it was tedious for me, I created the following:
this however didn't cover all my use cases though so I kept going...
Theeeeeen... I wanted to develop my "above ground" tile set a little better so its not just platforms...
This was a day of work by itself. But it'd save me so much time moving forward, and would result in a better product. Now I know how many tilemap units every jump is, and I can tweak things easier. This, and my asset spawning tool will allow me to make my levels quick and relatively pretty. Though I will ned to spend a lot of time glamorising the cave scenery. I'll show the rest of the levels as they are relevant! But for now let's move on.
Walking:
Now that I have a test level created, I should probably finish the game's base mechanics, with that in mind I created the walking system. It was... incredibly simple. At first, I was thinking about how I'd have to do animations and would have to balance jumping with rigidbody walking velocities...
So to start, I grabbed a pre-made horizontal joystick asset to save myself some time, and then as I typed in "rigidbody2D.velocity" into my player controller I realised: "Oh right! I already have this jumping system, the frog has to move in hops, why don't I just make the walking system a sequence of mini-jumps!"
So here's the script:
While the joystick is being held, a jump force is applied at regular intervals. Thanks to my grounded system, the frog will switch its leg sprite to its jumping state every little hop, making it animate too. The bulk of the work was already pre-made in my player controller.
Look at him go...
Checkpoint Implementation:
With my core systems complete I moved onto creating another level. I used my tileset here to make a simple level. Something smaller and easy to test. This level is where I created the re-spawn and checkpoint system. The red blocks here should reset the player to the start or last used checkpoint.
The checkpoint manager is broken into 3 parts, and this prefab can be placed into any scene.
The manager object stores what checkpoint the player is currently set to.
The Reset Point is where the player will return to when they hit a hazard.
A Checkpoint contains the checkpoint script and has an attached box collider that moves the reset point to this position when it is touched.
Below is the Checkpoint script, attached to each checkpoint and starting location.
Like any checkpoint system, it was important that a checkpoint couldn't be re-set to a previous one, so each checkpoint has an index, and if this index >= the one the manager has stored, the checkpoint will not be updated.
Funnily enough, I never used this checkpoint system in this level because it ended up being too small to justify it.
Hazards:
For the next few levels I wanted to introduce a simple hazard system, in the form of an object that will follow a path, and if it is touched it will reset the player.
These hazards can be seen working below:
A hazard is broken down into 3 parts as well. The parent which is the script holder, it's reference points, and the hazard block.
The reference points define the path the trap follows, and the hazard component holds the sprite and collider of the object.
Currently the script has 2 modes, AtoB motion, where it will go from reference A to reference B and back. Or, Circular motion where reference 1 serves as the circle and reference 2 is used to define its radius.
I also planned to add a track system that can take a list of points and move through them for more complicated paths, but I will not develop this unless level designs call for it. This also goes for the "time between points", where I may want to have points pause after reaching A or B in the AtoB system.
The full script as it is now can be seen below.
With this range of systems, I could simply keep making levels, which kind of puts us where I am today!
Level 4:
Level 5:
From here I just need to keep producing levels. However, I still have a few more things to add. Firstly, my level setting tool: To save myself some pain, I switched the start and end vectors to use object references instead.
This allowed me to make the previously shown level 10x faster, as I had 10 platforms to detail.
Also while it wasn't shown here, I spent a lot of time tweaking the player controller, it was a slight struggle for me to fix, but the player no longer glitches out when grappling in the air.
Finally, I have coded a simple dropping platform that will drop after a set time after being touched. This modifies the collider of what the script is on, so I can create separate tilemaps for platforms and drop them separately. I simply haven't developed a level to use it yet.
Conclusion:
I am glad to be working back on my project, and from here I can keep production going, developing levels and mechanics as they are designed.
I didn't achieve everything I wanted in this short period, but as long as I am working and getting things done I am happy with myself.
Looking at my hack'n'plan, it seems like I just need to better manage my expectations for level design and production. I will list them as individual tasks for the next couple weeks and hopefully this will help me better judge how long these things take.
Sprint 2 Goals:
In two weeks I would like to have:
-7 new levels
-Indicators for what surfaces are hazards
-sprites for the hazards
I am sure many tasks I haven't considered will crop up, but for now these are my main objectives. I will add them to my hack and plan as I go.
With all that in mind, I look forward to my next blog. Thanks for reading! I better get back to work!