Capstone is basically a student’s last hurrah in Champlain College. As a senior programmer, I am currently paired up with two artists, a designer, and a producer as we collaborate to make a functioning vertical slice by the end of the semester in hopes of our game moving on to full production.
As it is the first week, our team’s main goal was brainstorming and getting ideas out in the open. While a lot of things were thrown on the table, we ended up with three base ideas.
The first (and personally my favorite) idea is a Luchador themed 2D fighting game, which would twist a lot of normal fighting game conventions in order to make it more interesting and in order for the game play to line up more with actual wrestling. While this would definitely be very technically challenging, as a pretty big fighting game fan myself I am very much up for the challenge.
The second game idea is a sort of Harvest Moon-esque farming game with some action mechanics as well. The general theme is “Harvest Moon with the mob.” We think it would be a fun, yet darker twist on the farming genre which has such a tendency to be light hearted. How complex this game could get code-wise really depends on what we decide the full features to be. I imagine most time would go into background systems that would involve mafia interaction and actual farming gameplay.
The third idea is a close second to the Lucha idea, we were thinking it would be a 2D platformer where one player plays the “boss” of a dungeon, and they construct a dangerous level for other players to traverse. Then the game would transition to the heroes, as they progress the level that was made for them and try to survive the villain’s traps. This one personally seems like a blast to me, and I imagine technically, a lot of time would go into crafting good tools for the designers to use to make the plethora of rooms players would have to traverse. I also like the idea of the platforming being more combat intensive (think Rogue Legacy).
Right now, both of the artists on our team our 2D specialists, so in order to play to our strengths we will probably go with a 2D artstyle and game. Knowing this, we will most likely be developing in Unity, as it is the engine I’m most comfortable with, and I also think it is an incredibly powerful tool for 2D games.
Another thing I’ve been trying to work on is trying to set some basic architecture for our game. Although we haven’t finalized on an idea, one problem I’ve run into with Champlain game projects in the past is that they are very agile and fast-paced, meaning prototyping is happening almost constantly, leaving very little time to clean up code and construct a stable architecture. While a programming professor already told the class that we would have to bite the bullet sometimes, I’m going to try my best (as I feel most programmers should) to write clean code while producing results quickly. That’s why I decided to use some of the downtime this week to take a head start.
Input System and Messaging System
Knowing that the entire team is hyped about the fighting game idea, I realized it would be the hardest to successfully prototype and prove its intent – which is why I decided to start working on a fighting game – style input manager. The fantastic thing about this is that even if we don’t end up working on the fighting game, the end result is a clean input system that can be re-purposed to whatever other type of game we want.
I started by making a separate input managing class that communicates with the player object through a notification system. I grabbed this handy free to use code here – http://wiki.unity3d.com/index.php?title=CSharpNotificationCenter, and modified it a bit to fit some of the data types I was using.
I set it up so that each player character has an in editor modifiable list of actions they can take. This list of actions is then sent to the input manager so it knows what actions to listen for. This is to provide flexibility to the designer as they choose a character’s moveset or options available to them. It looks a little like this:
These are all actions that are associated with an array of movements. For example Quarter Circle Forward Punch is down, down-forward, forward, and finally punch. In order to distinguish these complex motions from a mere button press, the input manager has a buffer of inputs that all have a modifiable life span. When punch is pressed, it reads through the buffer to see if any of the directions match the order of the pre-defined actions given to the input manager by the player object when the game starts. Once the action is successfully recognized, it sends a message to the player object with the move that was just performed, which at that point the player object can do what it wants with that info.
The great thing about this is that the game starts by pruning the lists of actions to listen for. A player object simply tells the input manager what actions are important to it, and the input manager will listen for said actions and inform the player as they happen.
As I mentioned before, the system I wrote here pretty much accomplishes three goals:
- It’s a headstart on the most complex prototype we are planning thus far (this type of input system is crucial for a fighting game)
- It’s well structured and decoupled code that can easily be used with the other game ideas as we prototype them. The input might not be as complex but it’ll still come in handy.
- It lets me feel comfortable that I have some good game architecture going on before the chaos starts.
That’s pretty much the gist of this first week. I don’t want to dive in too deep without solidifying the ideas, but I wanted to get a head start on making broad systems that will fit in and help all of our game ideas. I might also start modifying the input system I wrote to work with two players, as multiple players are crucial to 2/3 of our main ideas at the moment. I’ll make sure to update the blog with any significant changes to the input system at a later date.