Posted February 13, 2021 by ProllyEdible
No One Man is the first game that I've created for a game jam. I was surprised by how much I was able to get done in such a short amount of time. When the theme/limitation (power/5 RGB values displayed at 1 time) was announced my first idea was to make a platformer where you lose energy every time you move. I think I may still try to implement that mechanic later on, but given the time constraint I decided to focus on a simpler puzzle mechanic where each action would deplete the character's energy level (which could be recharged via a charging station). I like how this idea turned out. I wasn't sure how combining action points, puzzles, and platforming would work, but I see a lot of potential with this set of mechanics.
I did run into some issues along the way. Creating this prototype highlighted some flaws in the way that I was structuring my Unity projects. My old way of working involved triggering events from scripts on game objects, which works fine if you have 1 of a type of game object (like a level finish) that will be in every level, but for other things like checkpoints or charging stations it meant that I would either need level-specific scripts or levels would need to contain all of the referenced game objects (even if they were unused) because I had scripts that were looking for specific game objects (like: battery01, battery02). I found out after the jam that the way around this is to have a level manager script which acts as a sort of coordination centre for these events. The game object will create a reference to the level manager (which is present on every level) [private LevelManager lm;], which it will assign in the Start method [lm = GameObject.FindGameObjectWithTag("LM").GetComponent<LevelManager>();], and then any methods in the level manager (eg. ChargeOn, which triggers an event) can be triggered from within the game object's script. Any game objects that would've been looking for the battery tile for the event trigger will now look to the level manager for the event instead. This means that the only thing that absolutely has to be in the scene is the level manager, all of the other scripts are now optional and no longer dependent on each other. There may be a better way of achieving this, but right now this method is working really well for me.
I also had a bit of an issue with editing my tiles/sprites. Not really an issue, but the time constraint of the game jam revealed how slow/inefficient my process was. If I changed a colour or needed to make a change to multiple images I had to open up every image individually to make the change. When it came time to recolour the tiles/sprites this meant a lot of manual editing/saving, etc. At first I found that you can automate this process to some degree with Photoshop. You record an Action of you recolouring 1 tile/sprite, then set Photoshop to automate this process on all images in a folder (an optionally its subfolders, which is really handy). This sped up the process a lot, but if an image only used say 3 of the colours and not 5 then the Action would skip a selection step (where I select one of the missing colours) and would fill the entire image with the replacement colour. This meant going in and manually fixing those images, which was pretty time-consuming - especially as the scale of the project grew. Since finishing the jam I've been experimenting with spritesheets and tilesheets. Spritesheets work really well and have sped up my image creation/editing process a lot! Tilesheets in Unity are a bit fucky. I've read that you need to have a gutter between your images, but I couldn't find a way to get this to work. Everything I tried resulted in graphical glitches when the tiles were imported. My workaround for this has been to use the Crop tool in Photoshop. This allows you to split the tilesheet into small sections. You can then export them for web and export all of the tiles in one go. I feel like I can still be more efficient in this area, but for now I'm happy with the reduction in time spent opening/exporting images.
I would have liked to have added more levels to the demo. I feel that if I had not spent so much time editing images and trying to fix the issues with script dependencies I could have achieved this. As it stands tho, I'm very happy with how things turned out with this jam. I feel like I learned an enormous amount over a very short period of time. Aside from a few misplaced tiles and a bug where only the first battery tile in a scene would trigger the animation properly, I feel like I was able to make a fairly polished prototype within the time limit. I've plans to develop this prototype into a full game with more levels, a story, and some more mechanics in the later levels.
Thanks for checking out No One Man,
ProllyEdible
Changes: