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...

2D Engines or 3D Engines for 2D Projects

After spending some time with the development of a 2D game for PC or maybe other platforms I had time to test out some engines that we have access to for free at home or with student licences in school.

For rapid prototyping the Game Maker is the first choice but it has problems with complex mechanics and collusion detection.

Working with Sprites and only 2D objects makes the use of an engine like Unity3D or even the UDK more tedious than helpful because these engines are designed for 3D gameplay and 3D meshes. To tell them otherwise via code is a lot of work and the result is not always desirable. 2.5D on the other hand is more easy to accomplish because the engine already knows how to handle 3D meshes and the "2D gameplay" is possible with some camera tricks.

Using an 2D engine like Torque2D is the better choice for Sprites, 2D objects and 2D gameplay. I am just starting to work with it so I will hold my praises for the moment, maybe it is easy, maybe not...

As for scripting languages most engines today use some kind of c++ related syntax and operators so the switch between different engines is not so difficult, in some cases the code is even transferable between them if not too much engine specific code is being used.

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.