Jam's postmortem log (Thoughts and Behind the scenes)

Hello there. I hope you liked the game.

First and foremost, I would like to extent my gratitude towards all the people who played, rated, and/or provided a feedback during the game jam. It means a lot to me to know that this game has reached a lot of people in a few days. I'm also very excited with how the game got ranked in the event

But even if that weren't the case, I'm still happy about how the game came out in the end. 

For that reason, I would like to take this opportunity to share my thoughts on the development of this project, as well as a look behind the scenes. I'm dividing this log on sections as way to sort my thoughts on this, but also as a way for you to look at the parts you'd like to see the most.

The most complete game

I have to confess that this wasn't the first time I've participated in a game jam, or the first time I worked on the development of a game. But out of all the projects I worked on, I feel that this is the most 'complete' one so far.

What I mean by this, is that every project before this were either prototypes of very ambitious ideas where I didn't measure the amount of resources, time, or skills required to carry through, or very minimalist games where I didn't consider the aspects beyond the core gameplay in the case of game jams, like visuals, UX/UI, or sound (most if not all of them didn't even have sound effects).

I think this could've also been the case for this project if it wasn't for one thing: the ARPGE system

I developed this tool prior to this event, and while it had very few features as of this log, I still wanted to put it to test on this project, with the goal of showcasing what it can do with so little, while also thinking that it would save me some time on the logical aspect of the game, giving me more time to work on other aspects.

Looking back at it, I don't think it save me that much time on the code, but going in with that mindset is what drove me to take the time to work on all the aspects of the game, including the sprites, tiles, level design, sounds, music, and even having some spare time to test the game with some friends of mine.

I guess the thing one can learn from this is: having a concrete goal beyond "make a game under a certain amount of time" can help set up a solid foundation for your project; and that it's okay to prepare (or reuse) some stuff if it helps you to achieve your goal. You don't need to create everything from scratch (it took me so long to realize this), in fact, some games out there either use premade assets, or reuse old ones from previous works to create new experiences. 

ARPGE Implementation

As stated earlier, the ARPGE system doesn't have many features at this point. The most it could do was two things: allow you to move entities, and attach them areas that send signals when they interact with another (IBoxes). Suffice to say, I was struggling to find the best use of these few features (aside from making a controllable character).

Before the solution came, the theme of the jam was revealed: Time Travel. Among the ideas that came from the brainstorming session that happened afterwards, the thing that stood out to me the most was the Sandship dungeon in The Legend of Zelda Skyward Sword: a dungeon that changes its layout based on the time period you're in.

So, I went with that idea, and immediately started to work on a prototype with that functionality.

Of course, I also thought that having the ability freely change the layout of the map won't be enough, and have to provide some challenge or incentive for doing it. One of the original ideas I had was to make small actions on the past that will open or close paths in the future; for example, planting a seed in the past that becomes a giant tree in the future and blocks one entrance and opens another (again, this was inspired by Skyward Sword).

In the end, I opted to simply make locked doors to save on time and resources. However, I didn't want to spend time on creating an inventory system to carry keys to open them, so I decided to have them unlocked remotely.

That's how the switches came in!

It may not look like much, but it's actually what allowed me to have more versatility when designing the map in the end.

Fun fact: The end goal is also a switch, and it opens a door that's out of bounds.

Tiles too small

Even at the stage of conception, I decided to limit the game to 3 time periods, as the perfect balance of content diversity for the player, and having a manageable amount of resources to make. I also decided to base their themes on a primary color to easily identify them between each other: Medieval (Green), Modern day (Blue), and Futuristic (Red).

When the time of making the sprites came, I decided to start with the tiles, and went to make 47-piece tilesets... twice (one for the floor, and the other for the walls)... per theme. Needless top say, it took me a long time to finish all of them (a whole day to be precise).

Still, I was satisfied with how they looked at first, and fortunately this approach helped me a lot on the implementation of the more intricate labyrinth design for the final release.

Unfortunately, by the time I started putting other sprites in the game (namely, the character sprites) halfway through the development, I realized I made a big mistake: I miscalculated the size relation between the tilesets and the rest of the sprites, resulting in the walls being way to smaller than what is actually intended.

I didn't want to spend time to properly fix this issue, or simply resize the tiles or rescale the sprites to set the intended approach, so I left it as it is. I think it didn't affect much how the game is perceived in the end, but one of my friends who tested the game made the comment on how one of the tiles looked like a toilet... for some reason.

Quick music production

While this wasn't the first time I made music for a game (I have unlisted projects that have terrible music, in my opinion), I was still worried that this aspect would take long to have it done due to my lack of experience. To my surprise, I finished most of the sound effects and the main theme before the end of the day, with some spare time to fix some issues that came out after the testing.

One of the tools in LMMS that helped a lot through this aspect was the Beat Editor, which is so easy to use, and is very useful for short sequences, which is how I made all the sound effects for this game.

For the background music, I followed the theme of time periods, and assigned two instruments per period that could represent them, while using different note lengths for each one: long piano and organ notes for Medieval, medium electric guitar and drum notes for Modern Day, and short weird wave and whoop sound notes for Futuristic.

Although I think that the sound aspect isn't the best thing of the game, I'm still happy with how it came out in the end, and I feel more confident now on my skills in music and sound composition. So, I guess the lesson here is: don't be afraid to try new things when working on a project; you are better than what you think.

As a side note, I also reused some of the piano notes for the jingles played at the end of both the normal and true endings of the game.

The best came at last

From what I can to tell from the comments and feedback, the labyrinth puzzle design seems to be one of the best aspects of the game, and I'm very glad that people liked it. So, it is my pleasure to inform you that it was implemented at the last part of development!

The initial layout of the map had a more simplistic structure, where the 9 rooms were mostly empty, and the only obstacles were the entrances blocked by time periods or unlocked doors. I originally had plans to fill these rooms with decorations on the last days of development.

However, when the testing period came, a couple of concerns appeared: first, the players were getting lost despite the minimal structure of the map, due to how similar the rooms looked; second, one of the players didn't get the fact that they had to trigger the switches to open the locked doors to progress.

As a solution to the latter, I created the small section in the starting area to teach the players what they have to do to progress, as well as a way for them to safely get familiar with the controls. After quickly implementing it, a burst of ideas came to my mind on how could I design the other rooms with this very same approach. And that's where I realized, I could turn this entire map into a giant maze.

I have to admit that this was my favorite part of the development, because it's where I could focus less on the technical or artistic aspects of the game, and more on the design of the challenge and player experience of it; but also because, in my eyes, it made a better version of the idea I had in my mind.

So, yeah. Always test your games with other people. You never know what your game needs to make it better.

By the way, if you need a map of the entire game: it's already there, you just need to pay close attention ;)

Closing thoughts

Overall, it was a good experience. I put up to test my current skills and learned new ones; I got a taste of what I believe actual game development is like; and it all concluded with a very satisfying end result: the release of my best project up until this point. I'm happy for this.

Thank you so much for taking your time on reading this. I hope it was very insightful and/or informative. Though, I feel like I left out some some information that might be of interest; so, please let me know what other questions you have on this. I'll be glad to answer them.

Also, a big thanks to Vatredox for hosting the Beginner's Game Jam and allowing me to take part of it.

And, once again, thank you so much for playing the game. It means a lot to me to know that there are people who are enjoying my work.

PS: Have you found the two easter eggs I put in the game?