Unlike the other songs we have shared with you so far, this is not one that can be considered a standalone musical experience. If for the other two you could easily separate them from the graphical background and the gameplay and they would probably have the same impact value, this track is heavily targeted on that specific level and has more meaning and more emotional strength while combined with the other game elements. I hope you will take the time and listen to it and we’ll be grateful if you could share with us your thoughts and opinions regarding it.

Finally, I’m going to use this opportunity to let you know that Vlad’s new site is now online – SJCONGO. He’s a very talented musician, we’re lucky to be working with him and we’re going to do our best to support him in his musical endeavors even when they are not connected with Pixel Toaster Studios.

As you well know the whole graphics package is going through a complete makeover and our two dedicated artists are working hard to transform and also improve the original concepts. This takes time especially when you are working with a colorful bunch of people with strong ideas and the will to see them taking shape in a video game. Jim, our soon to be famous brilliant programmer, is constantly setting new boundaries to what you can do with a platformer engine. About a month ago he finally managed to get the PTS designers off his back, me included, by providing them with an awesome toy in the form of a fully functional editor. Of course, that fixed a problem, but generated countless others in the form of bugs and tweaks/features requests. Add them to the constant work of optimizing the engine and everything related to it and you get the idea how overwhelming the whole thing can be for him. I and Iorya are probably the only ones having a blast since for the moment there is no pressure on the design core so we are kind of playing around with things and stressing everybody else with our requests.

Bottom line: we are striving to release a game that is at every level as close to perfection as humanly possible and we will waste no effort in trying to achieve that. That includes release date delays because Rinni – The Elements of Xi will go public only when we all declare ourselves happy with what we have accomplished. Make no mistake: we are seriously committed to the new deadline, but we will always put quality first and if for reaching the desired level of game polish we need to postpone the release again we will not hesitate to do so.

Seth Lex

Area checks have been in there for a while. Scripts were working as well about 2 weeks ago. In the level editor that is. Getting them to run in the preview tab (actual game simulation) was quite tricky. It took a lot more than I anticipated, but now they’re getting along quite nicely.

So how do those exactly work? Quite simple actually. Each prop can have an unlimited number of areas defined inside and each area can have its own script. For now, scripts are run only when the player enters the area. In the near future, each area will be able to have lots of scripts attached, based on the triggering condition: time greater than something, player has certain properties, per-frame, etc.

Scripting system

The scripting system is a very powerful tool and this means there’s a high chance of over-using it. Scripts, unfortunately, are very slow compared to compiled code, but offer a lot of customization. Obviously I’m trying to keep the best of both. Instead of having scripts rule the game, I plan on keeping them one-shot actions. In other terms, I mean to have the scrips execute as rarely as possible and tell the engine what to do, instead of having the scripts run everything. This keeps the flexibility of the scripts while preserving the speed of the engine. Of course, it’s not free and it’s not as easy as it sounds. In order for the scripts to pull the levers, first I have to make the levers and connect them to something. Time for an example! Let’s say we want to control they movement of the player. The slow way would be something like: “If left key is pressed, move player to left. If right key is pressed, move player to the right.”. This would be defined in the script, which is supposed to run every frame, check the keys and move the player if necessary. Does the job, but it’s very slow. The right way to do this is to run a script once that does this: “Set the left movement key to: Left Key. Set the right movement key to: Right Arrow” and then have the engine run according to what the script configured. Advantages: the engine runs the code (fast), you can set any key for movement (flexible). Disadvantages: the support for this has to be built withing the engine. That means more work for me, but better speed in the end.

Other stuff

Being low on “Programmer Enthusiasm”, I worked on a few small examples which will come in hand quite soon. One is a small (and very fast) particle system. Another is something very similar in concept, but quite different inside the code. Both of those are very useful when the time comes to add in the eye-candy. The last experiment is a small (fast as well) pathfinding system. Not sure how useful this will be in the future, but since I was bored and it only took about 45 mins, I say it was well worth it. Working on a big project and dealing with complicated problems really drains the enthusiasm, but having completed those small experiments with exciting results refills it quickly.

Got a large TO DO list and lots of inspiration, so it’s back to work for me!

I hope this shed some light on the latest progress on our engine. Feel free to use the comment form below

To make a long story short, we realized we bit more than we could actually chew when it came to graphic package of the game. We made some unrealistic assumptions regarding the work force needed in ordered to deliver a game containing graphic assets of such magnitude. The original plan was to have levels drawn in full as a single image, no tiles, no objects that repeat themselves, etc. This still sounds great in theory, but the fact is that as we progressed with the level design and the levels got larger and more complex, we realized that sheer size of them was simply overwhelming, especially for a single 2D graphic artist, no matter how dedicated and work absorbed he may be. As a simple example, the 3rd level from the 1st location ended up to be a 400 million square pixels monstrosity that would have taken ages to draw.

So we back tracked a bit, took some time to think things over and toss around some ideas and we now believe we have come up with a solution that will allow us to maintain the level of graphical detail and polish we are aim for and in the same time drastically reduce the workload for our tiny graphic department. That being said, I’m happy to let you know we’re back on track, enthusiastic as ever and still hoping to maintain our promised deadline.

The following blog post will probably be Jim’s since he has recently finished doing some of his technical mambo-jumbo with the game engine and editor that I can’t hope or wish to understand, but he’s pretty happy about and I’m sure he’s dying to share this binary extravaganza with everybody.

Thank you!

So this is it, my first and probably my last blog post, text post at least. I’m going to keep on posting, but limit myself to the “image” section of the site where I can tell you thousands of stories through color and shape, where I can introduce you to bran new worlds and characters you’ve never dreamed of before.
Finally, about Rinni – The Elements of Xi. Seth Lex asked me to write a few words about the artistic direction, some sort of introduction into the graphic world of our game, but I simply can’t and if your still wondering why, please read above. What I can tell you though is that… err… well… these are the voyages of team Pixel Toaster. Its continuing mission: to seek out new gameplay elements, new entertainment methods. To boldly go where no (insert offensive word here) corporation has gone before. Hmm, this sounds a bit familiar doesn’t it? I think I’ve heard something like this somewhere before, I’m just not sure where.

Ok, that’s all folks!

Ta-daaaa: blog post! Thank you!

Mutley

On the emotional layer the level is marked by the first and probably the most violent and shocking twist our game story has – basically it’s the catalyst of the entire flow of events that follow. It’s also the moment the main character instantly takes shape, matures and becomes distinctive enough to separate him from all the rest of the Giblits. He loses all connections he previously had with his people as he is forced to make some very hard decisions and this accelerated transfer from childhood to adulthood leave our tiny hero a bit scarred and confused. So as you can see there is this huge baggage of emotional information that needs to fit in just one level without making it feel flooded and that’s certainly not easy.

When stripping everything down to core level design you’ll find a four pieces structure. The first one seems to be more like a tutorial because it focuses on introducing some newly obtained abilities from the previous levels and helping the player get the hang of using them. Although short this stage is pretty important since the lesson taught here will be repeated in several other forms throughout the game – so we must make sure we have the player’s undivided attention by keeping the LD simple and focused, but not too simple because having fun is of the essence. The second part is an Element based puzzle, the first of his kind actually, and it’s a bit harder than most would expect, but we decided to keep the overall difficulty level of the game pretty high up so this puzzle is no exception. It’s based on just two Elements because after all it’s just the begging of the game and the number of Elements introduced this far is limited. Nevertheless being the first of its kind, finding the correct “cipher” of this puzzle will probably take a few minutes even to experienced players. It’s followed by a fast paced jump and run section to rebalance a bit the fun sources of the game which are the puzzles on one side, one of which I’ve just mentioned, and on the other side the original platformer actions we are all, I presume, accustomed with, such as running, jumping, climbing, grabbing, swinging and so on. This part-brain-part-brawl recipe is the one we will apply in most cases when building the levels for this game.

The Forest ends with the first boss fight of Rinni and The Elements of Xi of which I am not going to tell you anything at all because I want it to be a surprise when you’ll play the game.

That pretty much sums it up, but if you still want more please check the Image section of the game site for more colorful information and keep an eye out for the following weeks’ updates because depending on what our Lead Graphic Artist wishes you to see you may get a sneak and peek at this level’s good looks.

Gifted by nature, the designer, if kept in his natural habitat, can live forever. Unfortunately there are only a few recorded such case as most of them choose death out of simple curiosity and hunger for “the new”. As soon as they die they immediately reincarnate into non-designers and find true happiness. This is because the non-designers are terrified by “the new” and seek shelter and comfort in “the old”. Since the last one can be found in large quantities all around us, the non-designers live a long, prosperous and uneventful life.

This was a happy story.

The End

P.S. The heat in Bucharest might have had an impact on the above post…

In my opinion, as an indie (independent) game developer you got to start small with something YOU would like to play, and add the novelty element consisting of one or a few things the other developers haven’t tried yet. If you can’t find anything new, just make sure that whatever it is, you make it better. Then work at the game and release it ONLY when you and the team are happy with the state of the project. Is it fun? Is it challenging? Is it memorable? These are the questions you need to ask yourself and find answers to. Also a good way to see this when the game is ready (playable version) is to do a gameplay test session with several people, from veteran gamers to simple non-gamers, and analyze how they react, see if you spot any big gameplay problems. Tell them nothing more than how to play and then just watch them and take notes – you will find out more than 50 editorial teams can tell you.

Why indie developers? Well some people decide to become indie developers because they’ve always wanted to create games. They have no big design experience, but they are very dedicated and in the end they actually come with interesting products. Some people were already developers at big companies, but due to limitations, mainstreaming gameplay for sales, they move to indie to try their best, have fun, and experiment with new things without worrying if for example a “feature” is both fun and easy to understand by 1 million people. Of course accessibility is not a bad thing, but when you take an RPG and you mainstream it for FPS players you end up having RPG developers and fans going mad.

One big step that not many indies take into consideration is the web promotion/marketing. When you have a product you gotta start heavily promoting it, from videos, media in general, to press releases, interviews and previews with Gaming Sites, and web site promotion – this is one of my jobs at Pixel Toaster Studios. As indies many of us sale the game directly from our site and if we are lucky and the game production value and gameplay are good, we may get a chance to be on high traffic portals like Steam, Impulse, Gamersgate, etc. thus getting some money back from the investment which translates into money to produce more quality games. Remember: no matter how good the game is, if nobody knows about it, you will have no sales, and that it sad.

Well these are some thoughts I liked to share with you guys in my first blog post, hope you enjoy it.

When applied to video games this generally refers to the amount of time the common player will require in order to get accustomed to the game elements, ranging from basic controls to understanding and completing level objectives. As the game progresses and new elements are introduced the learning curve registers value modifications usually directly connected to the targeted audience/consumers. So casual games usually have a pretty steep learning curve in the sense that player spends only a small amount of time learning the in and outs of the game and this is because “the lessons” are either extremely easy or the amount of information that needs to be assimilated is very small. On the other side of the fence you will find the hardcore games in which the learning process is sometimes quite demanding because of the game complexity and may, depending on the player, take a lot of time. Since hardcore games are hardly forgiving towards the player, not being able to fully master the basic elements of such a game results in a detrimental effect to the gameplay experience, and in this case the learning curve overlaps the difficulty curve, making the last one spike against the best intentions of the designer.

And this finally brings us to the idea of making a game that perfectly combines the best the two have to offer: the small and universally accessible learning packages of the casual and the complex and demanding gameplay of the hardcore. And this is what Rinni – The Elements of Xi is all about, this is the design trick we are really proud of. The so called learning packages of our game are tiny and generally consist of elements you most likely found in other platformers. Running, jumping, grabbing, swinging, etc. are actions you came across in other games of the same type, and if you haven’t had the chance to play such games I can assure you without a shadow of a doubt that they are easy to comprehend, learn and master. Then what makes Rinni – The Elements of Xi special? Well, as you progress and the game unfolds you will be presented with increasingly difficult puzzles, puzzles that you would normally expect to find in hardcore games. The extraordinary thing is that these puzzles do not affect the learning curve in any way because all you need in order to solve them you already know, so we can freely tinker with the difficulty curve without worrying about the learning curve. The Elements are things such as fire, water and rock/earth. From early childhood we all know the possible interactions between these elements, we all know that fire can heat up a bowl of water making it boil and transform into clouds of steam that can in turn produce rain or snow or even ice depending on the temperatures; we all know that a rock will sink into water, but can’t be damaged by fire and that you can extinguish a burning fire by pouring water on it.

So as you can see there’s not much we can teach you and the game holds no secrets from this point of view. Also keep in mind that the above are only a small part of the Elements of Xi and only a handful of elements interactions. The difficulty of the game is given by your ability to make the necessary connections in order to solve the puzzles we will be throwing at you, and there will be plenty of those. So the question is: do you really have what it takes to solve these puzzles and help Rinni in his adventures?

Stay tuned for more design introspection in the following weeks.

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!