Java Archives - Tangible Dreams

Ludum Dare 39 - "The Liberation of Liberatia"

My Ludum Dare 39 game

I participated in Ludum Dare 39 this weekend, and made a new game. Just as last time, I decided to participate in the 78 hour Jam instead of the 48 hour Compo. While I was still adhering to all Compo rules, this meant that I could make a strategy game, and still have some time left for polishing the final game.

This time, the theme was "Running out of Power". During my brainstorming, I decided to interpret the word "power" as political power. From that, I then decided to make a game about overthrowing an oppressive government. The player weakens the regime by converting the population to their side, which ties in with the "Running out of Power" theme.

As in my previous LDs, I developed the game in Java, using the LibGDX framework.

Brainstorming

Due to the scale of the idea, I decided that the genre of the game should be a strategy game. Since that genre is more complex, I also decided to keep the mechanics simple, by implementing the game as a "one action per turn" turn-based game, with alternating turns between the player and the AI-controlled regime.

In my original brainstorm, this would happen by gradually taking control of various government departments, and then finally confronting the leader. But with a bit of prototyping, it became clear that this would take too long to implement properly. Instead, I simplified the scope a bit.

I kept the "population as a resource" element from my initial concept as the core element of the mechanics. As the game goal was still to overthrow the regime, I also needed to decide how to create that as an antagonist. Keeping the idea of overcoming multiple obstacles from my initial brainstorm, I decided that the antagonists should be three overlords instead of one.

Designing the game

By performing this simplification, the game concept was distilled into two aspects, that the game mechanics needed to cover: A way to get/lose the resource of the game (i.e. the population), and a way to defeat the antagonists.

The base mechanics in my turn based game, was to let the player choose one action per turn. So I mapped these two aspects directly into the actions that can be performed. Firstly, a category of actions that affected the population resource, i.e. gaining control over them, making the opponent lose them, or removing them from the game entirely. And secondly, a category of actions used to affect the antagonists.

The antagonists respond after each turn. Their actions affect the population in the same way as the player. I.e. taking control, making the player lose control, or removing the population from the game. This also introduced a lose-condition. The game is lost if the antagonists control all remaining population.

I decided, that each type of action would have a base percentage change of success. In order to have a purpose for the population resource, this chance is boosted the more population the player controls. It is also lowered by the amount of population controlled by the opponent.

Lastly I added some extra features for variety. Each round has a random type of action gain a bonus, if attempted. The antagonists' chance of success become higher over time (reset by a successful action performed by the player). And you can perform "investigate"-actions against an antagonist, which give a small permanent bonus to later attempts to depose him.

Finally, some music!

In my previous LDs, music has always been on my TODO-list. But it always ended up being out-prioritized by other features. This time I planned on using 6 hours specifically on sound and music, and prioritized it as a "must-have" feature. So for the first time in seven Ludum Dare participations, I ended up with having actual music and sound for my game! I'm pretty happy with finally reaching that personal milestone. Next on my list: Making good music 😉

Play the game!

Try "The Liberation of Liberatia" now!

Simple data-driven game design

A simple example of data-driven game design in "Above Your Clearance"

In my latest game, I experimented with making my game objects data-driven.

At its core, the concept of data-driven design is to avoid hard-coding the game objects and game logic into the game code. You can implement this to various degrees. For example, instead of defining your different game objects as different Java classes, you can instead define a generic game object structure. You can then define properties and types that you can then apply to these generic objects. In this way, you can "assemble" game objects dynamically, using these properties and types. And your game engine then uses these to handle the game logic. This is the approach used in Entity Component Systems for instance. You could even implement your game-specific logic in a scripting language, which you could then maintain using external tools.

There are several advantages to such an approach. As your game objects are now data instead of code, the game can import them from external data files. You can then alter these files, for instance using an external editor. This means that designers (or modders!) can tweak the game logic, without requiring any code changes. You also get a clear distinction between the game code and the game logic.

The structure of the game

"Above Your Clearance" is a short adventure-game, which follows the format of classic "choose your own path" adventures. This means that the game has a very simple structure. The game presents you with a situation, and then you get a number of choices. Each choice will potentially change the state of the game world, and then move you to a new situation. I designed this structure as series of nodes, connected by choices, which can be simplified into the following diagram:

Game concepts

I also introduced two resources to the game, credits (money) and clones (lives). If the player run out of either, he loses the game. Additionally, I also included the concept of "plot flags", in order to track the choices made by the player. This means that the game logic boils down to the following concepts:

The game tracks which node is currently the active node. The active node is the node which is currently being displayed to the player.
A node has a description, which the player can read. It also has a list of choices, which the player chooses from, in order to change to the next node.
A choice has a description, describing the choice to the player. It also has a destination, which is the node which will become active if the player chooses this choice. In addition, a choice has a requirement, which checks e.g. a specific plot flag. If it doesn't pass, the choice will not be visible to the player. Finally, a choice can trigger one or more effects. An effect is a specific change to the game world, for instance setting a plot flag, or changing the amount of credits possessed by the player.
A requirement is a combination of the type of resource and a value. The game logic uses these to check the fulfillment of the requirement.
An effect is a combination of the type of resource and a value. The game logic uses these to change the specified resource by the given amount (or change the specified plot flag).
When the player selects a choice, the game logic will apply any effects related to that choice. It will then check whether the player has run out of any resources. If not, it will change the current node to the destination.

A data-driven design approach

As the concepts above include game logic, I had to isolate this from the concepts themselves. Specifically, there is logic to check the requirements, to apply the effects, and to change the active node. As I did not want to implement a scripting language for this game, some hard-coded game logic was necessary.

One approach could be to have different classes for each type of effect and requirement. Those classes would contain a Java-method to apply the the specific effect or perform the specific check. However, this would mean that these objects would contain game-specific logic.

Instead, I implemented a type property for these classes, with a type for each specific effect or requirement. For instance, I implemented a type for "change the number of credits", a type for "set plot flag", etc. I then combined this with a numeric property that specified the magnitude of the effect.

This meant that I could move the game logic into the game code itself. I implemented the game logic itself as Java methods, which would get the effect or requirement as an input parameter. These methods could then use the type and magnitude on the game object, to determine how to handle it.

Implementation

See the source code

Designing a GUI to handle the above concepts was relatively simple. At any given moment, the player only sees the active node, and the choices related to this node. So I made a GUI to display this information (as well as the current resources). When the player presses a button, it applies the corresponding choice to the game world. It then refreshes the GUI with the contents of the new active node:

As for the implementation of the concepts above, the data model consists of four data-driven classes:

A Node class, which contains a description, a node-number and a list of Choice objects.
A Choice class, which contains a description, a Requirement object, a destination node number, and a list of Effect objects.
A Requirement class, which contains a type and a magnitude.
An Effect class, which contains a type and a magnitude.

Each of these classes only contains properties, no game logic. It would therefore be possible to import them from an external data file. The GUI dynamically shows the currently active Node object. It also determines which choice buttons should be active (depending on their Requirement object). And the choice buttons call the internal game logic, with their corresponding Choice object as a parameter. In all cases, the data-driven classes contain no game logic, only information about how the game logic should handle them.

Try "Above Your Clearance" now, to see the concepts in action!

Conclusion

Hard-coding your game logic directly into your game objects is fast, but it can be inflexible. By using data-driven design, you can handle your game objects and game logic as data, instead of code. This means that you can keep the code separate from your game objects.

Instead, you implement properties corresponding to the game logic you want to support. You can then assign these properties to your game objects. This can make it easier for non-coders to customize and tweak your game play. In addition, this also makes it easier for your game to support external editors, and even modding.

"Above Your Clearance" - a #1GAM game

A text-based "choose your own path" game, made in Java LibGDX.

For my May #1GAM entry, I have created a short humorous "choose your own path" style adventure game called "Above Your Clearance", using Java LibGDX.

In the game, you play as a Citizen in an oppressive society, who are unlucky enough to be selected for an important mission. You then have to navigate through a series of decisions. And you need to do so, without running out of credits or clones (extra "lives").

The setting is loosely based on a tabletop roleplaying game called Paranoia. I intend to use it as an introduction to new players of this game, as a sort of "primer" on the tone of such games.

My focus this time was to build a "data-driven" game: Every game location is displayed using a single reusable UI. The content of this UI is then changed dynamically, as the player progresses through the game. The game objects are implemented as objects with data, but without game logic. An example of this is the Effect object, i.e. what happens when the user chooses a specific choice. It has a type (which is the kind of effect it has on the world). It also has a corresponding magnitude. But it contains no logic about how to apply itself to the world. This means that Effect objects can be defined as data, e.g. in an external data file, or through an external editor. The game logic is instead handled by the core game logic. Here, specific functionality is excecuted, depending on the type and magnitude of a given effect.

Additionally, I made a few more experiments with the Scene2D GUI-api, including building some custom Actor components, that are easier to change dynamically during the game. This ended up working rather well. As I did for my latest LD-game, I also made a HTML-version of the game. The game should scale for both high-DPI and normal-sized screens as well, which also took some experimentation.

Play the game!

Try "Above Your Clearance" now!

The Morix Colony: A Post Mortem

Introduction

The following Post Mortem contains my reflections on what went well, and what did not go as planned, during the creation of The Morix Colony, my recent Ludum Dare 38 submission.

Background:

The Morix colony is a turn-based strategy game, in which a young nobleman was banished from the Imperial Court by his older brother. He was sent to the small remote planet of Morix, to act as its new governor. Using the resources of his new world, he will extract raw materials, amass wealth and influence, upgrade the colony, and fight off (and/or bribe) marauding space pirates. Eventually, he will become powerful enough to be able to repay his brother for the injustice.

It was made in my sixth Ludum Dare, and was my first time participating in the Jam instead of the Compo.

What went well:

Story - I’m glad I took the time to work out a story as my first task, as it gave the player a specific goal to achieve. At the same time, it gave me a contextual framework for all the other writing in the game. This meant that I could frame all the other events, resources and NPCs in terms of how it helped the ambitious main character in achieving his goal.
Participating in the Jam - I usually participate in the Compo, but this year I decided to participate in the jam instead. I followed the same restrictions as the Compo, but for the extra time. I really enjoyed having time to make some deeper gameplay, a proper story, and a more polished end result this time.
Content - I am happy with the amount of content I managed to include in the game this LD. I managed to include a variety of gameplay elements and resources interacting with each other. I had time for a greater variation in the writing, and even made two different endings. I also managed to implemented a good deal of reactivity: The NPCs addressing you differently depending on your reputation and social status. The random events changing if you become a criminal (or as a result of various actions through the game). And your advisor has different reaction facial expressions, depending on the news of the round. Just to mention a few.
Mechanics - I am quite satisfied with the mechanics I implemented. The interplay between the resources, the colonist allocation and the random events worked out pretty well. The gameplay naturally evolves into three different phases: Forst a survival phase in the beginning, where death could come swiftly. Then, this is gradually replaced by gaining traction, as you start to be able to buy upgrades, and are able to take advantage of the positive random events. And then, finally the feeling of power and stability, as you amass wealth and resources in preparation for victory. I also think I hit upon a good number of different resources. They behaved similarly in some respects, but also had unique uses to justify their separate existence.
UI - I was pretty satisfied with how the UI turned out. It seems that the tooltips in particular, worked well in explaining the game mechanics. I also feel that I struck a good balance between gameplay complexity and a simple interface. I also wanted to have tracked the colony upgrades in the UI, but I did not have the time to make the icons, so that instead became part of the end-of-game score.

Things that didn't go as planned:

Scope - My scope ended up a bit too large. I had to cut a few features, like extra facilities and upgrades that would have given the player more control over the random events. For instance the ability to assign colonists to defense, or to operate a radio facility, which would allow finer control over the probability of the random events. I’d liked to expand upon the mechanics even further, with a few more facilities, upgrades, and events for variety’s sake.
Early game - The early game suffered a bit from the cuts mentioned above. In the beginning, before you have built up a stockpile of resources, there is not a lot to do, except for advancing the clock, and hoping for some good random events, to be able to survive the pirate attacks. I had originally planned for an extra “game phase” in the beginning. There you would spend your first turns building up the colony. This would culminate in the construction of a space port, and mark the beginning of getting the “visitor” random events. Instead, I tweaked the pacing of the beginning, so that you have to balance your growth with being able to keep the pirates at bay. But the randomness of this phase felt frustrating to some players.
Content - While I built a lot of reactivity and details into the game, I think I should have adapted this effort to the kind of event that Ludum Dare is. The time spent on multiple endings, and creating a lot of subtle details that will only be seen after playing for quite a while, could probably have been better spent on improving the early game experience.
Tool-familiarity - I made the game using Java and LibGDX, which is my usual tool set. But this time, I ended up spending several hours on Saturday, on experimenting with mouse-over, and drag and drop functionality. I should definitely have practiced more on using the UI-toolkit before the event itself.
No music or sounds - Every LD I want to make some music and sound, but in most of them I fail to allocate the time for it. For sounds, I usually use BFXR, but I think I have to find a simple music tool without a daunting amount of features, much like the simplicity of Aseprite allows me to make functional pixel graphics. If you know of any such music creation tool, I’d appreciate it if you would leave a comment!

Conclusion

This has been one of my most enjoyable Ludum Dare events so far. Due to the extra time from the Jam, I had time to experiment with some deeper mechanics than usual. I was also able to spend more time on the writing and story, and to create a user-interface that feels more “alive” than in my previous games. I’ve also enjoyed the post-LD gaming, I feel that I’ve played some real gems this time!

Ludum Dare 38 - "The Morix Colony"

Another April, another Ludum Dare

As I have a few days off this week, I decided to participate in the Ludum Dare Jam this time. My intention was, that the extra time would give me the opportunity to create some more substantial mechanics. And as an extra bonus, that I would finally have the time to make some sound and music for my game.

The theme for this LD was "A Small World". I did not find this theme to be very inspiring, to be honest, but after brainstorming for a few hours, I did manage to come up with an idea: The player is a former noble in a galactic empire. He is banished to a small and politically insignificant world (applying the theme in both a literal and a figurative sense). From here, he has to amass enough money to bring him back to the imperial court. He does this by managing the resources of his small colony.

Planet Morix - Ludum Dare 38 — The Planet Morix

The game therefore ended up as a turn-based strategy game. The player allocates his population to resource production, which accumulate over time. And at semi-random intervals, he will be presented with random events, where he has to make a choice about what to do.

The types of events vary: Sometimes the player gets an opportunity to buy or sell a specific kind of resource. Sometimes, with sufficient resources, he can upgrade his colony in various ways. And sometimes, he is threatened by hostile space pirates, demanding tribute.

The gameplay is somewhat similar to "The Organization", which is one of my previous LD-games. However, this time I had extra time from participating in the Jam rather than in the Compo. This allowed me to better balance the random events and resource allocation elements.

I made the game in Java, using the LibGDX library. This time, I focused on experimenting with the Scene2D GUI-api.

Play the game!

Try "The Morix Colony" now!