For now the website is empty, but I will work on beautiful new website and continue to work on The Battle for Eersim. 2014 will be a productive year because of Unity3D and the tools it brings to the table. I hope 2014 will also be a productive year for you!

This is a retrospect of what I called phase one of the development of my action/adventure with the working title The Epic Quest. In this post I will tell what are the goals of this phase, how I am developing for this game and which tools I am using. Inspiration But first what is an action/adventure game for me. Well, the easy answer is games like The Legend of Zelda. This series is the main inspiration for my game. I just love Zelda games. I finished most of them. When I have time, I will play through the few I did not finish. But there are more games inspiriting me like Monster Hunter, Demon - and Dark Souls. Maybe Monster Hunter more then Dark Souls. I player Monster Hunter United for more then 700 hours, maybe even more then 1000 hours. The thrill of killing a big bad monster is what kept me playing this game. The fighting mechanics never bored me. The same for the mechanics of Demon - and Dark Souls. What I find really powerful of Demon - and Dark Souls is the atmosphere of danger. Death surrounds the player every where. Another atmosphere which I find really good was the one of the town of MH3rd on the PSP. It has a really positive relaxed vibe. It was a place where the player could rest. I really aiming to put those kinds of atmospheres and vibes into my game. Functional Document I started working on The Epic Quest in December last year. I did not start with writing code, but started with writing a functional document and the first background story for the game. The functional document is useful for me. First all my ideas for the game are all in one place and online. For this document I am using Google Drive. Sometimes this bites me in the a… because you need an internet connection. Not all trains I take have wifi yet. Still this document is still growing, but there are set borders. So the ideas will only be within these borders. The biggest border is the fixed sizes of the game world. What also puts up borders are the actions the player can do within the game. This is also written down in my functional design. Of course the world itself needs rules. Another set of rules are for the combat. Since combat is a big part of the game and the rules must be clear for me during the development. The rules for combat are an influence for the enemy design. Drawing and Prototyping When most of the current functional design was written, I started making tiles and character animations with Sprite Something. The best thing is what I draw with Sprite Something can be easily be imported by Tiled. So the first map I made was in Tiled. I exported the maps to JSON. I did not use the exported map for a month. When I started using Cocos2d-x I wrote the parser for the JSON with Boost C++ Library. The parser of Boost works well and it works on Android also. I still did not work on the prototype I made for phase one. Requirements All the requirements for the game became more and more clear when I was writing the functional design. Those requirements turned into different test fields. I knew Nintendo does the same for the games they make. Still I never done it before. But the blog post from Kynan Pearson about Metroidvania Style Games pushed me into the direction of making a link of test fields. For each test field I wrote down what was tested and what should and should not happen. This really helped me to find bugs. It is just like I tweeted before, these test fields are the unit tests for games. Now I had the plans for the first prototype on paper. I also used it to review what I made as prototypes. The first conclusion was that map structure from Tiled was not sufficient. I want the map structure to define also triggers, where and which monsters, but also reuse images for tiles and dynamic tiles. With dynamic tiles I mean tiles for a closed door which can be opened. I do not want to code this. Now I can define this within my level structure. The phase one prototype I start working on the prototype on April. I took my time and kept all documentation up to date. But working with the requirement list for each test level kept me focused on finishing this prototype. I start with an iPad version, but after a week I really wanted to work only on my Mac. Cocos2d-x does not come with keyboard support, so I made this possible with a very elegant fix. The keyboard support really boosted the speed of debugging. The best part of the keyboard support is I could release the game when ready on the Mac too. Phase two For phase two I am going to focus on Android, the fighting mechanics and polish what I already made. The prototype is really raw except for the level structure. I already refactored most of the code, but there can always be more refactoring of code. Before I can do all that, I must document the code. So I do not forget how it all works. So there will also be a technical design based on the current code. Of course more information and ideas will be added to the functional design. For example I only defined 1 monster. There will be lots more in the game. So there is still a lot of work to do for me. I hope you enjoyed reading this. Follow me on twitter @smallgaming because I will tweet about what I am doing. And I hope you are making awesome games yourself, if not go try it. You can do it! References http://www.zelda.com http://www.demons-souls.com/ http://www.preparetodie.com/ http://www.capcom.co.jp/monsterhunter/P3rd/ http://terriblegames.com/spriteSomething/ http://www.mapeditor.org/ http://www.boost.org/ http://subtractivedesign.blogspot.nl/2013/01/guide-to-making-metroidvania-style.html

What will The Epic Quest be about? The short answer is: survival and discovery. But so many games are about survival and discovery, so here is the long answer: The Epic Quest (working title) is a single player action adventure. The looks are like the 2d Zelda games, top down view. There will be a non-linear world full with history to discover. There will dungeons to wipe clean and loot to gather. The gameplay involves challenging fights with multiple enemies and big boss monsters. The player will be aided by folk for the right price. Maybe they will drop hints about magical armour and weaponry. Now you vaguely know what this game is about. Keep following this blog for more information about The Epic Quest (working title).

After 3 months I can say One game a month is a great stimulant for building games in the most optimal manner. Also the use of best practises helped me a lot and still is. I am having fun with one game a month and I sold a few copies of Bouncing Alien Pixel. Not bad for a little game which mixes a few classics into one. Also this game was featured on the iTunes store within the Arcade, Action and Game Center sections. For coding this means reuse of code. At the current time I am working on 3 new games which all use the Cocos2d-x engine. Using an not in house made engine saves me a lot of time of course, but the engine did not come with the social media integration I wanted to have. So I wrote a small code base for this purpose. The code is not done yet, but the finished code will ship with the next update of Bouncing Alien Pixel. Also I have to redo a small part of this code so I can use it in on Android also. Another issue which hold back Bouncing Alien Pixel up until now is how collision detection is done. The ball now does not go really fast, well it is fine for beginners. I want to make this game a real challenge for every gamer out there. So I wrote a collision grid which uses the inner workings of a ray caster. This grid really helped with speeding up the gameplay of Bouncing Alien Pixel. The grid will also be used by two upcoming games. Also I could use the grid for all kinds of collision checks within a 2d space. Some of the other code from Bouncing Alien Pixel is also reused by the three games which are in development. Code for settings and saving high scores are all reused without redoing any of the code itself. I did not only wrote games with Cocos2d-x. I wrote two games or tools for helping out my son with his schoolwork and I used Javascript. The first game was to make an easy to use game for learning to read a analog clock. The tool is really easy to use, but the parent must also be actively involved. Since the parent must check the answer and must handle the input. The reason why the parent must be involved is I believe a kid should learn as much from the parents as possible. The parents shows they care about their offspring when the parent is actively involved. The little math tool/game is written with the same mind set as the clock game/tool. Still there can be some improvements to this game. Like an overview of all (in)correct answers after all questions have been answered. It only shows how many correct answers are given. I did use both tools and made games out of them. My son learned his maths and how to read a clock, so for me those Javascript games were perfect. Check my profile of one game a month here: http://www.onegameamonth.com/SmallGaming And remember: "You can do it!!"