After almost a year of work in TinyWorlds, we have been forced to pause our more ambitious project.
For better or worse, we established a high quality standard and we could not achieve them in the set time, what has led us to abandon –but no to cancel- the project, since we are not satisfied with what we have at this time.
We have decided to change our direction by doing another type of game, a simpler game, technically speaking. We will focus on fun. But before to changing the project, we think is a good mental exercise to realize a little retrospective analysis on what we have been doing.
One of Lucera´s biggest problems is that we are a bit uncommunicative. In general, we are centered in our daily work, that is what we love to do, and we do not spend enough time telling it to the world, in a way that it looks like we are not doing anything during months because only we can see our advances and we are the only ones who know that we are working on it almost everyday of the week. This year we are going to try to use more this blog and be more communicative.
For starting with the analysis, we want to repeat that we have not reached the quality standard that we set initially, especially in the graphics section, maybe it was too high or maybe we were too demanding. We will consider that in our next project. But however where we spend most of the time was, without a doubt, in polishing the physics engine, it is a labor that, unfortunately, we underestimated at the beginning of the project.
We have established 8 sketches of the videogame, during 8 iteractions that have help us to improve, accept or discard different initial ideas. And although did not manage to finish TinyWorlds in the set time, we expect to be able to use some parts of it in other videogames.
All the game is programmed in C++, using our videogame engine MindShake, our audio engine BrainWave and our physics engine OutWit.
TinyWorlds is really a 3D videogame, although we decided that the camera will be always on one side, like a classic 2D arcade, but with volume. In fact, like part of the esthetics, we exaggerated the volume in the Z axis in order to emphasize that the videogame is three-dimensional.
Like we said before, in the graphic section we have not had luck with the different artists that have participated in the project. Initially we decided that the videogame should have an esthetic similar to an electron microscope view, but unfortunately none of the graphic artist we worked with has managed to get the look that we wanted.
As you could read in previous entries, the main character of TinyWorlds is a blue bacterium with yellow eyes, many pupils and a dangerous tooth row, like the one you can see in the previous concept:
Also, as you progress in the game, the bacterium acquires some flagellum with which you can do some things that you could not do at the beginning.
The main objective of our hero seems to be to infect cells with nucleus that can be found in the different phases of distinct levels, although as we advance in the game we are going discovering that things are not what they seem…
And now, we will describe some of the key aspects of TinyWorlds:
Even though in this videogame we generate the geometry of the levels in realtime, most of the information of every phase was contained in a TMX file (created with Tiled).
Inside of tiled, the information is divided in layers of objects and we use the object’s proprieties to be able to configure them. For this, we define initially a document where we describe
the different proprieties than every type of object can have, visual or logic.
Generation of Geometry:
In order to generate the geometry in the right way, the first step is identifying, through regions and properties in tiled, what is a room and what is a corridor.
The main restriction of the rooms, to be a valid one, is that it must be able to trace a straight line from each vertice to the centroid of the room without being crossing into any other line.
On the other hand thanks to the corridors we identify what we call doors, which connect a corridor with another corridor or with a room.
In order to generate the geometry, we decompose splines adaptively, after obtaining the segments of a close polygon that later we triangulate to obtain the different net that compose the scenarios.
It can be said that in TinyWorlds everything is elastic. Both the main character and the scenario can be deformed as they were made of flexible and soft material.
In an internal level, the main character is made of particles bound together by springs at different levels, which give it an organic behavior. And thanks to the different kind of springs we can give it a more or less soft appearance.
Like our hero, the cells that appear in the scene are made of springs, although they have much less detail that the main character.
Besides this, all levels have an “external edge”, elastic too, which confine our hero inside the limits of the level and prevents it can come out.
One of the main features of the scenes of TinyWorlds is that there are no straight lines. Both cells and scene edges are defined by splines. In this way, the general look of the scenes seems more organic.
One of the most difficult things in TinyWorlds was to attrac the characters by all surfaces without creating vortices, in which could get trapped by different gravities. We must take into account that some cells can move in order to reach some places, and characters had to be able to walk without problems in any surface.
We can achieve this movement with the use of an improved quadtree where we store the springs-segments, produced in the geometry generation step, as well as lookup data.
Configuration files and panels:
In order to configure the world in an easy and efficient way, in TinyWorlds all elements can be configured by external files, in XML or CFG (key = value) format when information does not have a complex structure.
That files can be modified at any time by a text editor or changed by a panel system that we can use at any point of the game.
Here are some examples:
Example: configuration panel shapes.
NumParticles = 14 # Must be even (forced) (max 126)
DefaultBlobRadius = 30
# Blob springs
SpringToCenter = true
SpringToNeighbor1 = true
SpringToNeighbor2 = true
SpringToNeighbor3 = false
SpringToNeighbor4 = false
SpringToOpposite = true
SpringToAllOthers = false
# Blob particles
ParticleVelocity_Drag = 0.9f # Used to reduce blob internal velocity
StayFit_Elasticity = 0.8f # Used to maintain blob shape (circular)
GroundCollision_Elasticity = 1.2f # Used to bounce blob particles on collision with ground
# Blob iterations
NumSteps = 4
In addition, we implemented a triggers system, so it is possible to configure much of the gameplay by using external files.
This part will be 100% reused in our next videogames.
<!-- indicator up (left) -->
<trigger repeat="inf" continuous="false" delay="0" id="" name="" >
<hero_enters area="1" />
<message action="hide" id="1" fade="1"/>
<decoration action="show" id="1" fade="0.5" />
<trigger repeat="inf" continuous="false" delay="0" id="" name="" >
<hero_exits area="1" />
<decoration action="hide" id="1" />
One of the things that we love about TinyWorlds is the camera behavior, because is configurable in real time with its control panel and also with its configuration file, and thanks to the triggers is possible to obtain very attractive effects.
Panel camera settings:
The main parameters of the camera refer to the different ways in which the camera can follow our hero to keep him inside the screen.
- Fix: The camera is always focused on the main character.
- Delay: The camera follows the player with a delay, so when he start to move, the camera take some time to follow him, but do it with the same path.
- Average: The camera moves to the middle point between it position and the player position.
- Approach: The camera tries to arrive the desired position in a fixed number of iterations.
The ‘limits’ parameters restricts the camera when following our hero, and they are used to avoid, for example a big change in the current position if the character is suddenly teleported. With this limit, the camera will do a fast travel to the player’s position, instead a position swap.
The predictive mode allows it move ahead or behind in the player’s direction, letting it to show a little more of the stage in the direction that our hero is following. Is useful to know what we will find in front of us, or we can see if “something” is chasing us.
The different ways to zoom, by using the scale (X/Y) or approaching the camera, give a lot of possibilities to the player, because the change of scale in the camera has a curious effect over the objects at different depths.
The user control, by keyboard or by PAD, was a real challenge, because all the surfaces are curves. So maybe the player can´t intuit the movement operation. It is not easy knowing what is up, down, left o right, because it depends of the position of our hero.
Finally, we got an intuitive movement which allows that every cursor or button of the PAD´s controller executes force in one direction over the main character.
This was another big improvement in our videogame engine Mindshake, because we improved a lot the particles system, letting different types of transmitters simultaneously with different overlapping effects. It is fully featured, even so that particle’s configuration panels occupy all of the screen, and it is necessary two monitors if you want to open them all.
The good thing about this system is that you can create and configure the effects inside the game, either through its panes or through configuration files.
We will reuse 100% this part in our next videogames.
As a final point, we want to mention the system of element manager, that allow us to manage all kind of components, graphics or logics: items to collect (coins, etc), keys, doors, check points, areas, messages to user, switches, etc.
Also manages automatically objects that reappear in the game if you are killed before arrive to a check point, and can integrate with trigger system, what facilitates our work.
We can reuse this part with almost no changes.
In conclusion, we have worked a lot in this project and not being able to finish TinyWorlds in the stipulated time is very painful for us. It was difficult, but a necessary decision. In any case, it was not wasted time because we can reused a lot of parts of it in other projects, and we have learned a lot of useful thing with our work.