It is time to start a new project. Not only so I have something to work on, but with another semester comes another project. This one is quite different though. Not only is it a group project, it is also a lot more free, but also professional than the previous one.
Not only are we required to have at least one meeting a week, but we also have free choice over game engine, genre, theme, you get the idea. The only thing we are required to include is some connection to the number ten. This project only started this week, so there isn't that much to talk about yet, but I'll explain what we've got so far.
The group
My group (which was assigned to me) consists of four people. We have been grouped up to fill out each others weaknesses, and so everyone can do what they are good at and what they enjoy. For example, coding is my specialty, so I am the main (or rather only) software engineer in my group.
This means that I get free choice over the game engine and some other software. BUT the downside is that because I am the only one with previous experience, I need to do all the version control, too. My group has no idea how version control works, so managing the repository is going to be a major task.
What is version control?
For those that don't know, version control allows developers to revert to any previous state. Every time a new feature gets added, a commit is created. This commit contains all the changes made, so by just redoing the commit, you get the previous version of the source code. There are also different branches, so one person can work on one feature on a seperate branch, while the main branch remains stable and without breaking other peoples code. Once the feature on the seperate branch is done, it gets merged into the main branch. This is also what I will be doing a lot. Merging other peoples changes. Hopefully, the rest of my team will learn how to make good merge requests quickly, so I don't have to do that much work.
The other people on my team don't really have any specialties. One is quite good at art and music, so he will be directing the art production, and the other two will take on the game- and level design. This is of course also a very important job. No matter how good the mechanics are, the game still won't be fun without good level design.
The game idea
It's another rogue like. Why? Because level design is hard.
There will be ten maps (or levels), the player has to fight through. They start off with ten lives. They can take damage from enemies, reducing their health, but retaining their maximum health (this will make more sense in a second).
To fight off the enemies, the player has access to one basic attack. In addition to this, they can unlock abilities. Every x amount of kills, they will be able to pick one of three abilities presented to them. If they pick one, they can assign that ability to one of two ability slots. There is a downside to picking a new ability though. To choose a new ability, the player has to sacrifice one of their lives forever. There is no going back.
This means that if the player picks an ability while they are at 5 health and 8 maximum health, they now have the ability they picked, but are now at 4 health, with 7 maximum health.
This mechanic introduces a tradeoff to getting stronger. The player has to evaluate if the skill is worth losing a life for, or if they want to pass on the opportunity.
Once the player has killed enough enemies, they are allowed to progress to the next map. Beating the tenth map results in the player winning the game.
One proposed idea, to add diversion to the gameplay, is to give each map a unique mechanic/requirement. The player would have to do something else than just fighting, resulting in some change of the gameplay. We didn't come up with examples on what these mechanics could look like yet, but this might develop into a core mechanic, if it isn't too hard to implement and granted that the game- and level design team can come up with ten unique mechanics, as having these feel too similar would achive the exact opposite effect it is supposed to have.
What's going to follow
Just like with my previous project, there probably won't be very frequent blog posts, but devlogs are required for this projet, so they are probably going to be at least a bit more frequent than before. Anyways, that's all I have to write about for now, so I wish you a very pleasant day, and thanks for reading until the end!
Comments
Post a Comment