Some Technical Mambo Jambo

The engine used to build the game works on an eventsheet-layout-layers principle. If this sounds boring to you, then you can go ahead and skip the "Events List" section, it's mostly about that. I won't be mad, I promise.

Events List
The specific arrangement of the metagame (e.g. the game which encompasses all other minigames like the duels and battles) - with different windows appearing and disappearing at flexible intervals depending on the internal on-goings - made it quite difficult to organize the code.

At first I tried creating separate layouts for each event, but the effort of doing so combined with the jungle of swaps that was going to happen between the different layouts made this option become very unattractive, very fast.

The second approach was to have one layout with multiple displayed layers, and swap the visibility of layers based on the current needs. However, the engine used had a problem with this approach, as it a) did not deactivate elements on invisible layers and b) could not wait for an event to finish before continuing to the next one (Waiting for Signals is only possible for actions inside events.)

The solution that proved most effective and which I am really happy with is this:
Every time an event occurs, be it the player going from A to B or a random "SamuraiAppearsOutOfNowhere" function firing, the certain event is being added to the end of a list (or to the beginning, if it shall precede all other events already in the list). Then, a certain layout is restarted for every element of that list, starting from the back, and dynamically building an individual page for each element, after which discarding that list element. By resetting the same layout each time, we don't have to wait for any events to start or finish, and we don't have to rely on layers visibility and their elements.

Also, this offers the nice possibility to write down a history of everything that has taken place. Sweet!


Finite State Machines
(coming soon)

Tilemapping
(coming soon)

Mathematical Concepts for Unit Positioning
(coming soon)

Life of the Samurai - 2. The Battles

The Concept

We will get started with the Battle Mode. Here is an in-game screenshot to give you a feeling for the kind of battles we are talking about. Just keep in mind that the sprites used are only temporary and will be replaced eventually:

As seen in the screenshot, the battles are 2D with a top-down view. 

The player controls the units beginning on the bottom of the battlefield, which can be one of the following classes:

• Sword Infantry
• Spear Infantry
• Samurai with bows
• Cavalry 

The unit classes have their strength and weaknesses and when used correctly, allow for a rock-scissor-paper take of the battle, where spears easily defeat cavalry, cavalry easily destroys archers and archers are well suited against infantry of all kinds. Sword samurais are well-rounded in most perspectives.

Beyond the attack and defense power, there is stong differentiation in the movement possibilities for the different units:

• Cavalry is the quickest unit and the only unit capable to quickly cross streams and high grass or wheat fields. Infantry units have more difficulties with the terrain. A disadvantage of cavalry is their slow rotation speed.
• Archers are the quickest unit on foot and will try to back away when engaged in a melee battle of any kind, as they are the weakest in terms of armor.
• Spearmen are quite slow, both when advancing and turning around, however their armor makes them very resistent to engagements up close. Just don't put them face to face with the nimble archers.
• Here, swordsmen are once again the best all-rounders, and get along relatively well in any situation and against any enemy. 
• 
  

Life of the Samurai - 1. The Original Concept for Battles

The original concept was limited to the Battle Mode - a part of the game in which small units of soldiers fight against eachother on a 2d, top-down view map. I am writing down the original idea as a kind of protocol, even though the final result looks differently:

• Unit positioning

- The units should be composed of independent soldiers, each aware of his own state (moving, standing, rotating, attacking, defending) and capable to act by himself.

- The unit's arrangement would be left to the player's choice. If he could imagine it, then he would be able to do it. Predefined positions would be given, but other than that, the player would have a unit-manager, on which he could manually position the soldiers of a unit in any thinkable formation he wishes. Merging units of the same type would also be possible.

This concept was dropped.

• Gameplay

- This is the part I was most excited about: The interaction of the player with the battle would be neither entirely real-time-strategy, nor entirely turn-based-strategy. What I wanted to do was give each unit on the battlefield a "messenger" (let's call him "Mercury" from now on), a unit responsible for carrying information between the troops and the General's unit.

Picture a real ancient or medieval war. In the midst of battle, the general was unable to give his orders instantaneously, as almost every game these days seem to presume. Instead, his orders first had to reach the troops before being followed.

The same principle was planned for my "turn based real time" implementation. The player could roam freely on the battlefield using the General unit, but the interaction with his troops only takes place through messengers.

So, every time Mercury reaches the player, he can specify the actions that his unit must undertake (by selecting the future positions, the way of movement, the way of engagement, etc.) and send him on his way back to his unit for the orders to be followed.

I originally expected this to require fast reactions as well as good planning and steering the battle as it unfolds. Great generals would have been able to plan entire battles before they had even begun by anticipating the enemy's moves and preparing the right reactions.

Sadly, the messenger concept (having a messenger carry orders from the general to the troops) turned out to be a nice idea only in theory, but in practical terms it made the game boring and annoying. The player was never focused on the battle itself, but on the messengers and the positioning - with the battle paused most of the time. So after implementing it and trying it out, I had to scratch it and started anew - with a 2D Total War take on the battle field, which we will discuss in detail later. This also seems to stay more true to the nature of the Sword of the Samurai's battles, which allowed permanent control over the troops.

The fate of the original concepts

The first steps

The first idea for the Life of the Samurai came about while fooling around with java. This was during my first weeks of learning how to code at the university. 

We had the task to make any kind of small game, and being a fan of Rome Total War at the time, I boldly decided to try and recreate the battle mode in 2D. That turned out to be a horribly bad idea.

Not only did I lack the programming skills, but the task required a better understanding of some mathematical concepts, especially geometry, then I had at the time. This, of course, lead to an unfinished project and a head shake from the professor when I tried to turn this in:

Some soldiers standing idly in a line, on a googled background. Oh, and in the bottom right, well, those were spinning soldiers. Spinning soldiers poorly rendered.

Well, it was a start.

Nevertheless, trying to solve the positioning and movement problem turned out to be a great way to learn some of those things I didn't know, like the relation between cos, sin and tan, or the workings of pathfinding and/or positioning algorithms like the Hungarian Algorithm - which is now the heart component of the Battle Mode (which we will discuss in detail later on).

So that's when I realized that game making is a lot more than just fun or work. It's an opportunity to learn. To learn arts - graphics design and drawing, sounds design, animations and skeletal models, user interaction and storytelling, the mood and the feel. To learn complex concepts - historical concepts, mathematical concepts, organizational concepts, resource management concepts. The list goes on.  And all of this, while having fun and a rewarding result! Clearly there was no better way to go.

Thus began the quest to making Life of the Samurai.

Life of the Samurai - Prologue

Over the following weeks I will use these posts to track the progress of Life of the Samurai, a project which began out of personal pleasure and for my own development.

Life of the Samurai is a game strongly inspired by Sword of the Samurai, a little known gem from 1989 which puts you in the role of a Samurai advancing for the supreme military power in Japan's Edo Period: The Shogunate. Sword of the Samurai was a simple game, in that its single parts were short and sweet - a duel between two samurai, a battle between small units, a rogue-like top-down fight against multiple enemies, and the meta-game. However, when put together, the game was more than the sum of its parts - it pulled the player into a long and difficult journey that was as fun as it was rewarding.

All this made Sword of the Samurai, despite its wide spread lack of popularity, become one of my favourite games of all times. Stalking forums and chat boards over the years, I hoped to see a sequel or a remake, one that would offer the same journey, but beyond the limits of the 80's hardware. A sequel with better duels, battles, and graphics. As the years passed and nothing came out of the waiting, I finally decided this was unlikely to happen anytime soon, so I went ahead and took matters into my own hands. This, too, proved to be a difficult, but fun and rewarding journey.