This past week has been quite busy in terms of work on Live, Die, Escape. I have been spending lots of time building up reliable systems for the game to be built on top of. Unfortunately, some of these concepts are a bit boring and not as exciting as things like new items, levels and rooms, or new enemies. However, I would like to make this post to talk about some of what I have been working on and the design choices that went into making them.

State Machines

A big part of what I have been working on, as is common in many games and applications is state machines. This is such a versatile design pattern that can be used in so many places throughout a game. Since I have just started rebuilding the game based on the prototype, the first entities I have added to the game are the player and the laser turret. Both of these are built with state machines.

The player currently has 3 states: Idle, Walk, and Run. These are pretty basic, and will likely be expanded upon in the future. They are pretty self explanatory, so I won't bore you with the details. But let me just say, using a state machine design is so much easier and more efficient for developing and debugging features once you have the base system down. It took a bit to get there, and I went through several iterations. Originally, I wasn't sure what the states should include. I had each state have it's own rigidbody, collider, sprite, etc. Looking back, this may have been a little bit of a silly approach. But I still enjoyed the process of figuring it out. Now, the player has one of each element that it is composed of, and the states live on different nodes, which simply access and control these elements depending on if they are activated or deactivated.

The laser turret works in a similar way. It has 3 states as well: Idle, Priming, and Activated. I decided to add the priming state to the previous design for the laser turret because I believe it gives the player more useful feedback on when the turret will be activated. If you are in a dangerous situation, you have a better indication of when the laser will turn back on. Each state also has it's own animation (of course), and I'm really liking the laser turret animations right now, I believe they are very cute.

I realize that the game as a whole should also be made up of a state machine, but at the moment that isn't how it operates. I like to think that I won't need to implement something like that, although I may be proven wrong and have to change a whole lot later down the line. Let's hope that doesn't happen :)

Art

I'm redesigning the sprites as I go. I currently have created a player character as well as a better sprite for the laser turrets.

For the player I thought that it would be cool if you were an alien with 4 arms. I iterated off of this with the idea that your inventory will have 4 slots, one for each hand. Whether or not the items will appear in the player's hands is currently up in the air, but I think it would be cool. I have to experiment more with how it looks. The player may undergo some redesigns due to the fact that I  have been told it's hard to tell that it has 4 arms. The clothing is a jumpsuit, inspired by prison jumpsuits. (This will be relevant to the story.)

The laser turret has been simplified as well. As I mentioned in a previous devlog, these turrets are inspired by the laser turrets in Portal. I really like the design of them and I think the functionality they have is very useful to the kind of environment I'm trying to create in my game.

I've decided to go with a lower resolution pixel art for this game as I feel it better suits my styles of art and development. It also makes it slightly easier to pump out sprites and animations faster.

Levels

Like many games of the top-down and puzzle genres, I have decided to go with a level-organized game. Each level will consist of a few rooms, and failing that level (dying) will reset the level. This seems like a good fit for this game, although I am still unsure of how level traversal and save points will work. I want the player to be able to go back to previous levels and rooms if necessary, while still having clear divides in the game for difficulty and progression. It is possible that I will get rid of the level system and simply have save rooms to save the entire state of the game and all rooms. When you die, you would revert to the previous save state. This is also a pretty standard design, but I am unsure about which system to go with. If you have any thoughts on this design, let me know in the comments! Which might be a more enjoyable experience for the player, and how can balance be achieved between these different traits?

Game Access

Currently, the version of the game still up is the prototype, and is not the version that I am working on. While I am still always hoping that people will play the prototype if they want to, please keep in mind that it is wildly out of date. I am not sure when I will have a playable version of the game ready, but do expect to be able to play the game before it is officially released. This minimum playable version will hopefully be up within the next few weeks.

Conclusion

Thank you for reading this devlog! As always, I'm really enjoying the process of making this game as well as these devlog posts. I hope to post another one at the end of this week. It seems to have been easier for me to make these posts on the weekends rather than Fridays, so expect that from now on. Feel free to leave any feedback in the comments and I hope to see you next week!

Calvin