Posts Tagged ‘Keep It Simple Stupid’

C++ and continued work with Unity 3D

Saturday, December 10th, 2011

Hi again!

Some time has passed since my last post as I’ve been quite busy for the last couple of weeks. I’ve also decided to stop calling these updates weekly updates as there is no point in that when they aren’t weekly. It will be better to share things with you when I feel that I have something to share, and I hope you agree. So, in this update I will round up the work that I have been doing with the final C++ course at Blekinge Institute of Technology, as well as my continuing work with Unity 3D.

Wrapping it up with C++

The last two weeks have been spent with wrapping up the last C++ course that I was taking. And this was mainly done with a one week project together with another programming student named Tobias Lundström, who also took the course. Also, fellow game graphics student Kunal Lutra did the graphics besides his other studies, and it looks great. We used Haaf’s Game Engine for the project which is a 2D game engine for C++.

Below I will talk a bit about what we initially planned for the project and what we finally ended up with, as well as a short reflection over how the project went and what I learnt. There is also a short video of the game further down.

Initial idea

During our project we created a 2D Space Shooter named The Reach. Our initial idea was a 2 player split screen co-op game where the first player would control the steering and weapon systems of the space craft on his side of the screen by using standard W-A-S-D for steering, and space bar for shooting.

The second player would have his side of the screen and act as the ship engineer, diverting the ships power between engines, weapons, and shields, but also be able to repair different parts of the ship that got damaged during combat, which in turn would affect how the ships steering operated. The second player would control this by using the mouse, with an overview layout of the ship to quickly be able to give attention to required areas.

By having this kind of co-op in an otherwise ordinary space shooter, the idea was that the game play would be more dynamic and fast paced with the players having to constantly communicate. This would give even more of the pilot/co-pilot feeling where the first player would have his eyes on what enemies the ship was facing and thereby be able to communicate to the the second player if they needed fire power, speed, or protection, depending on the behaviour of the enemy. This would of course also work the other way around were the second player quickly could say which parts of the ship that were seriously injured and demanded that the first player avoided damage in those areas at all costs.

The enemies of the game would behave in ways that took advantage of this kind of system. For example there would be a hard hitting enemy that demanded more power diverted to the shields, and another one which came down really fast and needed to be avoided by moving quickly and thereby diverting power to the engines e.t.c.

Final game

As we quickly realized, the above vision was quite ambitious for a one week project and we were forced to cut a lot of features out because of the short deadline. What we ended up with was the ability to divert power to either the ships weapons, making the ship do more damage, but sacrificing shield protection, and the other way around, using the up and down arrow keys. This made it a singleplayer game, as the ship systems functionality was to simple to really involve another player. Also, we narrowed it down to one one sort of enemy that come in waves, using different moving and shooting patterns, as well as a boss.

During our project I was mainly occupied with programming the player and the ships systems, and Tobias Lundström handled the quite advanced enemy system and did a great job with it. He also handled the programming of most other parts of the project.

Reflection and Learning

I think that the initial idea we had would be interesting to see in a space shooter to make it more dynamic. Unfortunately time caught up with us we had to rethink the idea. This shows how important initial planning of a project is to make a functional game in the end.

Instead of planning a lot of elaborate features and systems from the beginning in a project. I think it is important to learn how to narrow game concepts down and start out small with a core game mechanic that really works before moving on to the next feature. Using this way of developing, you can constantly iterate through the game development process and ensure that a feature is really working and that the game is fun to play before taking on the next feature. The design principle KISS (Keep It Simple Stupid) comes to mind and it can be a very good guideline when designing games.

This will also help you to finish in time without having tons of more things to add before the game works and is fun to play. I also think that this kind of method can avoid stressing the development team out by taking one step at a time, and be able to finish quickly as you are only working on a single feature at any given moment. This is very important to make sure that the team doesn’t burn itself out which otherwise can happen, and I feel that this is often a problem in game development.

If I look at the pure programming aspect of this project I think that I have become more object oriented in mind when I program, moving functionality to different manager classes, like the players movement, shooting system, e.t.c. This is better instead of programming it all in the player class which make it all more complex, cramped up in one area, and much harder to work with. My programming teammate Tobias made me very much aware of this during the project and I thank him for opening my eyes a bit.

Also, since I am not a programmer at the core, but a designer, I think that having worked with another dedicated programmer has helped my communication skills with that certain competence area of game development. It helps you as a designer to better understand the programmers workload during a project and therefore be able to plan your work better, and cut out functionality that you know won’t make it during the given time frame. Knowing other competence areas and what they do and how they work is always important in any development team, and this of course goes for graphics, sound and music, e.t.c. It helps communication and will lead to a better working team.

This project wraps up my two courses in C++ at Blekinge Institute of Technology this year. I have learned a lot and have definitely gotten a better understanding of object oriented programming, how it works, and how to use it. It has not only helped my private programming skills, but as mentioned above, also evolved my communication skills with other programmers, as well as my way of planning.

Unity 3D – Continued work

For the next couple of weeks I will be returning to Unity 3D to learn more about game development using that engine. As you all know, you learn by doing, and I hope that the next few weeks will help me get a better understanding of the engine, as well as being able to continuously work more efficiently with it. My goal is also to be able to apply the object oriented thinking and programming from the C++ courses when I work with C# programming in Unity, and that this will help me further organize and structure my game development more efficiently.

The next time I post I will go more into my continued work with Unity 3D  and how it is proceeding.


Jakob Lindh