yes of course, have fun! :D
A member registered Dec 21, 2015 · View creator page →
Creator of
Help Blööki to rescue his family from the evil kids at the fun fair
Platformer
Play in browser
Recent community posts
A lot new stuff since the last blog entry. First of all, Solar Colony now looks a bit better, because of some new graphics. But I also changed a lot of internal stuff.
Startmenu
One change is the startmenu. Now one does not immediately start in the game, but inside a start menu. There you could create a new game or load a savegame.
The nice starfield is also the background of the game itself.
The three different difficulties will result in a different starting station. The game itself is also a bit easier or harder. On hard, each citizen will consume much more oxygen, food and water.
On easy, a demolished room will give you its full cost back. On hard you will only get half of it back.
UI cleanup and room removal
The UI was a real mess. Now it is a bit better. I added a Scene2D table on the left side and added all buttons to it. Each button now has the same size and they are also a bit bigger now.
One new feature there is the destroy button. Up to now it was not possible to remove a room from the station. Now you can destroy rooms by activating the destroy button and clicking on rooms. But you can only destroy a room if there aren't any people in. If a room is removed. All its content is moved to other storage, and depending on your difficulty, you will get some of its cost back.
I also added some icons. If a citizen is hungry, thirsty, etc. a corresponding icon is shown. If a storage is full or a system is not able to produce something it is also shown by an icon.
Graphics
I have added some new graphics, but as you can see, there are still a lot of graphics missing. The character sprites are ment to be placeholders, but I think I will keep them, because they are not as bad as I thought.
As you can see on the gif animation, I also added moving meteors. They basically just some nice looking feature, without any gameplay mechanic. They are moving from right to left and will be deleted if they are near the Meteor Collector facility. But the collector itself will always produce the same amount of meteors, independent of the colliding meteors.
Cloning
Originally my plan was to let the people reproduce themself by the normal way. But that would involve more AI, rooms for the people, children and so on. But because of a lack of time, I wasn't able to implement all that stuff. So instead, I implemented a cloning facility. To generate new humans, you have to install a single cloning facility. You can then use the "Place Character" button to generate a new human, but only if you have enough water, oxygen and biomass.
Gameplay balancing
I started balancing the game itself and yes, it is really hard to do so. I added more build costs to the rooms and adjusted some converters. At first my people died very early and I had to make more adjustments. Now it looks a bit better, but it is far away from being balanced. I will try to find some time to adjust it, but we will see.
Update: added artificial intelligence to the citizens. "Intelligence" is maybe not exactly what I implemented, but they are now walking around and they can deliver resources from one room to another.
What's new?
Let's start with a little gif animation:
So the graphics are really ugly, but they are just placeholders.
The little guy you see there, was idling around at the Rock Crusher. Then the Rock Crusher broadcasts a message, because it has run out of Rocks. The little guy receives that message and is happy to help! So he responds and goes to the Meteor Collector, where he collects some rocks (or meteors). Then he goes back and drops them at the Rock Crusher.
Not a complex task, but let's dig a bit into code.
gdx ai
The AI of my citizens is based on statemachines of the gdx ai library. Each citizen now owns a StackStateMachine. To be exact: My own implementation of it. The gdx-ai StackStateMachine is nice, but I missed some things there:
- A simple changeState method. The gdx-ai version will always put the new state onto the stack, but in my case, I often want to replace the current state with the new one. Instead of calling revertToPreviousState and then changeState, I added a simple popAndChangeState method.
- The stack is private. In most cases that's really good, but I want to serialize the StackMachine. Sure, LibGDX can serialize it, but I don't want to serialize all States. There are some states I don't care about. The GotoState is one of them. It contains a GraphPath and the start and end room. But instead of serializing it, I discard it, because the parent state is able to reproduce it anyway.
Most states are implemented as a simple Java enumeration:
public enum AI implements State<Citizen> {
Idle() {
public boolean onMessage(Citizen entity, Telegram telegram) {
// handle messages and maybe switch the stateMachine
// ...
return false;
}
},
GotoSource() {
public void update(Citizen entity) {
// goto to specific room and grab resources
// ...
// this will add a GotoState if we are not at the source:
// if( not near source ) gotoRoom(entity, job.from);
}
},
DeliverGoods() {
public void update(Citizen entity) {
// goto to target room (add GotoState if necessary)
// and drop items...
}
};
public void gotoRoom(Citizen entity, Room target) {
GameWorld world = entity.getWorld();
BasicGraphPath path = world.findPath(world.getRoom(entity.position), target);
if(path != null) entity.stateMachine.changeState(new GotoState(path));
}
}Of course, because the behaviour is described by an enumeration, I have to store any additional information inside the citizen. In this cases it is ok, because the only thing I need is a MoveJob instance. For other states, like the GotoState, I have to store a bit more data, like a GraphPath, intermediate target, speed, etc. So instead of putting that into the citizen, I added an extra State, which is not an enumeration, so it can store its own data.
Really small update: Rooms will now connect properly and the first citizens are there.
Rooms
Each room has multiple "Connectors". Each of those connectors is able to connect itself to an adjacent room. If it is connected, the floor will be rendered, otherwise a closed door is rendered. The connections are established whenever a new room is placed.
In the future, each of those doors will have a cost. This costs will be used in the pathfinding algorithm, to find the shortest and most efficient way from one point to another.
I think it might be cool, if the user can close those doors manually to seal them off in case of a leak in the hull. But that's not on my schedule now, maybe I will add it later on.
Citizens
I implemented really simple citizens with a basic walk animation. At the moment they are nothing more than a position vector, a direction and a texture. The next step will be the pathfinding algorithm, to let them walk around.
Due to a lack of time, I wasn't able to work as much as I wanted. But at least I was able to implement some of the basic stuff.
Screens
The game consists of a stack of different ScreenStates. When starting the game, the MainMenu screen shows up and when you select a new game, the GameState is pushed onto the stack. If you pause the game, a PauseState is pushed, etc.
The top of the stack is the only state that will be updated and rendered. So if you push the pause state, the game will obviously be paused and to continue you just have to pop the pause state. Easy go.
Tilebased or "Room"-based ?
Which is the better solution? Answer: They are more or less equal.
Tilebased:
+Simple collision detection: Just check if the tiles are free!
+Super simple pathfinding
-if based on an array: limited size
-Complete rooms will be placed, but each room would consist of several tiles...meh
Room based:
+Unlimited in size
+One room is one unit
-pathfinding is a bit more complex
At the moment I prefer the later one and I hopefully stay with it! Would be a shame to change it later on...
Bad, bad design...
For an easy access, I added static access to the textures. Really ugly and bad coding style, but for a "simple" game like this one, it will work. (Don't do this at home!)
Room placement
Up to now, I only implemented the mechanics to place new rooms, without any fancy stuff. If a room can be placed at the cursor position, it is rendered in green and otherwise in red. No black magic here.
The room itself is nothing more than a placeholder. Later on there will be plenty of different rooms with different features, like a water recovery system, carbon dioxide reduction assembly and so on.
Next step
The next important step will be the implementation of simple people and the pathfinding for them.