The Problems of Working Alone – Adventures in Coding

Adrian Castravete is a coder at Figshare. With his extensive experience in algorithms, Python and C programming, Adrian brings the fun into solving all kind of math puzzles. He likes to spend his free time building games and playing with his cat. You can also find him dancing in the nearest pub.

I don’t know if many people remember what it was like when they made their first running program. I still remember mine. It was a simple program that  did practically nothing.

How it began

It was just a simple C program which returned 0. Only when I advanced a little and got to print something similar to Hello, World, did I have that feeling of achieving but also a sort of emptiness. OK I did it, what now? I felt scared by the enormity of the things I had yet to learn. I didn’t know much at first, but I quickly picked up everything I could from my professors and tried my best, at home, to build something. I had no idea about algorithms, best practices or best coding styles, but I just continued learning , mostly on my own by looking at other source code.

Throughout the months of my first high school years I learned a lot and in the process of doing so I created hundreds ,if not thousands, of tiny tests, programs and projects. Many of these don’t exist anymore, lost in broken hard drives or forgotten diskettes.

Thinking back, a lot of them were trials to recreate old games, or rather to see if I had the abilities to create rudimentary versions of them. As such there have been tests like Pacman, Boulder Dash, Snake and even a very basic Wolf 3D clone, in the years onwards.

Incentive

You could say that games were a big incentive to get me started on the journey of learning how to program. I remember playing Super Mario on a Nintendo and saying to myself: When I grow up I’m going to make games like this. Years passed and hardware changes. I never actually got to program something for an actual NES but I did get to play around with various ASM and produce a kind of emulatable binary for it.

Even though things change and thousands of new games come out every year, they’re all more or less placeable in a type of genre or feel. Whether adventure, puzzle, arcade, platformers or others, they all have at least one thing in common with another game of the same genre. One of the best “coding adventures” one can take is to build a platformer; where you have your player viewed from the side and jump on objects or do other various actions with the objects around you, in a two dimensional environment. I find it’s the best balance of subtle things that puts you through the main challenges of building one.

Working at figshare

Getting older, responsibilities grow and you reduce the time you can spend on your own personal projects, and unless you find a job where you do the things you like it’s the best one can hope. If this place also gives you lots of opportunities to learn new things it’s even better. Figshare is just the place to learn new things. Amid all the versatility of subsystems and the different needs that Figshare touches on there are a lot of directions you can take to learn something new. A bonus of this is getting to do mini projects.

The game project

One of these mini projects is an idea that came out of a Figshare hackbreak. What if you could just choose a character, which would have one of our faces and drop it in a game environment with an old school feel, like a Super Mario clone, of course with the open science idea infused into it. One can imagine that a lot of ideas stemmed from this one including the idea of an incrementally infinite world. It wasn’t long before I started actually working on a pet project of the sort.

So where do you start when you want to make a game? With a game engine, of course. You may have noticed though, that I’m not your usual programmer that would settle for taking a game engine and building it. Even though it may sound a little silly I actually tried to make my own game engine. This is due to various reasons. First of which is being stubborn. I just couldn’t settle not knowing exactly how things are made, others would be the radical ideas we had in plan. If I want to make a side-scrolling platformer with parallax effects, infinite world generation and even bone-like animations then the engine should be pretty custom.

‘Wait, there are game engines that can be easily adapted to these needs’, you might say. Well yes, there are but how can I quench that feeling that I described at the beginning of this post, if I didn’t know even the most intricate aspects of the game engine?  Foolish again, and knowing it would be hard, I embarked on my “quest”.

Trials

Trial 1: CraftyJS

First thing I tried was to search for javascript HTML5 game engines on the internet. There are quite a few, each with their plusses and minuses. The one I settled on was the CraftyJS game engine. It’s exactly what you need if you’re looking to build a javascript game. It has very good browser support, it’s very well maintained, with HTML5 canvas or standard DOM rendering support, events, sprite map support and even collision detection. The documentation is rather small, but the API reference is extensive and there is a lot of community support, should one stumble into problems.

With CraftyJS I quickly made a working prototype with rectangle images instead of sprites. The results appeared in a short span, but something was off. Even though the construction of the prototype came out fast, I didn’t like it that the engine had a lot more features than we ever needed, the file size which wasn’t too big was indeed noticeable and it just wasn’t the way I wanted it, nor how we like it at figshare. Meaning, I could just build a simple, stripped down engine and eventually add what I needed after that.

Trial 2: Custom Engine, CraftyJS like

Of course nothing’s easy when you start an engine from scratch. Although I abandoned the idea of CraftyJS, I did like something about it: its Entity – Component model. So I decided to borrow the concept.

After a long period of working and in my spare time working on this project I built a pretty OK engine, exactly suited for what I needed. Problem with it right now was that in the frenzy of programming I did add some small stuff that most likely would never be used, and I had noticed that my engine wasn’t dealing well with large number of items. In fact it appeared that my laptop had just gotten old, because I got the same latencies in CraftyJS too. Well that wasn’t good… If I want to build an infinitely spanning level I should be able to add a few thousand objects. Thinking about this problem, it dawned me that I never deleted anything behind the player as it passed. At this point, though, I didn’t even want to delete anything. I would like the user to be able to revisit passed places.

The problem wasn’t the memory that was created, but just that iterating over the entities, an ever growing collection of it wouldn’t do. This is where chunking comes in.

Trial 3: Nickname “Fast’n’Dirty”

At this point in the creation of the previous engine, things had become so intricate that it was very hard to implement chunking on the actual source. Since it isn’t a project with a deadline, I thought it would be OK to just rebuild the engine with all the things I had learned previously. I felt a little like Kame, the incense burner builder. ‘It wasn’t the perfect creation my mind demanded.’ So I started building it again. I did leave out a lot of stuff from the older engine that was just in excess but kept everything I needed and wanted to add.

As it’s nickname implies, this version is supposed to be straight forward and the fastest implementation development and runtime wise. It should not be tainted by needless complications like prototypes and still be easily extendable. It also deals with chunks, animation and basic events.

How do you build an engine, in the end?

A simple hierarchy. That’s the main thought with which I started building the game engine. So it would be simple. Just a main class I’d call Game that deals with everything in management and then a simple hierarchy of Objects to deal with everything that’s on screen.

I’ve been talking in the previous parts about “chunking”. So what is it and how does it help smooth things up? Of course we can’t iterate on every frame over all the objects loaded or generated at runtime, but we can split them into chunks. Just have an array contain other arrays of elements to be displayed on one or a half of a screen. These smaller arrays I call chunks and they’re activated by the position of the camera. It’s no use moving objects 2-3 screens leftward or rightward. The objects outside that range would just  “freeze”. These objects will also be pulled out of the collision mechanism.

The collision mechanism is a simple one. I didn’t want to build anything too intricated if I’m not going to use most of it. It just checks that the rectangles formed by the bounds of the objects intersect each other and after collecting all intersecting objects, the control reaches back to the requesting function. It is the duty of that function to check whether for example the player falls on a solid object or just walks into one.

As I stated towards the beginning of the document I said I wanted to give the game an old school feeling. Many ideas stemmed from this one from using the C64 palette for everything, to doubling the pixels as older computer resolutions, but it quickly became complicated dealing with non-square pixel ratio. So I gave that idea UP but I did retain the screen border like in those computers.

In the future I plan on having bone animations. Right now, animation is done via spritesheets. While this is the perfect way to go, in a classical sense, bone animation give a far higher degree of granularity for movement. Interesting effects can come out of this, like non-quirky slow motion. Another aspect of bone animations is that instead of spritesheets you have assets, which are basically just one image for a part of the character that can be moved, rotated and scaled to need, which means that the file size is much, much smaller.

Conclusion

In the end building everything from scratch is not exactly what you want if you don’t want to deal with intricate subtleties, but if you’re like me you’ll want to go through them all and find your own solutions to them. In the end, you might even end up revolutionising the way something is done.

I love working on this project and after it’s done and possibly integrated into the figshare team page, I’ll release it to the open source community. You’ll probably find far better ways to do the stuff than I did!