Introduction

I managed to finish my first #1GAM game at the very end of January 2016. To be honest, defining it a complete game is quite an overstatement. In its current state, the game is just a bit more than a prototype.

The main game mechanics are developed, the core graphic engine is running steady… but it lacks all the refinements necessary to render it a real complete game (e.g. graphics is barely rough drafts, the map is just a functional test, and the game behaviour is not calibrated).

Anyway, I decided to pass on the next project and consider it done (at least for the moment being). I don’t want to spend any more time on it. It’s been a learning experience, an interesting project, but it’s time to thinker on the next one.

In this post I’ll try and sum-up and clarify (mainly to myself) the whole experience in order to take advantage of it in the future.

The Concept

The January 2016 #1GAM theme was HOBBY. Christer (Kaitila) gave a whole bunch of useful hints and suggestions in the keynote. One can refer to his/hers hobbies, or go for something on a meta-level such as developing a game about the hobby of playing/developing games.

I must admit I initially had some difficulties in finding an interesting and valid idea to develop. The theme was somewhat elusive. I didn’t want to concentrate on an abused theme, and I simply couldn’t fine one that pleased me. I didn’t want to be referring to my hobbies in any way (playing musical instruments and/or playing games and/or sport). I didn’t want to create a hobby simulator.

After some thought, I came up with the idea of implementing some kind of RPG in the like of Little Computer People. That game was really ground-breaking, back in the days (which is, by the way, 31 years old this year… holy smoke, how much time has passed!).

Once found the key, the game concept almost wrote by itself:

You are controlling a pixie, a little entity living in a low-fi simulated world. You are very prone to boredom, so you need to keep yourself occupied with as many hobbies you can. Your (low-fi) home is full of things to do to push your fun-o-meter as high as possible. But, remember, you also need to do chores and attend you daily job, or you will fail!

During the four weeks of development I wrote down a day-by-day diary of the project. It’s really fun, now that the month is passed, to read it back in retrospective and find out how the concept itself has changed. For example, I initially devised the player control to be mouse-driven. Then it changed to use a path-finding algorithm. Finally, it settled to a simple keyboard driven control (the Dijkstra path-finding algorithm I developed will come handy in the future).

What went right

The style

I knew from the start that I would adopt a old-school (pixel-art) style. Like many, I’m very nostalgic of the golden-era-of-gaming pixel style.

For the resolution I settled to a 320x240 resolution (scaled by 3). This is the standard QVGA resolution we used for the “Mode X” on DOS. Maybe a higher resolution would have been much better in terms of map-spacing (and the HUD could have been integrated better), but I couldn’t afford the additional graphics effort.

For the viewport/camera, I adopted a fixed, no scrolling, single-camera, view. This made the things really easy.

Note for the future me: raise the bar and, in a the future project, implement a scrolling and/or dynamic camera.

The input method is keyboard based, mimicking a gamepad (arrows and two function keys). This is more than enough for the gameplay purposes. I thought about using the mouse to point the target player position and use a path-finding algorithm to move the player. It worked well, but didn’t fit the game mood (with the time continuously advancing even while interacting with the user).

Framework and Tools

Coming for a C/C++ background, I’m used in develop almost everything by myself. Using a (script-based) framework like LÖVE was unusual, indeed. At first it seemed to me somewhat strange not having the control of every single bit of code, but I can’t regret my choice. The framework is really easy to use and puts no (or very little) limits and constraints to the developer. I do prefer it to more advanced frameworks/engines such as Unity, at least for not having to spend a lot of effort in learning how to used the IDE itself.

I also managed, for the sake of curiosity, to do some experimentations with the pixel-shaders and they are really an awesome tools. I will definitely use them in the future to enhance the feel of a game of mine.

As a valid companion to LOVE, ZeroBrane Studio proved itself being a really nice and productive IDE. The step-by-step debugger integration with LÖVE is really a life-safer.

On the graphic-side of the project, Pyxel Edit was a nice and easy tool to use.

It’s quite amazing that with a bunch of tools like that, and a little effort, one could go and implement a read game.

Social

Social networking is such a messy and strange thing. I don’t feel really at ease with it. Nevertheless, its potential is astonishing.

With Twitter as a collaboration/interaction medium, a lively forum, and a nice channels one can difficulty desire more.

Interacting with other fellow #1gam developers helps a lot in keeping the motivation and morale high.

Once finished, I opted to use Itch.io as a publishing platform, as a valid alternative to GameJolt.

Easy-peasy.

What went wrong

Loose game mechanics

The idea wasn’t that bad… but I suspect that the game wasn’t going to be fun no matter what. Even with top-notch graphics, audio, and the needed refinements. The game mechanics is stale.

After some days of development, once I managed to have a working prototype, I had the feeling that the game was really dull to play. There wasn’t any real interest in playing (that whence the name of the game itself spurted out). I committed to finish the game no matter what, but the final part of the development was quite uninspired. I continued to put some efforts toward completion just to reach the monthly task, and the nicest things were only ancillary to the project itself (splash screen, state management, auxiliary libraries, etc…).

In the next project I will try and define an compelling game mechanic first (perhaps with a pencil and paper prototype, if possible). Then, develop, once reasonably convinced it may be funny.

Too late assessment

I tried to keep the project simple and aim for a quick and effective realization… but, nevertheless, during the brainstorm phase I put too much things. Or better, I eliminated too few things when reviewing the ideas. The core game mechanics should have been implemented with a simple text-only interface (i.e. to simulate the player state evolution) in order to try it’s efficacy. On the contrary, I aimed for a more sophisticated game interface that required some effort to be implemented (i.e. the map engine), delaying the game mechanics assessment.

Time management

Prior beginning the monthly assignment, I thoroughly scheduled the monthly activities. I did this in order to better organize and reconcile the project with my other daily life duties. The planning was quite relaxed and did accommodate everything. But, it was too relaxed. Having diluted the developing along the month with such a pace made me, to some degree, distract. For the next project I’ll go for another kind of scheduling (more deadline-driven). I will give to myself some days at the beginning of the month to brainstorm and define the game. Then, I’ll go and concentrate on the game for two full weeks, at the end of which the game will need to be (almost) complete. The last days will be left for the final touch-ups and refinements.

No libraries

I’m not fond in relying upon third party libraries. They need to be learned, sometimes they do “too much”, other times they lack some crucial features… and I inevitably end in discarding them and reinvent (once again) the wheel. That’s The Developer’s Curse.

Due to the project nature and strict deadline I avoided to search and use external libraries. I would have ended in (possibly) wasting precious time and – most of all – incorporate something that is simply overpowered compared to the project itself.

So, I went and wrote all my support libraries (map rendering, animation management, tweening, state management). This was really fun and a precious learning experience, and hopefully it required less time than adopting external libraries. I ended in creating some really useful and light libraries that I will reuse in the next projects. Hopefully enough. :D

Conclusions

This was my first experience in a gamejam and I enjoyed it. Giving myself such a tiny (but sufficient) deadline to think and develop a game (or part of it) it’s motivating… and reaching the goal, by the end of the month, is really a self-esteem booster!

It’s been also a while since the last game I developed (experimentations left alone), and going back to square one for what concerns my computer programming self gave is very pleasant.

I simply can’t wait to start the next month project! Oh, dear… the month has already begun and I’m late (to be honest I already started the second project)!

But first I will leave you with two “epiphanies” I formulated during this month.

• You won’t be dry of ideas for too long. Just concentrate and elaborate, also with the help of some lateral thinking.

• Write down everything pops to mind as soon as you can. Ideas are volatile. Writing them down gives a valuable resource for later usage and helps in keeping focused and elaborate while writing the whole concept.

Enough for now. See you in the next post-mortems!