Modularity

Modularity is king!

This statement cannot be understated enough when it comes to common programming practices, and even more important when undertaking a project as large and complex as a game. Games are a special case in their own due to all the different interacting systems, and keeping track of them can be a nightmare if not implemented properly. This is where modularity comes in.

Some programming languages have modularity built in, or are entirely based on it. Visual basic is a good example, and right now I'm fiddling around with Visual Basic for Applications, a scripting language built for office apps such as excel. It is very explicit in how it defines modularity. Every piece of code is written in a "module", which usually contain a sub or a function (if it returns a value). There are also class modules where you can write a stripped version of a class to call methods from. VBA unfortunately (and it seems contradictory) does not support inheritance which is a major component of modularity, however there is a way to fake it through interfaces involving the implements keyword, but I won't go into that here.

What I will talk about is the many applications of modularity and how it could improve what our last year's codebase looked like (which was a little messy).

One of the our worst transgressions was overuse of a main game class. Although we had separate systems we dumped a lot of code into the class containing the main update loop. In fact we only had one update loop where everything in the game was being called, and it acted as a universal manager. Too much reliance on a module can lead to a unhealthy dependency that can have catastrophic effects when that one class fails. So how do we improve it?


One way is to separate every game system into its own little environment, where it has its own manager classes that handle the data calculation . The physics system can have it's own update that does the calculation for the next frame, and all data is handled in that specific update loop which would be implemented in a manager class for physics. It can then send the final processed data to wherever it needs to go, for example handing it off to the rendering system to be sent of to the graphics card for processing (using pointers of course, we don't wanna waste time with pointless copying of objects). This is also better for collaborating with multiple programmers. If you can have these subsystems isolated as much as possible, then  multiple people can be working on different things without interfering with each other (this will benefit especially when it comes to sorting out conflicting commits).

Where this really puts a new spin on things is scripting. Now this is still a learning process and I'm still figuring  out how to exactly implement it but I have the high level concept down. There are two variations you can take when it comes to choosing whether to implement scripting. Choosing to code everything in the engine will give you better performance because the code is closer to the core of the game, and doesn't need to be referenced externally. The obvious downside to this, especially when you get to larger projects (as we are this year) that one small change will force you to recompile your entire source code, which can eat up valuable time and leaves little in the way for prototyping and testing.

The other alternative is to include scripting to handle your high level game logic, which will change more as you are reaching the end of your development cycle. Because scripting languages are coded at runtime they are essentially "instantly" compiled and can be run immediately. The benefit is that you can make tweaks and even major changes to upper game logic without needing to recompile the entire engine. The scripting engine acts as the brain and the core engine the body (sort of). The drawbacks though are a loss of performance as this(script) code is "outside" the main engine code, and the engine has to go all the way to the script to get the high level instructions, but again you save the time from having to recompile your entire engine. It is a balancing act of time vs. performance depending on how well you implement it.

For this year's title, I think we will be having a go at implementing a scripting language, could be python, lua, especially with the multiplayer requirement in the upcoming semester. We'll just see if we're up to the task.

Game Concept Overview

A new year, a new start.

Phoenix development studios has been stuck in a rut, so to speak, for the past couple of semesters when it comes to our game design. We found a concept and theme that we've stuck to pretty faithfully, even carrying over the same title. We've had our fill and it's about time to retire The Next Dimension for the time being.

Now this leaves us in an interesting position. Over the summer, some group members had looked into different game types we could approach this year. The first was a tower defense game. At the first the concept was appealing, but upon closer inspection it was concluded that it would simply require the production of too many assets, more than we believe we could handle, and so inevitably it was out of scope.

Then we had an idea, something we haven't done before but are interested in trying. A multiplayer focused party game. The rough idea currently is to have little, simple-designed avatars with a basic melee weapon (something stick-like) thrown into an arena and set to fight to the death. Now where variety comes from are multiple game modes (king of the hill, capture the flag, infection), different skinnable weapons and characters and different arena's with various obstacles. That is the ultimate goal.

What we realised last year is that we have a tendency to overscope. Whether it was the amount of levels, or characters, doing more was detrimental. Now we were fortunate that for Level Up we had a well-functioning
level that we showed off and realized that it was better to have one functioning level than a bunch of useless ones. This led us to setting realistic goals this year which will consist of basically getting skeletal systems implemented well into the controllable characters, getting the basic attack and defense mechanic (and movement) working well, and having a stable game run at a respectable framerate, that can handle multiple players.

Because we are using multiple engines this year, Havok for physics and Ogre and 2LOC for everything else, we feel we can optimize controller input and minimize resulting lag. We are planning of transitioning from SFML's rather slow input handler, to the well established XInput which will also allow for easier controller integration.

Other things that new engines can provide (that we'll need)...

Physics: We'd like to implement rigid bodies and ragdoll like physics into our main characters. When a character hits another and kills them, they will collapse into a ragdoll like pile of meat. We're planning on implementing this with the use of Havok.

AI: Artificial intelligence is going to be one o the most important factors of our game, because it is almost entirely based on player to player interaction. With limited to no networking in the first semester, we need to have a semi-sentient ai manager that can do basic character control and movement that will enable someone who is playing alone to have a fun game experience.

Graphics Pipeline: This year we are using the versatile Ogre engine for rendering and graphics and we hope that figuring it out and implementing it will be outweighed by its uses. It may allow us to prototype faster if we can get it up and rendering quickly.

Networking: Networking will be implemented next semester once core gameplay and AI has been implemented to a stable level.

Input Handling: This year we are planning on transitioning to a much better method of handling, Xinput, which will allow us to better implement external controllers, especially for a multi-person game and have a overall stabler framerate.

Final Thoughts
After going through the first GDW we now know our restrictions and what we are allowed to do. This game will not be split-screen, but rather local multi-screen play. We are not using multiple gameplay elements, like driving, walking, flying but rather multiple game objectives (like ctf, ffa, king of the hill). Overall this year we know we have to have a realistic scope and get solid gameplay first before anything else. It's going to be a fun year :)