What you shouldn’t do to make your own game
I worked in at least 6 medium sized or big projects, but a lot of them did not had success.
The first title that I’ve participated was the “Jogo da Cidadania”, which was planned to use Macromedia Director as platform. That was the first mistake, the use of a high level technology to make a complex game. We coded the game in Shockwave but it had a terrible performance and was incompatible with a lot of PCs. Even with two months of optimization, the results were very bad. He had to make the shockwave to do miracles and we detected a lot of bugs and undocumented features, and the game still bugging on other PCs.
- First learned lesson: do not use uncommon technologies for games. If you intend to publish, use something that works.
The second game was “Kyros” while I was working at Eleven Cells. On that project I learned by the hardest way that projects and documents are essential to deliver a game if you are not working all by yourself. The game lost control of its features and we were coding random pieces of the game that generated a lot of rework. Other thing that made the game conclusion to be delayed and cancelled was that we used a FPS framework to make a 3rd person fighting game.
- Second learned lesson: Do not get out of the road. Make a document with the game design or goals and get stuck to it.
- Third learned lesson: Do not use frameworks of other purpose for your game. If you don’t have a framework for your style of game, then is better you create it from the scratch than using a half related framework with your game further if it haves millions of lines of code.
The third game was the “Evolução” for Abdução. This game was very well conceived and had tons of documents of design and game design. The team had a amazing leader and they were using a great engine (GameBryo). The game was scripted with a stackless version Squirrel and ODE for physics. They used Maya as tool for 3d. The project got a little bit delayed but wasn’t a big deal.
For me this project is my reference as a game project, except by the fact that the investing company didn’t published the game (yet). I hope that the company decides to publish it, the game is amazing and it was a nice piece of work.
- Fourth learned lesson: If you are making a project for another company, do not create expectations on the publishing.
The fourth and fifth projects are projects that I made at spare time. The fourth was to be a game using my middleware (Sphi), but I was being compulsive and didn’t finished the middleware. I got out of focus and probably the framework would grow forever and finally loose its simplicity and usability.
- Fifth learned lesson: If you are making a framework or a middleware, do not code things that you won’t use. Always code just what you need and at the simplest way, even if it looks ugly and do not use any design pattern.
The other project still running. I’m coding the game that I intended to code on Sphi framework without any big framework. I’m using HGE with Chipmunk, and made the code on the simpler way that I could make, it is almost mediocre. This mediocrity made the GUI implementation a pandemonium.
- Sixth lesson learned: Simplify the things but do not make it to be mediocre. This can bring problems for the whole solution with thousands of small WOPs. A drawing or a class draft is always useful.
I hope that my mistakes could help someone someday somewhere.