So as previously predicted in the last post, the development of new levels has become more difficult, and only increases with each new level made. In this previous sprint just finishing, I had aimed to get to 20 finished levels, however only managed to get to 16. The positive side to this is that all of the new levels are longer and more interesting as they have been made with the new benchmark in mind, and creating interesting puzzles.
While I’d love to show off more of the new levels, we’ll just have give sneak peeks here and there, so you’ll have to see for yourself when the game is out!
Next sprint is to make MORE levels! However due to the rate at which inspiration is accumulated I will also be thinking about other aesthetics such as background colours and UI themes.
This weeks focus was bringing the levels to a new measure of standard, where each will focus on utilising the tools in the environment in different ways. For example on level 1 – where the player needs to learn how to rotate the camera and that red zones bad – it is impossible to complete without rotating in BOTH directions.
The new level one!
Each of the previous levels before this point have either been removed, or upgraded to meet the new standards. Other than using techniques to navigate around levels, as well as taking a certain time to complete. This time is balanced to experienced players, so if I’m able to complete it at full speed under a certain time, the level won’t be long enough and needs to be extended.
Needs more danger
So this week we remade/created new levels and now have 10! 1/6th of the way there, 60 is the target. 10 a week is a good timeframe, but experience tells me the more I make the harder each will become, however this time I’ve set requirements and have a framework to design to, so hopefully the difficulties of the first game don’t re-emerge.
It’s been a week of vast progress! Not only did I manage to fine tune some level transitions, but I changed the ghost behaviour to be far more interactive than previous, as well as wrangling the audio manager into a scalable tool for the dynamic music!
Silky smooth transitions
Firstly achieving level transitions was both easy and tedious. While the code solution wasnt particularly complex, I quickly realised that there are several situations where the function needed to be called from, and nailing down each situation and getting them to behave consistently took longer than expcted.
The world fades away
The next major win of this week was changing the ghost wall behaviour to trigger and complete after the initial collision of the player. Previously a ghost wall would require the player to stay in contact with the wall to continue the fade out process. While the fading out itself wasn’t much of a challenge, the implementation of these walls as a tilemap made things much more finnicky. In the end, I had to essentially access the collision data and multiply by the collision normals (direction of contact), followed by calculating the output position in worldspace, finally using that position to select a cell of the tilemap and editing that instances alpha.
Finally, standardising the audio manager was the most feared task of the week, but rewriting it from the ground up proved to be worthwile and made it more accesible for me to switch out audio on demand going forward.
Next week I will be focusing on proliferating all of the levels and updating the current ones to be a little bit longer.
This week has been focused mainly about the background music that will be present in the game, and while the process has been long, the first round sounded great! While this was only the first pass, it highlighted the requirements of the audio itself, the main points being loopability and duration.
The music is aiming to be dynamic for the game environment, meaning that as a player progresses through each of the levels, the music will advance further, either changing in movement or adding new layers of instruments. Some pretty cool stuff (albeit hard to screenshot).
While the details of the audio are being ironed out, I wanted to at least make some progress this week with a visible, front-end (and screenshottable) feature, hence this cool particle system.
Shiny spirit things?
As you can see above, this particle system creates small particles to fade in, choose a random direction to float in, glow, and then fade away again (the background changes color to show the glowiness here). This brings a factor of liveliness to an otherwise static (for now) world, and thanks to the ruthlessness of Unity’s particle culling, these floaty bits can be spread over the entire world, and hardly tax processing (win win!).
This week has flown by, and this time previous, I was under the delusion of getting at least the background music completed and implemented. This might take a few more weeks, but will make progress in other areas such as SFX and doing something with the background.
This week I focused on fine tuning the presentation of the player, attempting to increase the visual feedback for a player as they traverse the many horrors that await them. The most (percieved) complex of these goals was the use of a shader to dissolve the player away after touching a killzone, and while it started out to be a daunting task that I had little idea on how to tackle, it is one of the most documented effects for 3D models that I could find. After a short time and a minor amount of head-to-desk conflict, the result was quite effctive!
The untimely demise of an unfortunate circle
After overcoming the odds, I was on a roll (ha). Looking into providing the feedback of motion was the next goal, and to that end produced two particle systems that activate after the player was going a certain speed. This helps place the player’s circle in the world and the visually describe the relative speed they are moving at, making it easier to navigate open-design levels. This also provides the secondary effect of warning a player that they may be moving too fast to control effectively.
Gas Gas Gas
We are making progress! Next week, I’ll be looking into implementing an audio manager and providing sounds for audio feedback.
This week I set out to upgrade the visuals of the key components, most notably the bonus objectives (tokens) which now orbit, with a tail renderer as well as a shiny new shine shader.
The old vs the new
I have to admit using unity’s shadergraph is both thrilling in it’s raw power, but on the other hand very difficult to find the resources to make heads or tails of the hundred or so nodes. As using shaders is relatively new in the workflow, I often find myself consuming large swathes of time overcomplicating my solutions to rather simple problems, for example pulling out hair over a simple texture panning shader making several iterations, not realising the issue was external of the graph and to do with the texture wrap setting.
The player sprite got some attention this week as well, with a few new variations to get off to a start, most likely ending with a large variety of choices for the player which they can use their found tokens to unlock.
While the amount of checklist items I was hoping to have an impact on this week didn’t quite make it as far as I’d hoped, its been a great learning experience with the ShaderGraph interface, and the tokens turned out excellently.
Next weeks goal is to finish off the goal-zone shader, and start work on the particle systems for player to world interactions!
Over the past few years, I have been continuing (time permitting) on the development of the next installment of Ready to Roll. While I have been progressing in terms of development of the game, I have done little to document the process, an oversight I hope to overcome here.
I have decided to start recording the day to day in the form of this blog, where you will be able to gain insight into the good, the bad and the spaghetti code I’ve done my best to iron out into a functional project.
The journey so far…
After releasing the first app in 2017, it was clear there were several areas that could be (drastically) improved upon. While the game itself played well mechanically, and the fact that there is yet to be a bug report (yet!), it was painfully obvious that the components outside of the actual gameplay was more than lacking.
Its user interface was blurry and left much to be desired, the token displays and level times were slapped onto a saturated blue background causing the entire main menu to look overly busy and cluttered.
Ready 2 Roll has come a long way since, its main aim to adress the issues of its predecessor, with smoother graphics, optimised code and doing away with the tacky main menu, it should prove to be a sleeker and more refined experience for new and returning players (not that there was a huge amount to begin with).
Previous graphics vs current build
The active development is currently concentrated on the bonus objectives (tokens) graphics, and with a new sprite, shader and particle system, they should be looking good soon!
Hopefully as weeks progress I can continue to not only improve the game but expand my skillset. With a focus on using Unity’s ShaderGraph, I believe I can continue to develop the improved presentation and experience of Ready 2 Roll.
Gravimass is a new spin on the idle game genre where there are no “clicker” mechanics in it. Instead the game systems are presented with a ‘2048’ style game-play in which the player needs to drag same-sized objects together to merge them together.
It has been (and continues to be) great fun to work on this game, especially when it was taken to the Media Molecules Game Jam of May 2017 to work and meet great people. The game is still currently being developed and is not yet available.
Idle Isles is a prototype Idle/Clicker game with an environment where the player can walk around and interact with objects (the norm being a series of contextual menus and clicking on static icons for currency).
The game was uploaded to Kongregate here. (Chrome does not support WebGL by default, information to enable it is here, or use another browser like Firefox)
Ryan Jeans 