Our programmer talks about the engine and the editor

July 26th, 2009 by Jim

Hi there! My name is Jiman Andrei and I am currently the only programmer here, working on Rinni – The elements of Xi. This is my first blog post ever so I hope I’m doing it right :)
For the first post I believe it would be best to talk a bit about our engine and our editor: what they’re suppose to be and what they are so far.

What they’re supposed to be

The core idea of the engine is to be: flexible, fast and easy to use.

The most important for me right now is flexibility. The point is to limit both artists and level designers as less as possible thus allowing them to come closer to the concept they dreamed of. The catch is that sometimes flexibility kills “ease of use”, meaning that those dreams will be harder to reach. It will be a challenge to find the balance between the two, but I can’t say I dislike challenges :) Last, but not least, comes speed. This is an issue I am not quite concerned about just yet since as we speak our engine is fast enough to run on low end cards. I have a few tricks up my sleeve, but they are not needed at the moment and I can’t afford spending time on optimizing something that doesn’t exist yet.

Now let’s talk about the level editor. The whole idea behind it is that it’s not “Rinni – The Elements of Xi Level Editor”, it’s “Pixel Toaster Studios Level Editor”, meaning that I don’t plan on using it JUST for Rinni, but for the vast majority of the 2D titles that we might release in the future. The downside of this plan is that it will take longer to get the tools ready, but once they’re ready, it will be a breeze to come up with new titles, eliminating most of the hard and redundant work. All that will be left to implement is gameplay mechanics and very specific features (speaking from a programming point of view, of course).

So, how does our engine work? Well, it’s mostly based on “props” (I call them “props”, but you can call them objects, items or whatever you like). Those “props” are supposed to make pretty much all of the game, from a rock to an NPC or a door.

The “prop” concept contains: one or more images that define the aspect of the prop, a collision hull used for physics (optional), areas that trigger scripts (optional), scripts (optional) and sounds (optional). At least this is what I’ve thought about so far. The concept will change once we need more stuff. As you can see, you can define pretty much anything with this concept. Let’s take an NPC for example: a bunch of images (the character, its shadow and probably a little bird flying around him), a script that moves him around, a few sounds both for him mumbling an the bird singing and an area around him that triggers a quest or a chat with him.

This looks pretty simple actually and most of it actually is simple to implement. However, there’s a huge difference between implementing this in the game engine and in the editor. Allow me to exemplify:

We’ll take a basic example of drawing 3 overlapping images that move in a given direction.

In the engine we need to adjust the coordinates (for movement) and draw the three images. On the other side, in the editor we must make sure you can add images (and remove for that matter), you can select and position images in the right place, that we allow for the changing of the order the images are drawn, that we have an easy way to define the direction and speed of the images and have a “preview” mode that behaves like the engine above.

Things suddenly got way more complicated. This is pretty much the reason level editors are made before the game itself and the same reason why there’s usually more development time invested into the editor instead of the game itself.

What we have so far

Well, the concept does look promising, but what do we have implemented so far? We’ve got the basic props ready to be used. That means images and collisions. You can pretty much define a landscape so far. We also got layers! The layers move based on their distance from the camera and this produces a nice sense of depth with the levels we create.

Soon enough, we’ll have area triggers and scripts implemented, providing I don’t hit another brick wall of bugs :)

This is pretty much the end of my blog post. I hope you enjoyed it.
Stay tuned for more updates!

Tags: , ,

2 Responses to “Our programmer talks about the engine and the editor”

  1. Brad Whelen says:

    It is nice to see that their are hopes that this game will not only be a success but it shall also be used to create other games through the engine. While initially it may appear that it is slowing down the programming but in reality it is a great tool that will increase your output. This is definitely great resource and time management. Can’t wait to see a trailer. From what you are describing, it appears as if alot of detail has been put into every aspect of the game and I cant wait to see a finished product.

  2. Jim says:

    Hi Brad,

    Glad you’re interested in our project :)

    I also can’t wait to see the trailer :D

Leave a Reply