Blogs - Aron_dc

As I can’t show you any code of Gliese yet, I will show you an interesting library I stumbled upon while I took part in Ludum Dare. It’s called “Artemis Entity Framework” and is very useful if you make a entity based game (most games are entity based I think ;) ) and don’t want to write a own entity management system.

For the beginning there are three basic classes you need to know:

• World
• Systems
• Component

Components
Components are the most simple objects Artemis does his magic on. They are simple data holding objects derived from com.artemis.Component and are used to store and change different aspects your entities could have. Just have a look at an example of a Position Component.

import com.artemis.Component;

public class Position extends Component {
	private float x,y;
	
	public Position(float x, float y){
		this.x = x;
		this.y = y;
	}
	
	public Position(){
		this.x = 0f;
		this.y = 0f;
	}
	// I've hidden all getters and setters as they are trivial. 
	// You could also chose to make the attributes public 
}

As you can see there is no magic in this code. So let's investigate Artemis further and look what Components are effectively used for.

Systems
Components normally don't have any logical code, as described above they're simple data holders. So where do we modify our entities. Let's imagine you have some entities with different components that give them information about their position (look at the code above) and speed (imagine a class almost identically to the Position-class but with speed vectors). To actually move them according to their speed we need Systems (typically derived from com.artemis.EntitySystem or its subclasses).

Systems use ComponentMappers to retrieve the different Components (called Aspects in this context) from entities and use them to process some logical code (e.g. rendering, moving etc.).

I'll show you a simple EntityProcessingSystem, called MovementSystem, that is used to transform an entitys position according to their speed.

import com.artemis.Aspect;
import com.artemis.ComponentMapper;
import com.artemis.Entity;
import com.artemis.annotations.Mapper;
import com.artemis.systems.EntityProcessingSystem;
import com.me.mygdxgame.components.Position;
import com.me.mygdxgame.components.Velocity;

public class MovementSystem extends EntityProcessingSystem {
	@Mapper
	ComponentMapper<Position> pm;
	@Mapper
	ComponentMapper<Velocity> vm;

	public MovementSystem() {
		super(Aspect.getAspectForAll(Position.class, Velocity.class));
	}

	@Override
	protected void process(Entity e) {

		Position position = pm.get(e);
		Velocity velocity = vm.get(e);

		position.setX(position.getX() + velocity.getVx() * world.delta);
		position.setY(position.getY() + velocity.getVy() * world.delta);

	}

}

So what do we have here...

First you'll notice the two ComponentMappers, annotated with @Mapper, that are later used to retrieve the Components for Position and Velocity of an entity.

Then we use the super-constructor to tell our EntityProcessingSystem what components the entity we want it to process should have. In this example we need the Position and Velocity so we tell it through giving the super-constructor the according class information.

The logic is processed in the process-Method that gets an entity to handle with. In there you'll see that we get the references to the two components we need through the ComponentMappers (pm.get(e) retrieves the Position-Component from the processed entity). Then we change the current Position with the help of the Velocity-Component of the entity (world.delta is simply the time that elapsed since the last processing run).

You can use these EntityProcessingSystems to make almost anything you need to do with your entities, from translation, rotation, assigning textures, rendering ... everything is encapsuled in an own EntityProcessingSystem.

World
The world (com.artemis.World) is the class that creates and handles your entities and systems. To show you how the World-class is used let me show you some snippets:

world = new World();
world.setManager(new EntityManager());	// sets how Entities are managed within our world. Different managers are available	
world.setSystem(new MovementSystem());
world.initialize();	//final world initialisaition. Never forget to call this!

I only added one System but you can add as many Systems as you like. You can also exclude Systems from the automatic processing (but you have to call "process" manually then) through adding another parameter to the setSystem method that sets this System to "passive"-processing. This is useful if you want to split your gamelogic (typically processed automatically) and your rendering (that you better invoke manually to maintain a correct rendering order (e.g. background-foreground-hud).

Our world is initialized now, but how do we add entities? That's nearly as simple as writing a Component. First we retrieve a new entitiy from our world, then we add all components we think it needs and last we call addToWorld() at this entity.

Entity e = world.createEntity();
e.addComponent(new Position(20, 20));
e.addToWorld();

The last thing we need to know is how to start the processing of our entities. To do that we first need to calculate a delta time (a time that passed since the last call of our main game-loop). As I use libgdxs Game class I already get that value from libgdxs internal behaviour.

//this belongs into you main game-loop
world.setDelta(delta); // pass delta time to Artemis
world.process();
// here you could also call process at any System, you have excluded from automatical processing (e.g. rendering)

First we give our delta time to the world object, so it knows how much time passed. We then call process at our world object, that invokes every non-passive System in the same order we added it to our world. If you have passive Systems you'll need to invoke their process() method manually.

Conclusion / tl;dr
Using data classes (Component) and classes that implement the processing logic (System), Artemis makes it easy to hold your entities logic independent of the entity description and keeping them physically separated. The approach of adding needed components to an entity makes the whole system very flexible and helps keeping them slim and easy to understand. Thus making the whole implementation of different entities really fast and slim.

Mimisi? What's that? It stands for Minimalistic Minimalism Simulation (very creative eh?) and is my entry for the Ludum Dare that happend just last weekend and had the Theme "Minimalism".

Mimisi is a cut down "settlers with highscoring system" game, where you have to build a little settlement on an island and make sure your villagers survive. To make sure that they don't die you have to make sure enough food is in your silos. But on the other hand you are also reaching for higher scores that you only can gain when you build more smiths that produce tools (they are directly converted to points at the end). So the big dilemma is keeping the balance of food production, the ammount of sustainable villagers and the production of tools for getting big scores at the end.

So what's so minimalistic at this game? It's not just the graphics (even if that was not intended to be a minimalistic part --> programmer art) it's also the gameplay in what you have somewhat minimalistic influence on as you can only decide where your villagers build and what building that will be. From here on your villagers take over and fulfill the tasks (building & transporting goods) on their own. So if you place to many construction sites, your food production can get too unattended an so your villagers will starve to a painful death (figuratively spoken).

As it its written in Java with the Slick2d Engine it should run on every Windows,Linux & Mac with the most recent version of the Java Runtime Environment.

I also uploaded my Source code (but I strongly recommend not to look at it if you don't want to die painful like these little villagers, as it was written without rhyme or reason...) so you can have a look at it (believe me, don't do it! Or at least have in mind that this isn't the normally achieved quality of code i produce!)

So finally here's the Link to my entry on the Ludum Dare 26

So let's start this thing here off slow.

As this is my first post here I should introduce myself to you. First, my name is Sten (in the internet I mostly use my nickname "Aron" or "Arondc", long story... blah blah) and I am living in Leipzig(germany). Currently I'm 27 years old and studying for my masters degree in computer science that I hopefully achieve sometime next year. I am programming since approximately 10 years now, mostly in Java, less C/C++ or other Languages (LUA,Javascript). So that should be all hard facts you need to know about me.

Why am I here?/Why am I posting here?
A good friend of mine (see "Baldurius" in my friends section, he has a great project he's working on too!) asked me if I know about IndieDB (of course I did!) and if blogging here is useful to make your project known to a wider audience. As I didn't know how many users follow the blogposts created here, he just started and I followed. So my appearance here is one part an experiment and another part hope to find other people who are interested in what I do (at least more than on my old wordpress blog).

About my project
Workingtitle "Gliese" (named after the Planet Gliese 581 d ... go google it!)

Some time ago I started to design a game about surviving on a foreign, not so friendly, planet. My inspiring example was mainly Outpost2 as it never had a (spiritual) successor as far as I know. But I didn't want to concentrate on pure colony management (like Outpost2 did), I also wanted to have some bond between the player and the little people on this planet. So I decided to cut things down from big style colony management to a smaller group of people trying to set foot on this planet to survive and prepare it for the real colony ship that will arrive sometimes later. At least thats my idea until now. Maybe I'll switch my focus back if I see that the gameplay, I have in mind, doesn't work very well.

As I am in a very early stage of development (and I am moving my code from slick2d to libgdx) I unfortunately have nothing to (visually) show to you yet. I'll try to document the development through this blog as frequent and often as possible, to let you literally look over my shoulder while I develop this game.