Welcome to the Dynacat development blog. My name is Michael and I'm the lead programmer at Replayne. I've been playing video games since as long as I can remember. I spent most of my life playing Nintendo games, but have also tried out a few popular PC games.

Starting today we're going to post weekly updates, some of them being articles talking about our experience developing video games and others showing some of the game's content. Today I want to talk about how I got started at Replayne and my role in the company so far.

When I joined the project, there already was a working prototype of the physics engine. My first task was to develop a stage building tool. We could have built the stages in a 3D modelling program, but the isometric nature of our game would benefit greatly from having a specialized tool.

The stage editor is designed to build the terrain by blocks. Each block is one cubic meter in size and has nine points defining the height of the terrain in different parts of the cube. We also have tools to generate and edit larger collections of blocks and the ability to import 3D models to define more complex physical surfaces.

An image of the block editing tool being used on a stage in the game

Since I was familiar with the stage editor, I was given terrain designs to build in it, which I would send back to the designer when completed for them to add sprites (the term sprite refers to any interactive element in a video game) and decorative items.

Later on I was given other programming tasks such as building the menu system, updating the graphics engine and programming a lot of new types of sprites, including enemies and bosses. As the project has advanced, the number and scale of programming tasks has diminished, but there is still a lot left to to.

As programming work became more scarce, I started doing stage design work and eventually moved on to other creative tasks as well. By taking on other tasks I can reduce the workload for the designer. As of today, I spend most of my time designing and building stages.

An image of the stage editor tool being used

Doing creative work instead of programming has been an interesting experience. Programming is pretty straightforward: You have a problem to solve and you break it down into smaller parts. Designing stages is a lot more open ended, making it more difficult to decide what to do and how.

In a small company like this it's good to have a variety of skills so that the development can continue efficiently as the nature of the development process changes.