For this checkpoint, various features received a bit of refinement. The Title and End scenes for example had their canvas readjusted. (See Gif Below:)
This involved an interesting quirk. I knew I wanted to set the canvas component’s render Mode on my canvas object to ‘World Space’ so to easily position my UI elements (such as titles and level select buttons, etc.), but I found that I had to first set Render Mode to ‘Screen Space - Camera’ and then to world space to make it work the way I expected. This seemed to be like having to invite the UI inside the room, before offering it a place on the couch. The Event Camera setting on this canvas component needed to be set to the Main camera, despite that being the only camera. Unity’s quirks have are plentiful, but the software absolutely falls on the side of convenience when judged overall in my opinion.
Order in Layer on the canvas component was set to 5, just to bring the shiny things (UI elements) out from behind the platform objects I have in the scene.
The result of all the canvas jiggetty wrangling made things easy to re-position where I wanted them. Now my scene would render the way I expected it too, even as an unpredictable WEbGL build. (See images for the ‘before’ and ‘after’ Title scene, and the bonus: ’still in development’ showing that the Triangle enemy has wandered off screen. This actually seemed funny in the End scene, but they did it while the game was running too. In fact, at this point there were still some issues with the all the enemies spontaneously breaking out of their patterns. No this wasn’t burgeoning self-awareness of the ai, but I hadn’t yet attached RigidBody2d components, nor set them to Kinematic …which has now resolved most of these collider issues.
Other user-friendly features implemented over the week included setting up a scene-escape key [0] (zero) to return to the Title scene. A scene reset key [R] was already set-up prior offering players a little control over any bugs that might spring up. These were both originally implemented in the Biscuit Run Player Movement Script, but later I realised that this would mean those functions would be unavailable in the Title and End scenes, because the player objects were not present there. Suddenly another reason of why useful scripts are often attached to empty objects placed arbitrarily (and invisibly) in a scene became bug-judderingly clear. Post feedback session, and the two reset keys are now scripted into the Level Manager object, which is present in every scene already (See screenshot of the code block below).
Polish wasn’t just put on the UI, despite spending another week untangling script issues, I also developed a bit more difficulty incrementing by adding some strategic spikes to prevent some rampant ‘cheesing’ flagged in the previous feedback session, and though the introduction of a couple of asymmetrical challenge scenes. (See images below). Spoiler alert: they were a little bit too difficult for the joyful level advancement I was expecting. Oops!.
Some of the actions taken to improve to the game in terms of playability are invisible, because they were corrections in game behaviour, removing bugs, and researching fixes for little annoyances. Like the ‘freeze method’ …which was randomly failing to actually freeze player input, getting fixed eventually by resetting the frozen bool in a different method (that is called a little later in the respawn transition).
Oh yes, and for full scene control, (and so nobody misses out), I added a button in the Title scene to select the End scene and a button in the End scene to select the Title (Start) scene. Now the level select buttons are complete.
looking great so far. Like the clean simple level select at the start of the game :3
yes the way that it gives you a choice right from the start compared to a separate level choosing scene makes it clear
Yeah, I like games that get on with it, but the control over levels helps with getting feedback and game testing. I can see now why level select is often recommended by teaching staff. Upon viewing the End Scene though
ooh bouncy balls!
I feel like the child whose drawing has just been matter-of-factly reinterpreted by an adult… Those aren’t balls, I mean they are obviously circular, ever so slightly bouncy shapes falling from up-high and interacting in a ball-like manner, but they are not actually balls. They are an abstract, clean, clear simple graphical representation of a random number of delicious biscuits falling from the sky… then being munched into by an enemy Triangle in a particle explosion. And you know what? I ain’t changing them one bit. The basic graphics in this game involved gradual stylistic development that was (at least partly) a conscious choice. …I am only mostly joking here. I do really like the style direction Biscuit Run is taking. Call it nostalgia, lack of skill, or a disdain for using pre-made sprites… I’m keeping it.
…maybe a timer that counts up rather than down would be better if you can select the levels rather than have to advance through them
At the time of the feedback session, I was already pondering a timer that counts the entire playtime (and total respawns), and at the time of writing it has already been implemented, although the total playtime doesn’t currently display, in favour of showing the number of attempts and average attempts per level, etc.
Wow hahaha I really suck at using left and right hand at same time! I think the white collider things got stuck to the right in level two, and my orange player got lost in level three (blue fella just respawning constantly). Love the aesthetic.
This bit of feedback highlighted the buggy enemies, which seem to now all be fixed through applying the aforementioned RigidBody2D components set to kinematic. There was a chart about determining collisions in Unity games and after looking at it, I am surprised that any of the collisions were actually occurring, since most apparently require at least one object involved to have a rigid body component. I suppose in practice the minimum spec for collisions are just colliders …but expect them to be buggy!
The reference to the ‘orange player’ disappearing is most definitely about resetting the player controlled ‘Reverse Gravity’ feature, (which I am yet to have a level built to use it in anyway, despite a several sketches). I thought I’d fixed that by resetting the bool at respawn, but I shall have to further investigate the code.
And I noticed some praise of the aesthetic, which is encouraging me to draw new player sprites that really fits in with the simple design, (or just use the rectangles).
the simple look is good i found it a bit difficult because i had to get used to the controls
Reading this, I am cautious going forward with level difficulty, because I am aware I have played the game enough to be more used to using the two-character controls than the average first-time player.
Surprisingly no new feedback about the use of light and shadowCasters in the last scene. It has actually slowed progress down, partly because of the steps involved applying shadow casters and positioning lights, partly because of the indecision I now have around using it, and partly because it has bogged down the speed of compiling in Unity every time I want to run any scene. Food for thought, since there are at least ten more scenes that could have shadowCasters and lighting applied…
Did you like this post? Tell us
