Table of contents
Open Table of contents
Intro
The series of this individual blog is more like a reflection than notes from the development process of our DH2650 game project. I’m at the end of this study period and trying to revisit the learning process and what I have done in our project. Some of them may not appear in our game, I just leave them here as the archive of my thoughts.
Project Team
I took part in production development before, a product trying to use the Unreal engine to render user-customized 3D avatars in an SMS application. I have some knowledge of 3D rendering and 3D game engines, but the situation is a bit different than my previous work experience.
Our project team consists of three artists and two coders, and considering the time constraint and the workload of members, a pixelated and simplified art style is a better choice. The advantage of this art style is obvious, it’s easy to draw pixelated art while keeping most of the expressiveness compared to realistic art, and it’s good for our group to leverage our artistic strengths.
Game Genre
After some ideation, we decide to make a pixelated platformer. It’s a mature genre with a lot of games that we can learn from. From my current perspective, while I think we did a great job and delivered a satisfying demo on Monday’s presentation, I think this is a trade-off rather than a perfect choice.
First, while it’s good to leverage the artistic strengths of our members, it means the gameplay part should be built manually. It’s essential for a platformer game to have different and unique experiences for every level, which means a lot of work on thinking, designing, and testing levels, that requires more than two gameplay designers in a regular production team.
Second, platformer games aren’t the most popular among the team members. I’m the only one who spent hundreds of hours on platformer games like Celeste, Animal Well, Hollow Knight, Death Cell, etc. Hence I mostly worked as the gameplay designer in our team. Other teammates preferred other game genres in their daily plays. In my opinion, it’s a bit risky when the creators don’t play much in the same game genre, which means we might not be able to dogfood our game and test it from the platformer enthusiasts’ perspective.
Luckily, it turns out that for the demo stage, a good art style is more appealing than a nice gameplay experience, our game drew people’s attention with our cute character design, and I’m very happy with that.
Another Good Idea
During the ideation, we came out with a lot of great ideas about game concepts, and I personally resonate with one of them. Although we didn’t choose that direction, I still developed it a bit further, discussed it with my friends, and thought it was interesting. Hence I put it here as my personal reference for the future.
The main story concept is a player-controlled robot sheep escaping from a robot farmer. I think this would be fun because it has the potential to become a new type of Rogue-like game.
Most Rogue-like game has a quite linear game flow. For example, Slay of the Spire is a deck-building rogue-like game, when the game progresses, the player will collect items and cards to empower the character, and then defeat the boss in the late game.
But with the story concept I mentioned above, the game flow can be non-linear: instead of putting the final boss at the end of the map, now the final boss is chasing the player. When the player is collecting items (like a typical choosing one from three in most rogue-like games), the remaining items will empower the final boss. Once the player stops escaping, the final boss fight starts. Now the player needs to balance these two situations: building a powerful items stack, but facing a more powerful boss, or choosing to face the boss earlier to reduce clearance time, but may struggle with the boss fight.
I discussed this with a game designer friend, and he is very excited about this idea. Maybe I’m going to develop further on this idea when I have time later in the year.