Hello all, and welcome to the development diaries of indie game dev company Eipix. My name is Nenad, and in this introductory article I will provide a brief insight into our in-development game ’Fear of Floating’. In the following weeks me and my colleagues will go more in-depth, and cover many aspects of game development process - from game design and art to programming and music. We will share some of our pitfalls and mistakes as well as valuable lessons learned over the course of making FoF. Feel free to interact via comments, and share anything that you might think that you have in common with us..or not.
FoF is a funky mixture of arcade/platform/logic/racing game, meant to be fun and competitive among players in the first place and intellectually appealing (but not too hard) at the same time. The main catch with FoF is it’s unique control scheme (a bit difficult to explain properly, see video to get clearer idea about it, and of course wait for demo coming out this month and try it for yourself).
Control scheme challenges physical abilities of player and I feel that it leans more toward hardcore gamers rather than casual audience. Am I right or not - the time will tell. One of the first problems that we encountered is that game was fun but difficult to embrace. I had to sit down and show people how to play it, accompanied with tons of words and gestures, only to realise that a really good and simple introductory system (read: ’tutorial’) will be a must for the final game. Showing a game to people that are not involved in it’s production is an essential move for every game designer. The best course of action is to put a guinea-pig-friend in front of the game and carefully observe his reactions. Don’t say a word, just stand behind him and sweat. The more often he looks at you the more problems you have in your game. If gets carried away with a game - you are on a good track. Main motivation for introducing 3rd parties to game is gradual losing of objectivity of a game designer. Over time you end up playing your game so many times that you get used to all the aspects of the game, and start losing touch with reality of the game - is it too hard/easy, fun or not, etc. Luckily (or not) one always has some side tasks that gives him few days break from his precious and give a soft reset to saturated experience of the game.
The game started off as an experiment while messing around with Game maker (simple and powerful software most suitable (by my humble opinion) for rapid prototype development). Game maker provided me with quick and easy way to create and polish smooth and fluid motion i was aiming for. As the project grew (in spontaneous and uncontrolled manner) debugging became more and more time consuming. This was the point where we decided to switch over to Torque 2D. Main reason for choosing Torque is it’s multi-platform support and affordability. The real pain began with translating of polished fluid motion from Game Maker to Torque. The same equations in both projects yielded similar results, but different enough to make it a completely different game. After painful tweaking of parameters we were finally there where we were before, but this time - in Torque.
Our first game - Pyroblazer was our pet project, created with no game dev experience at all (and turned out quite good), and more important - without proper planning. Our second game - Ziro was an ultra crunch time project, so we decided to create FoF in more organized way, step by step. The first task (after a prototype was established) was nailing down concept and visual style. You can learn more about it in our upcoming articles.
