Fledgling Videogame Developer

Here are some general guidelines that should help to get your first gamedev projects proceed, and even completed in a reasonable time. 0. Prepare to sacrifice your time and effort Ok, you have idea for a game. But are you ready to make the effort to implement it? If you want to get your ideas ready, most likely you got to do it yourself. No one else will do it for you. 1. Start with something small and simple.  If your first game project is large and complex, you probably won't finish it. 2. Select an engine that fits to your game.  There is no need to shoot birds with cannon. Try different engines and use the one that fits for your purposes. 3. Create lots of prototypes and small games.   Select the ones that work for further development. Gather experience on suspended and unfinished projects.  4. Test the mechanics in early phase.  Find out if game mechanics is working as soon as you have working prototype. Try to define game's "fun facto...

I've been bit busy with my daily work for last couple of weeks, so gamedev activities have got less attention than normally. But still there has been some progress since my last update. My original plan was to finish and release "Dualball" flash game in the end of September, but now it seems to take some more time. Game itself is in pretty good shape: the mechanics works, there are no detected major flaws currently, and 75% of planned levels are ready and tested quite well.  We have done thorough testing ourselves and a number of serious bugs have been found and corrected during the process. Gameplay tests have been run on both computer and touch-screen tablet to get some extra coverage. It has been interesting to see that some bugs are not easily visible on both platforms: E.g. "ball ground check" routine worked fine on computer, but on tablet there were strange malfunction with it. So I strongly recommend you to test your games on multiple platforms in...

No matter how simple your game is, or how well you plan it. In any case it is 110% sure that there are several bugs included in your masterpiece. And fledgling game developer surely has more bugs than the experienced ones. :) Here are my thoughts of this matter. Major and/or often occurring bugs are usually very easy to detect, and they are relatively easy to find from your code. You just need to find (or know) where certain functionality is located in your code and check the difference between desired and existing operation. Fixing the bug might not be so straightforward, but at least you know fairly well where the fault is. But then there can be very nasty bugs that occur rarely or even randomly. Sometimes it is very hard to understand if some behavior is really a bug, if it can't be easily reproduced. And locating these bugs from your code is very difficult if you don't have clear idea where to look for them. Luckily here are some ways to ease up bug hunting. I am us...

As defined in the "roadmap", we decided to make updated versions from our two flash games. Because the plan was made and the work seemed to be quite straightforward, I started evaluating and updating "Turbomole Trial Run"  flash game.  Game was originally created with Stencyl and published using the Mochimedia distribution network. I had no intention to do everything again from the scratch, so I dug out the latest development version from my backup disk and started to explore how game was implemented about half an year ago. I have to admit that my old "code" (i.e. Stencyl blocks) is not too easy to understand, mostly because of the bad "coding" style and missing commment blocks. But anyways I got an idea what I've done before, and started planning the modifications.  First task was to remove Mochimedia API blocks out from the game, and replace them with corresponding Newgrounds stuff (leaderboard mainly). I also started new game pro...

First part of my summer vacations is over, and tomorrow it is time go back to work. Luckily, I have still one week vacation left in the beginning of August. :) My game development activities have also been quite minimal for last couple of weeks. However, there is a small exception: I've been discussing with my brother how our gamedev activities should be continued for the rest of the year. And as a part of this process we have tried to sketch a roadmap for upcoming game releases. I work full-time in large telecommunications company and all my game development is done in leisure time, so there is a clear need for some kind of a rough plan to keep things progressing smoothly. First of all, we have a plan to release three html5 games in the next six months: Two smaller ones and one large one. Smaller games are planned to have relatively simple graphics and gameplay, so we are able to finish them ourselves quite smoothly. There are already technology demos up and running for both ...

During the past weekend my target was to finalize " Explopool " flash game. Basically, the game mechanics was working pretty well and the content was also in good shape from my point of view. However, I found some flaws in the first tests and decided that overall gameplay was not on the satisfactory level. Therefore decided to postpone the release date and started to do some major modifications to improve gameplay and overall look&feel.  Testing your game is extremely important, especially if you are going to make a public release of it. Although your brand new game seems to be finalized on the surface, it is very probable that there is still some polishing to do and in most cases also some bugs to be fixed. Finding those may require very intensive and creative testing.  Common target for game design and testing is to make a game that will be a positive experience for the end user. If game designer (=you) is the only tester, then it is very probable that the testing e...