Student Project - Post Mortem

It is about a month after the completion of the first student project for the Games Academy. I had some time to think about the whole process and have to say that even on a team with five people work can be hard to coordinate. We had no producer in our team who would try to keep the team together and the project on track and we had no one to try to do that job and the result was that we changed the engine without checking the new one and just because some team members thought that some features were not to their liking. The engine switch resulted in a massive crunch time and some small sparks flying but fortunately we could work out a way to finish a playable version and there were only small difficulties between some team members. They will not work together again but they are not trying to kill each other.

The project itself is playable but not bug free (just like some rushed commercial titles) so we are not really disappointed with it but with better management we could have delivered a better game with all the features we had planned to implement and also without bugs.

It was the first  student project I worked on and even though not everything went according to plan I have learned a lot. In an earlier post I said the the first project is doomed to fail but that was just some students in higher semesters trying to ease our minds. As a matter of fact it was mostly about the teamwork and learning to keep a schedule than really delivering a great game. We managed just that and are content if not happy with it.

In the previous two posts I talked about engines for 2D games and after having worked with Torque2D I have to say that it was a bad decision to switch to it because there are some kinks (or bugs) in the engine that are not really fixed and the whole documentation was outdated and in some cases just wrong. So working with it was mostly tapping in the dark and hoping to find the right command and that the engine logic was compatible to my own. After some research I found out that Torque2D had no real support anymore and that there were two different 2D engine based on the Torque engine and we did choose the wrong one. The other one uses XLA and therefore has a lot of tutorials and is up-to-date but using c# is a little bit more complicated than TorqueScript because it is much more powerful and more object-oriented which could have been a problem for the second programmer (not sure though).

The biggest problem was and always will be communication between the team members. Not just the coordination of work but smaller day-to-day problems that could ruin the working relationship in the long run.

As a conclusion I could say that the next project will be better and that I will not make the same mistakes as before but I have to be realistic and just try to do a better job next time and if something is amiss I will talk to my new teammates...

Student Project - Engines a Plenty

And another game engine to learn and to master...

After having some trouble with imprecise collision detection and too much hassle with gravity on jump mechanics we decided to change the game engine for our student project. Previously we used Unity3D but it being an 3D engine and we wanting to make a 2D game resulted in a lot of headache for all of us but mostly me 'cause I had to tame the beast and failed miserably.

In the beginning of the planning phase there was the option to use the Game Maker but we decided against it because it could produce nice prototypes but making good games with it seemed impossible. A better engine had to do the job. Unfortunately, I decided that Unity would be a good alternative and we ran with it as long as we could before realizing that it was too much for us beginners.

One of our teachers mention another engine that we could use that is more powerful than the Game Maker but not a 3D engine that needs too much fixing. He was talking about Torque2D. So we now try our luck with that engine.

My preliminary tests show that the engine is capable of providing the mechanics we want and that it is manageable to change the engine at our current development stage.

All the artwork has to be resized anyway so the conversion in file type that is needed is not that much of a problem. The scripts have to be rewritten with the new engine code in mind but there were just about 50 lines of code combined so no problem there as well.

Student Project - Progress Report and some Disillusion towards small Projects

The project is deep in production and we are experiencing some difficulties I thought would be avoidable in a project that small and with so few people involved.

Being almost the only one with programming experience was clear for me from the beginning but the amount of work I have to do to get some "simple" mechanics to work properly has me overwhelmed and stumbling at times. Fortunately there is another team member with programming skills that helped out at these times and I could take a step back and reassess the situation.

Another disillusion I experienced was the fact that even in a team with five people work can stagnate and a good "leadership" is needed. I put leadership in parenthesis because it is more the internal communication the team lead lacks as the skill to lead others in the right direction or the right goal. We are all just students at a game design school and we don't know any better. Some students in higher semesters said the first project is doomed to fail and the failure serves as a learning experience for future projects. We joked about it and tried to optimize the concept to avoid any pitfalls and make it a game that we can actually make in the given time frame but with all the courses and now even some exams we somehow lost track of our schedule and have fallen behind. I took too much time to research features of Unity and other interesting aspects of game development.

The idea or vision of our game is clear to everyone but there is no additional game design that everyone knows and that is constantly updated to see the real progress we made so far.

Our project is still a work in progress and I don't know how far we are with the other aspects like level design or graphics because I just lost track of the overall progress but most of the core features on the scripting side are implemented and need to be tested, tweaked and finalized for me to move on to other aspects of the game that need some coding.

The Need to Change my Expectations towards Unity

After working with Unity and trying to implement the core features of the game project I am working on, I have to change my previous statement that Unity is comfortable and easy to work with to an extend.

When I first imported the graphics provided by our artist he noticed that they looked rather bland and there were some lines that he was sure were not in the original files. The files were Photoshop CS 2 files and the importer inside Unity had some problems with them. After some tweaking the colours could be corrected but not the lines, maybe there is an image format that we could use that is imported correctly into Unity but as we are not working with the final graphics too much tweaking would be just a waste of time.

Another aspect of Unity that bugs me a lot is the movement of objects by script. Simple movement in one axis posses no threat at all and is easily implemented but creating a jump, that looks good in 2D and is at the same time "physics confirm" meaning it feels right in the given environment, seemed almost impossible at first and without using a set of external scripts. These scripts are included as a standard package with Unity but I wanted to avoid using scripts that provide functionality that is not needed for the project. Unfortunately it was only possible to achieve a suitable jump movement by using said scripts and add my movement scripts on top of them.

As a conclusion I was to hasty to praise Unity as I did but I learned a lot in the process and will test more before jumping on someone's "band wagon" in the future.

Student Project - Ideas and Engine

After starting my semester at the Games Academy here in Berlin, Germany, I am part of a small team of game design students tasked with a semester long project. The task is to create a game similar to one of four examples:

• Super Mario Bros.
• Micro Machines
• BreakOut
• Xevious

My team has chosen the first one, a platformer similar to Super Mario Bros. The game has to be similar in core game mechanics but with some "unique" features to distinguish it from the original.

As the only one in the team with programming experience I have to choose the engine we use to build the game. I had some prior experience with the Unreal Development Kit  (UDK), but decided against it because it might be too difficult to implement a 2D platformer with it. The second choice was the Game Maker by YoYo Games but I decided against that because I didn't know how to use it right or how to expand the basic features it provided. Finally I tested the Unity Editor and found it easy enough to work with and not to difficult to push to 2D game play.

The Unity Editor is for the engine with the same name and it provides tools to create games for different gaming platforms like the PC, Mac, Wii, iPhone and more. There is a free version that has enough features for most games and there are many tutorials to get started without much headache. The scripting languages used are JavaScript and C#. My preference lies with JavaScript even though I haven't scripted with it before but I used Java and C++ for earlier projects.

The actual project is still in its early planning stages but we are confident that we can get it done in the expected time frame. We are not reinventing the wheel and are able to use assets found on the internet as well as our own so it is possible despite the fact that most first semester projects are doomed to fail.

I might give some more information on the project's progress in future post but I have to check with my team mates first.