• entries
12
20
• views
21278

Chronicles, technical and culinary, of the birth of a very complex and geeky Tower Defense game.

## Provinces management engine

We continue in detailing the mechanics of the turn based management game component by analyzing what happens, step by step, with the start of a new turn.

• Refresh effect of already occurred events, Apply events that were determined during the previous turn

• Evaluate food effect (abundance, starvation, effect on happiness and population)

• Evaluate province stability (chance of increase or decrease in rebellious activity)
Chance of rebellious activity increase :
(100-(Authority/2)-(Happiness/2)+Province modifier(province innate modifier)+Neighbors modifier)
Each neighboring region owned by the player has a bonus of 3, by the enemy a malus of 3, by the rebellion a malus of 1.

• Determine increase or decrease in rebellious chance

• If increase : Rebellious activity +=Random(1-5)

• If decrease : Rebellious activity -=Authority/10;

• Determine the occurrence of Rebellious events in the province
(Random roll 1-100 and compare with the Rebellious activity value)

• If roll>rebellious activity then no event occurs.

• If roll rebellious activity

• Determine the occurrence of random events in the province (TODO)

• Check province production (resources, gold, research)

• Check espionage detection of incoming events (TODO)

• Actions in the province during the turn :

• Take action to solve ongoing events

• Take action to prevent ongoing events (if detected)

• Build one asset in the province

• Civilian settlement :

• Food - Each unit of food sustains up to 5 units of population. Lack of food has a chance (50%+5% per each unit of food missing) of causing starvation and decrease the population (population decrease value 1-10% of the population). Abundance of food might (50%+3% per each surplus unit of food) increase the population (population increase value 1-10% of the population).

• Population - Determines the size of the settlement in the region.
• Gold production - This is the amount of gold that flows in the player's stashes from the province at the beginning of each turn.It is based on the province natural richness, the size and type of settlement, the governor's skill and the presence of a market (that generates bonus gold production from the resources production).
• More on this topic will follow in the next days....
•

Cheers,

Emiliano, H&R

## Before moving on with the posting, as we disappeared for so long, a summary of the past and present of EiR is probably due and useful (and hopefully also interesting), so here we go!

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## Empires in Ruins now celebrates its third year of life since the first time it was born in Emiliano's and George's mind as the remote idea of making a game together.

[/font][/color]
[color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## How did it begin? Well, that might sound interesting, the first idea was a Motorcycle Club Simulator, then during the brainstorming process it became somehow a fantasy based tower defense. It was our first attempt at making a game together, and in the beginning much (if not most) was about learning. Learning game design, Unity3d, assets creation, teamwork, etc etc.

[/font][/color]
[color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## The first version of Empires in Ruins was in 3d. We moved quite further with the development in the first months (of course with the euforic energy of the novelty, i.e. with not a single line of GDD, and not a clue on where we really wanted to go with the game).

[/font][/color]

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2][font=inherit][size=1]

[/font]
[font=inherit][size=1]

## A view of one of the last upgrades of EiR in 3D

[/font][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## Then slowly, when the first enemy units were already walking and dying down our 3d paths, the towers could be built and sold, we both got very busy on other projects and we had to put the project in hold for a couple of months. When we went back to it, in the beginning of 2014, we made some considerations:

[/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## 1) Making a competitive 3D game for a 2-man team of gamedev beginners was madness.2) Was 3d any useful for the gameplay? Did that additional rotation and movement freedom give any real benefit to gameplay? In truth not.

[/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## Exactly at that time unity came out with the new 2D toolkit, so it was definitely a sign that a change was due.We then decided for pre-rendered sprites out of 3d models made by George and to give the whole game a perspective-non perspective look (an ortographic topdown with 60 degrees camera angle to have a better view of buildings and units look).

[/font][/color][/font][/color][/font][/color]

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][font=inherit][size=1]

[/font]
[font=inherit][size=1]

## The very first screen of EiR in 2D

[/font]

[font=inherit][size=1][/font]
[font=inherit][size=1]

## The first semi-working version of EiR in 2D

[/font][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## While working on the TD engine, paying a huge amount of attention to every single detail (only to make the faked perspective trajectory of the arrows looking as nicely as we wanted, Emiliano (notoriously a details freak) spent something like 16 hours on it to fine tune it), we began designing a crazy thought we had: Tower Defense games almost always follow a straight "one-map-after-another" pattern. What if we changed that? What if we used TD maps to fight battles on a strategic map that had the player manage and tame the conquered provinces to avoid losing them again to rebellion or to the enemy?

[/font][/color][/font][/color][/font][/color][/font][/color]

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][font=inherit][size=1]

[/font]
[font=inherit][size=1]

## The first version of the main map and the current one

[/font][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## And that's what happened. Such a structure needed a story, and a story need a main character. We didn't want a hero, we wanted a failure of a man to lead the plot, but with at least some interesting features that would have made him attractive and somehow familiar to the player.

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## And Sgt.Heimer was born. Half-drunk, ill-mannered, unruly, and sent in a punishment assignment to tame the rebellious provinces in the Western Marchers of the principality. To say that we created for the game would be wrong, Emiliano has been writing a Fantasy book as a hobby for a few years, and that's where the whole setting comes from. The game takes place 25 years before the book, with a much younger but already pissed-off Sergeant Hans Heimer (That in the book is otherwise a marginal aged character).

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][font=inherit][size=1]

[/font]
[font=inherit][size=1]

## First sketching of Heimer by our illustrator Giacomo

[/font]

[font=inherit][size=1][/font]
[font=inherit][size=1]

## The latest conceptart about Heimer, by Giacomo

[/font][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## From there on we keep evolving and developing. The game still needs a lot of work, but we are now integrating some new members in the team in order to speed up the production without losing quality.

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]
[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## If you manage to do it, try to take and store screenshots all along the progress. The satisfaction of making such comparisons as the one in this picture below is huge. It really gives additional motivation to our work and a pushes us to move on with renewed dedication.

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][font=inherit][size=1]

[/font]
[font=inherit][size=1]

## A three steps evolution of the combat map look and UI in one year of hard work.

[/font]

[font=inherit][size=1][/font]
[font=inherit][size=1]

## A current view of the Village provinces control screen WIP

[/font]

[font=inherit][size=1][/font]
[font=inherit][size=1]

## A current view of the Town provinces control screen WIP

[/font][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## You can even already vote for it on Steam Greenlight, and our aim is to get it ready and public by december 2015.

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][font=inherit][size=1]

[/font][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## (I want to point out, that this deadline comes second after the quality of the product. There is no point in publishing quickly something incomplete or faulty, so if need for more time arises, we will take more time. Quality and features are something that we will NEVER EVER sacrifice.)

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]
[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

## Cheers!Emiliano, H&R

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]
[indent=1][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2][color=rgb(51,51,51)][font='Trebuchet MS'][size=2]

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

## Empires in Ruins - Title track OST - Red Dew Hellpipes

Hello guys, a short update while we struggle on the teaser trailer and on the GUI for the alpha version.

We finally got us the game title track, recorded and mixed by the guys from Red Dew Hellpipes. This is gonna be mainly the trailer OST and the game intro (probably a bit too focusing to be used ingame, but the style of the OST will stick to this anyway).

Cheers (soon a longer entry of the journal that we are already composing)

https://soundcloud.com/reddewhellpipes/empires-in-ruins

## Building a users base, extending your reach, where to start from

This is a short summary of how we begun spreading our Empires in Ruins. We went public on the 22nd of October after almost 2 years of development (thinking back we might have starter earlier, but on the other hand it takes a lot of time to take care of all this PR part if you are also the developer of the game).

This ones are the first babysteps of the process, but they are first of all for free, and they work. It is a slow process, so you have to be patient and constant. You can find a lot online about each of the given platforms, but if you are just moving your first steps into this, as we did a couple of months ago, checking this list out might probably help you a bit we hope!

It is probably not complete, there are many more places out there where you can say what you wanna say, but begin from here, that should already take some of your time, believe us ;)

Cheers!

IndieDB
http://www.indiedb.com/games/empires-in-ruins
Summary : Nice way to display the game and the progress, get several hits, don't get too excited if your game goes up quickly the rankings after posting some pics or stuff, don't get depressed if it goes down quickly after, it happens all the time.
Pros : Quite nicely structured, quick to manage, several hits
Cons : Needs moderation for each blog post before it's published, almost no feedback at all from users

Klout
https://klout.com
Summary : Keep track of your online influencing factor, schedule posts and tweets and manage stuff, very useful tool. Integrate the plugin for twitter to keep an eye on how you're doing there.
Pros : Optimal tool, management and measurements very well made.
Cons : Not many to be honest.

Summary : Probably the fastest way to increase your reach, using the #indiedev and #gamedev hashtags you can spread quite a lot. Find the right balance between tweeting quality and re-tweet enough times to be seen but not being a spammer. Don't forget to use the #screenshotsaturday hashtag on saturdays to have a boost of tweets.
Pros : Lots of feedback, reach grows decently fast
Cons : Don't get illusion if you get retweeted a lot from bots, the tweets flow is so large that lots of them get just lost on people's walls without being seen.

Summary : Painfully slow in the growth, people are probably afraid that if they like your page you'll be spamming their walls. Also is a bit more personal than twitter, so several don't wanna mix personal life and games, I don't know. But if it grows slowly, don't worry it's normal. (you can always pay to get fake likes from FB, but i find that a bit lame, though might be useful so people get to a page with more likes)
Pros : Use the following groups to spread, you will get quite some feedback, but don't expect many people to like your page even after liking the stuff you share. Compared to twitter a page allows you to put many more details and material.
Cons :Super slow in growing.
Good groups to join :
Indie Game Developers
Indie Game Promo
Video Game Developers

GameDev.net
https://www.gamedev.net/
Summary : Well, you are reading this so you know how to get here. I think the most useful feature is the developer journal. Don't expect tons of feedback, but much more than indieDB still. If you publish interesting dev logs you might get some useful one once in a while.
Pros :
Cons :

Indie Game Mag
http://indiegamemag.com/tag/screenshot-weekly/
Summary : One of the first steps here is to get once in the screenshot weekly section, later you can go for ads and try to get a short article there. Contact Vinny, the guy in charge of screenshot weekly, and send him 4 screenshots of you game and a little text. Not huge exposure but quite nice anyway.
Pros : Nice exposure, quick to manage, looks profi when you share the link
Cons : Not much to say about cons

Reddit
http://www.reddit.com/r/indiegames/
http://www.reddit.com/r/gamedevscreens
Pros : Quick to manage, decent exposure.
Cons : Can only publish limited amounts of stuff, if you miss the captcha or have to cancel a post and redo it, you always have to wait 10 minutes at least, a bit annoying sometimes.

ThunderClap
https://www.thunderclap.it/projects/20035-empires-in-ruins
Summary : A social crowdfunding thing, basically get enough support before a certain date and a message will be flashed on the walls of all the supporters if you get to the threshold.
Pros : Good exposure, nice tool to warm up the ground before a crowdfunding campaign.
Cons : People are afraid of spam maybe? Not to easy to get support there. The free version is pretty limited in the options on how to build the page and spread, but the payment version start to be only useful if you pay at least 100 dollars per campaign, the 45 dollars one is sorta useless.

Summary : This group is possibly the place where we got the most professional advice in several matters. Lots of experienced and helpful people there, willing to help.
Pros : Professional, helpful and useful.
Cons : More to get advice from fellow gamedev than to reach out for potential customers though.

## Tooltip system on uGUI Unity 4.6

Here we go, it took some pain as we only begun using uGUI less than a couple of weeks ago, but we managed to develop a functional tooltips system. It might still be improved and polished and the code is partially dirty, but it works well, it shows no performance issues of any kind.

No more talking and straight to how we did it, as we saw several people asking about something similar in several other places.

We have a tooltip object in the canvas, consisting of a panel with the background image and a child text element. to the panel we attached our tooltip script.

using UnityEngine.UI;
using UnityEngine.Events;
using UnityEngine.EventSystems;

When we are building the interfaces, we attach an EventTrigger to the object from the inspector, graphically, then from the code initializing the button we add triggers with a callback to the objects we need to get the data from in the following way:

public ToolTip ttp;

//initialize this by getting the script attached to the tooltip
foreach(RectTransform elem in childs){
if(elem.name=="Button"){

EventTrigger trig = elem.gameObject.GetComponent();
}
}

and the functions are

private void AddPointerEnterTrigger(EventTrigger evTrig, UnityAction action, EventTriggerType triggerType){

EventTrigger.TriggerEvent trigger = new EventTrigger.TriggerEvent();
EventTrigger.Entry entry = new EventTrigger.Entry() {
callback = trigger, eventID = triggerType
};

}

private void AddEventTrigger(EventTrigger evTrig, UnityAction action, EventTriggerType triggerType){

EventTrigger.TriggerEvent trigger = new EventTrigger.TriggerEvent();

EventTrigger.Entry entry = new EventTrigger.Entry() {
callback = trigger, eventID = triggerType
};

}

private void AddEventTrigger(EventTrigger evTrig, UnityAction action, EventTriggerType triggerType){
EventTrigger.TriggerEvent trigger = new EventTrigger.TriggerEvent();

EventTrigger.Entry entry = new EventTrigger.Entry() {
callback = trigger, eventID = triggerType
};

}

private void OnPointerEnter(BaseEventData dataObject, GameObject hovered){
if(hovered != null){
ttp.SetTooltip(hovered.name);
}
}

private void OnPointerExit(){
ttp.HideTooltip();
}

and then this is the script attached to the tooltip object. (this is the version for the gui canvas on screen overlay mode), it contains already a rough function so that the tooltip never goes offscreen if the mouse is close to the edge, and resizes itself (on a single line only at the moment) according to the length of the text

//text of the tooltip
Text text;

//if the tooltip is inside a UI element
bool inside;
bool xShifted = false;
bool yShifted = false;
int textLength;
float width;
float height;
int screenWidth;
int screenHeight;
float canvasWidth;
float canvasHeight;
float yShift;
float xShift;
int canvasMode;

public void SetTooltip(string ttext){
//ScreenSpaceOverlay Tooltip
if(GUIMode==RenderMode.ScreenSpaceOverlay){

//set the text and fit the tooltip panel to the text size
text.text=ttext;
this.transform.GetComponent().sizeDelta = new Vector2(text.preferredWidth+60f,text.preferredHeight+20f);
width = this.transform.GetComponent().sizeDelta[0];
height = this.transform.GetComponent().sizeDelta[1];

Vector3 newPos = Input.mousePosition-new Vector3(xShift,yShift,0f);

//check and solve problems for the tooltip that goes out of the screen on the horizontal axis
float val;
val=(newPos.x-(width/2));
if(val<=0){ newPos.x+=(-val); }

val=(newPos.x+(width/2));
if(val>screenWidth){ newPos.x-=(val-screenWidth); }

//check and solve problems for the tooltip that goes out of the screen on the vertical axis
val=(screenHeight-newPos.y-(height/2));
if( val<=0 && !yShifted){ yShift=(-yShift+25f); newPos.y+=yShift*2; yShifted=true; }

this.transform.position=newPos;
this.gameObject.SetActive(true);
inside=true;
//WorldSpace Tooltip
}
}

public void HideTooltip(){
//ScreenSpaceOverlay Tooltip
if(GUIMode==RenderMode.ScreenSpaceOverlay){
xShift = 40f;
yShift = -30f;
xShifted=yShifted=false;
this.transform.position=Input.mousePosition-new Vector3(xShift,yShift,0f);
this.gameObject.SetActive(false);
inside=false;
}
}

void FixedUpdate () {
if(inside){
//ScreenSpaceOverlay Tooltip
if(GUIMode==RenderMode.ScreenSpaceOverlay){
Vector3 newPos = Input.mousePosition-new Vector3(xShift,yShift,0f);

//check and solve problems for the tooltip that goes out of the screen on the horizontal axis
float val;
val=(newPos.x-(width/2));

if( val<=0){ newPos.x+=(-val); }
val=(newPos.x+(width/2));
if(val>screenWidth){ newPos.x-=(val-screenWidth); }

//check and solve problems for the tooltip that goes out of the screen on the vertical axis
val=(screenHeight-newPos.y-(height/2));
if(val<=0){
if(!yShifted){
yShift=(-yShift+25f);
newPos.y+=yShift*2;
yShifted=true;
}
}

this.transform.position=newPos;
}
}
}
here is a little video showing how it works. we make the tooltip appearing a bit above the mouse pointer so that it doesn't cause onpointerover problems, and we use the fixedupdate for the refresh as it is somehow more reliable about flickering and speed.

if you have any problem in implementing it, feel free to ask more details!

Cheers,
H

## Rebellious Provinces - Designing

"Be advised. I'm mean, nasty and tired. I eat caltrops and piss flaming oil and I can put an arrow in a flea's ass at 200 meters. So why don't you go hump somebody else's leg, mutt face, before I push yours in." Sgt.Heimer, 3rd Regiment Border Guards, Principality of Koth (sentence growled in a good mood day)

As I already stated in the previous entries, Empires in Ruins is aiming at being more than a simple TD game.
In the traditional Tower defence pattern, the main map is just a nice looking next level selection screen, I sorta never really liked the "lie" behind that strategic look it has. Therefore we decided that ours had to be different : if it looks strategic, it shall be strategic too.

Here's how the design is coming out. The following pic has a totally temporary placeholder graphics but is being used in the development of the engine for the strategic/tactical map.

Each region can belong to the player, to the enemy, or be an untamed rebellious one. Soon we'll tell you more about the plot of the game, for now just know that the main character is sent against his will to tame some rebellious marches in the Principality he belongs to, and finds himself with an unexpected war in his hands.

• The player can only attack regions (untamed or enemy ones) that neighbor one of the ones he owns.
• To conquer a new regions a player has to play a Tower Defense map.
• Each region provides each turn an amount of wood, stone and iron depending on the region specifics (e.g. forest regions provide more wood, etc) and gold (taxes) and research points.
• The player has a number of assets to build in a region to increase the productivity (library, forge, quarry, logging camp, mine, tax office)
• When the player attacks a new region he doesn't own, he chooses from which region to attack. That will give specific bonus to the single TD map (e.g. attacking from a region producing lot of wood will give a boost to the wood resources in the TD map, if the region used to attack also has infrastructures built, it gets also some bonus from 2nd degree nighboring regions (i.e. also from regions neighboring the region used to attack)
• Once the region is conquered, the player has an authority value in that province, that starts pretty low and needs to be increased by building proper assets (command post, guard post, barracks). The authority value determines the chance for each turn that rebellious activity increases or decreases in the region each turn. Regions have different modifiers to that according to their history and culture (i.e. some mountains places are famous for being home of a rebellious ethnic group)
• Neighboring regions belonging to the player give a bonus to keeping the rebellion under control, untamed neighboring regions slightly increase the rebellion, enemy neighboring regions increase it a lot (spies and agitators sent by the enemy).
• Some of the main character skill can reduce the rebellious activity
• Rebellious events can result in :

• [size=2]Loss of resources to bandits
• [size=2]Damages to assets due to riots
• [size=2]Increased chance of the enemy attacking the region thanks to partisans help (TD map battle vs enemy)
• [size=2]Battle - The player has to play the TD map again in order to avoid losing the region (TD map battle vs neutral critters (bandits, farmers, etc)

• ???A player can decide to replay anyway the TD map of the region in order to preemptively lower the rebellious value for a while.

?Ok, this might not yet make fully sense for you (even though i hope it does), but it was good for me to say it out loud to have a cleared wordy description of it stated.
If you like where it is going, drop a word in the comments, we get lots of views but no comments, i wonder if it's because you guys think it's not worth or why. We need feedback, cause in our mind it's coming out quite as we thought about it when we first begun the project one year and half ago, but the game is for all of you, not just a private thing for us.

As the design goes on and I needed to clarify my mind on what I was doing, here's some more information on the "rebellion engine" ( like this name, would be worth a game about rebellions management )
This is in pseudocode what happens in a region controlled by the player at the end of the turn :
rebellionIncreasingChance := 100-authority+rebellionModifier+various(neighboring regions, region governor skills, etc
[quote]

[indent=1]if (random(1,100)
[indent=1] rebelliousActivity+=Random(1,RebellionMaxIncrease)
[indent=1]else
[indent=1] rebelliousActivity-=AuthorityValue/10

[indent=1]diff:=random(1,100)-[size=2]rebelliousActivity

[indent=1]if(diff>0)
[indent=1] No rebellious events
[indent=1]if(0>diff>=-20)
[indent=1] Soft rebellious events
[indent=1]if(-20>diff>=-35)
[indent=1] Medium rebellious events
[indent=1]if(-35>diff>=-45)
[indent=1] Hard rebellious events
[indent=1]if(diff<-45)
[indent=1] Catastrophic rebellious events
[/quote]

and here how that is showing up in the debug window so far

Next step (before of course an endless amount of time spent in balancing the whole thing) is designing the events gravity and impact on game

Cheers for now! (the region used in the example is the blue-ish one in the first pic, with a single enemy-owned neighboring region)

## Research & Technology System design and implementation

A couple of days ago i begun the task of designing the research system, and honestly, I have always been a research nerd (that's also my main job in life, but I am talking of those people that would have loved Civ's technology tree to never reach the annoying Future Tech cause at that point all the research fun was over).

I already had the modifiers integrated in the game engine (even though all zeroed), but it was time to go for the design of the research system. I wanted to have it nerdy, very nerdy, but trying to keep it also interesting for those people that are not real research nerds.

During the last months, i kept a file in which i was noting down ideas about research topics, but now I realized immediately that to plan dependencies and requirements it was vital to have a graphical visualization of it, now other way around

I googled a bit around for some free quick access tool to draw a diagram, and ended up on https://www.draw.io/. It looked easy peasy and usable and I begun trying to use it to build up the technology tree. After a couple of attempts i noticed something that finally woke me up from my dumb moment. The diagrams were saved in XML...mmm...XML....mmmm mmMMMM!!

I took a look at the produced XML, it wasn't the cleanest i had ever seen but it was good enough. The i run to the C# documentation (EiR is built in Unity3d/c#) and took a look at System.Xml. Apparently by using it your executable gets 1 Mb larger, but when in less than 10 minutes i had the first node with the name of the research topic loaded in the game i realized that yes, trading 1 Mb of space with having a 30Kb file with all the research straight from graphical design to the game was absolutely a good, great, no, awesome deal.

A few hours of XML loading refining and expanding the diagram and yes. I am abso-bloody-lutely happy about it.

Now to balance the size of the technology tree, the specifications of each research and costs is gonna be an awfully long work, but that would have been it anyway. But the system itself works like a charm. Here's an example of how it is coming out.

Now the second part : i said I wanted to make the research system interesting also for those people that are not research freaks and don't wanna have to upgrade every single thing manually.
How does research work in EiR? Simple system. Depending on you assets and investments, each turn in the tactical map you receive a certain amount of research points that you can spend in technologies.

Now I begun designing two alternative systems to the "i wanna chose my topics by myself" way.

a) Research goes on automatically according to a queue I will decide before trying to keep it smart and balanced)
b) Player can choose a the order of priorities (Military, Building, Resource gathering, Soldiers, etc..) and the research will go on automatically, according to a queue I will also design before, but balancing a bit of every topic according to the priorities set by the player.

Now, I don't think I re-invented the wheel, but all together i think it is a decent system to quickly and visually design a research system and get it into use. Even if it is complex, the interactions and dependencies are managed visually, so it shall be easier to balance and modify for later.

Here's the first draft of a small part of the research system GUI design

What do you think? Here's how the tree looks so far (still temporary but getting similar to the real one)

In the while, stay tuned with us through :

## Introducing the Sapper

### being a pain in the ass for this dude is an art!"

from "Kaboom me a boom, baby", traditional drinking song from the 3rd Sappers.

All its stats are still temporary as the game still didn't reach the balancing phase but :

He has medium-low hp (more than average infantry and bandits but less than special troops),he is reasonably fast and with a bit of physical resistance (having gone through that kind of life makes a person tougher) and magical resistance (this is science, bitches!). He's not a close combat guy for sure, but when he reaches the castle, those sticks of dynamite deal quite some damage to those old stones.

There are different paths for the enemy horde to reach your castle aside from the traditional ones. It's the Sapper's duty, in the Krovan army, to make sure those ways are open and usable for infantry to flood in.

• Obstacles paths - A big rock or a pile of wooden trunks blocks an otherwise beautifully usable shortcut, the answer? it begins with "Ka" and ends with "boom"
• Tunnel paths - If the terrain is soft enough, he has a pick and a spade, and the skill to use them. Then why not to dig an awesome tunnel passing right under your nose and sheltering passing troops from your arrows and darts?
• Forest paths - An axe, he just needs an axe, to turn that lush forest into a walkable trail for infantries.
• Swamp paths - I mean, swamps are awful and full of mosquitos, who would ever want to reclaim them and build a path of planks so the soldiers can follow? Guess who...

So this is our Sapper, fully implemented and tested, and even reasonably smart considering the look on his face. Just lacking the game sprites (under construction) to be fully operational in its final version.

## The long, long way : On quality vs quick rushes (and Kickstarters)

This last month, according to a few months old plan and timeline, we were all hype on "yeah, let's kickstart EiR and get money to pay the people we want to work for us".

I now realize how naive that was.

We think we are developing a high quality product, with very robust and optimized code in the engine, top-class graphics and a solid design featuring intriguing gameplay traits, about that we have no doubt.
It is not about boasting, but we are really putting a huge effort in have the above mentioned properties shining in our game. We also think that although this is the first independent game we work on, for ourselves and not for some imposed specifications from above, we have the technical experience to get something very nice out of that.

Given this premise (maybe then when we will delivery, people's opinion will prove us completely wrong, it might happen, but the little feedback received so far sounds promising), let's go back to the initial sentence : "oh, we kickstart".

True, experience is the best teacher, but as nobody was born experienced, we need to make our bones on that. So we spent the last months reading (a lot), discussing (a lot) and asking questions here and there (a lot) to understand what and how.

Kickstarter is a beautiful weapon, let's say a BFG9000 (for who gets the citation). It has only one little flaw. It has one bullet only. So if you aim unprecisely, or shoot in a moment in which no huge crowd of cacodemons is preparing to charge you, you just waste it. And then it's gone ( I don't believe in a second KS try, at least not in a short term).

So we took a look at Empire in Ruins (my preciousss!) and we coldly dissected it, to see what we have and what we don't. And I am talking of one year of semi-part time work (bills don't get paid by beautiful gamedev nights only).

• We have a setting for the game. It comes from a book i am writing since a while (620 pages and going). not saying it is the most beautiful and creative setting ever (even though i hope it is), but that means that i spent 2 yrs thinking on it, so i know habits and costume of every single of the populations that live in it (in setting-building having been a DM in D&D for years is an invaluable tool).
• We have a design. We know exactly how the game is and is gonna be structured, which features will be available and where the gameplay is gonna be focused.Not saying that it's never gonna change, but the plan is clear in mind and on doc files.
• We already have most of the basic engine for a single map

1. waves and path system (newly rewritten, featuring also forests,water,amphibian, tunnels, flying,dynamically opened paths, etc etc, i am writing a journal entry about it but it's taking days)
2. units movement/animation/death/all functions
3. building and mouse interaction system (you can sneak a peek here http://goo.gl/JzZje4 )
4. towers shooting/best enemy targeting/special abilities (flaming arrows, clouds of smoke, throwing nets, caltrops, boiling oil, etc etc)
5. good-quality graphics for a single map demo (at least for terrains and towers)

• We have, almost ready, a 4 minutes original song recorded and processed by a real band (Red Dew Hellpipes, doomish military metal with bagpipes)
• We have a couple of sketches that demonstrate the skill of the illustration artist we will contract with the KS money.

Do you think all that is enough? After long long thinking, we decided that it's not.

First of all, I am absolute believe of the fact that a project shouldn't hit KS if it looks already complete or almost. I mean, why to ask money to produce something that you already produced?
But.
First of all you have to show some high quality stuff (bit of graphics, bit of video footage, bit fo drawings), to show that yes, you have a pool of skill available from which to draw what's necessary for a high quality product. And we think we are very close to that.
So what's missing?

Gameplay. People want to see a bit of all the gameplay features you will offer in the final game. Not finalized, but looking good, looking functional, looking interesting. Looking teasing.

In EiR for example we wanna put a large focus on two things that are not just the single TD map :R&D and tactics. (and RPG elements, but I will keep this for another entry of the journal)

An example of what the design states :
"The tactical map from which the single maps can be accessed is structured in regions. Each region has specific traits (e.g. forest regions, if developed, will confer a bonus to wood production during the fights in adjacent territories or on longer ranges depending on the development of the logistic system). Once a region has been conquered, mainly according to the plot flow (in several cases not only a single battlefield is open), it is up to the player to develop it and fortify it so that the enemy AI will not strike back, removing the region from the player's control"

Is this an appealing feature that might differentiate EiR from traditional TD games? We definitely think so.
Can we show that? No
Why not?

Because I think that development and showing off don't fit together. You don't rush superficially through features development only to have something to show off. I saw a few days ago a pic of of good old Bill Gates with the caption "It compiles?Ship it!".
Such a large game as we are developing (large for an indie company at least) implies a slow, accurate (to a level of paranois), modular development.

You start from medium-small components (a single map for example), then, keeping everything as modular as possible (you think you did it modular? probably is not modular enough yet), you build it. Feature after features, line of code after another. You develop the small component, you test it endlessly, then you declare it done and go with the next. And then you test the interaction over and over, and find all those if(...) cases that might arise in special situations and you solve them. And this way you go on, with a solid, robust, massive engine under your feet.

And if everything was done to perfection, a miracle will arise, a miracle called Emergence. (check this out http://goo.gl/ZjHiHl)

The one above about the tactical map is just an example among many, but the summarized moral is : don't do it quickly just to show it, and if you don't have it, don't rush towards showing it but take your time and do it well. It will pay off in the end.

Now my delirium of words, might be probably confused, ill-formed and emotional in its own way, but expresses my feelings about it, and the reasons why we decided to delay by at least two months our KS campaign.

Additionally, for exposure, if you sorta liked what I wrote, you could help us in enlarging the vital user base (that one also still too small in our case for KS and additional reason to decide to delay) and follow us on twitter or FB and retweet some of our stuff. If you don't like,
respect anyway that you got to read it until the end.
As usual, if I didn't want any comment or opinion I wouldn't have wrote all this publically, so feel free to comment. The meaner the more useful it will probably be.

Cheers,
H

## Tower defence - Static Vs Dynamic building

[color=rgb(51,51,51)][font='Trebuchet MS']

### [indent=1]When we sent the link of our pre-pre beta release to several friends that were not into Tower Games, the first feedback was always the same : "cool...but well, a bit static...".In that version of the game, towers were being built automatically on click (Build Tower button - Choose position - Click - Tower built and fully working). While this is quite traditional for TD players, i get it that somehow seems unnatural for people otherwise used to RTS games.We want to keep with us all the traditional TD followers, but why not making a game that can make more people happy?So approx ten days ago, i backed up all the code, and went for a deep refactoring of the building system. What i decided to add was the following : A limited amount of workers will be available on the map (their number depending on the skills of the player. They will leave from the castle (or from the workers tent when this building is available due to research and closer to the construction site than the castle) and walk until the construction site.There they will build the tower in a certain amount of time (progress shown by the building bar beneath the tower) and then come back to the castle.Construction sites are queued when the amount of builders available is smaller than the amount of sites.But then we decided to add some spice to it. Builders can be killed by passing too close to incoming enemies, therefore they try to avoid paths as much as possible, and in case of death, they will respawn in a certain time (unless the player spends some resources to make it instantaneous). The builders stats can be increased through research and skills.

[/font][/color]
[color=rgb(51,51,51)][font='Trebuchet MS'][/font][/color]
[color=rgb(51,51,51)][font='Trebuchet MS']

### [indent=1]Now, what do you think of this concept? So far in the test it performed beautifully. We think it gives much more importance to the time between waves (so sometimes now skipping that time for money ain't worth anymore), it forces the player to develop a much more interesting building plan, and brings somehow the game to a level of vitality that was missed before. (again, ignore the graphics that in the test image are totally temporary)

[/font][/color]
[color=rgb(51,51,51)][font='Trebuchet MS']

### [indent=1]Additionally, unlocking the builders tent becomes a very important achievement of the game, and increasing the number of workers and their skills (hp, speed and working time), gives additional interesting features for the research.

[/font][/color]
[color=rgb(51,51,51)][font='Trebuchet MS']

[/font][/color]

## Design considerations : "Video-game immersivity - Not only a feature for Virtual Reality environments"

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS']

### Imagine watching a movie, and suddenly something in the movie looks obviously fake.

[/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS']

### Doesn't it cause on you a sudden redrawal from the immersion in the scenes of the movie and back to reality?Don't you suddenly stop thinking on the scene you are watching a part of the story but as a fake scenery only. If so, your immersion in the movie has just been broken.Sometimes even a small detail is enough to break the spell : a piece of scenery looking wrong, a CGI background unnaturally strange, a modern watch on the wrist of a medieval knight. It doesn't matter what it is, but the magic is gone, and you find yourself staring at something instead of being inside it as a few seconds before.

[/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS']

### Games are not much different. If every single detail fits correcly with the others, if no flaw pops out to bother that part of your brain that notices that kind of things, you will forget everything around you, spending hours in a world of pixels that for a while will be your world. But then, a couple of single flaws can break the spell as in the movies, kicking you out from the virtual environment and back behind your keyboard.Now, if the concept absolutely is vital in Virtual Reality (CAVE-like systems or HMD), that holds as well for any other game.

[/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS']

### You are trying to capture the player focus completely, to grant him a full immersion on your game, and this concept applies in similar ways to tetris and to high-quality graphics FPS.Don't think that it depends on the quality of the graphics only, it is a much more complex phenomenon, emerging from the full synergy of the game features, even more sensitive because it can be easily ruined by any of the involved factors.Given the above introduction, let's now focus on the specific way we are taking this into account in designing the engine and the graphics of our Empires in Ruins. Don't take it as manual of instructions, but more as food for thought you have to consider when being in the first stages of your design.I think the problem is easier to describe by pointing out what might disrupt the immersivity. And mind this, the following list is far from complete, but should be enough to give a first overview of the topic. Most probably most of you already know all this, many others know it but never thought about it in detail, anyway writing it down is also helping me in tidying my mind up) :

[/font][/color][/font][/color][/font][/color][/font][/color]

• [color=rgb(51,51,51)][font='Trebuchet MS']

### Animations Game Speed - Do you really want your soldiers doing some sort of oily moonwalking when their speed on the path is much lower than the animation speed. I think this says it all...

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
• [color=rgb(51,51,51)][font='Trebuchet MS']

### Graphics quality and coherence - Quality means quality in the type of graphics that you chose. It can range from even really simple pixelart to high-res rendering as we use in EiR, but it has to be nice, and above all, the whole thing has to be coherent. Sounds obvious, but apparently not always it is.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
• [color=rgb(51,51,51)][font='Trebuchet MS']

### Visual feedback. Be Newtonish : For every action there is a (...) reaction. Skipping the "equal and opposite" from the quote, still goes to the point. Everything needs visual feedback, also small details. Takes longer to implement them? Well, you aren't going for speed if you are reading this, you are aiming for quality. Example, the arrow hits an enemy? Show blood, make the enemy skill blink in red and/or shake a bit too etc. A catapult hits in the middle of a crowd of enemies. Is blood enough? I went through it, and nope, it couldn't look any faker if you don't "shake" the units too, pushing them in the opposite direction of the impact too. The enemy dies, should its sprite just disappear or are we going for a decent even if short death animation? You answer.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
• [color=rgb(51,51,51)][font='Trebuchet MS']

### Proportions. What is the point of modelling really nice looking enemy units if then on screen they are 2 mm high? You want them a bit bigger, of course, to show off your graphics, but then if you make the towers proportional to it, they probably fill up the full screen and bye bye to playing the game. So what? An example (nothing new, Age of Empires got there much before). Make them disproportionate, but cheat the player's eyes with some tricks. An example we used is that the units are definitely larger than the towers proportionally, but the doors of the towers, that is the element next to which it will be possible for our eye to do the comparison, have the same proportion as the units. Believe me, a simple trick like this does miracles already.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
• [color=rgb(51,51,51)][font='Trebuchet MS']

### Audio - This is quite sensitive as well. Enough audio is vital. Too much might be annoying. True, a battlefield is a loud chaotic place, but don't you think that too much sound would rape the ears of the player. Go instead for a smarter balancement. Try a simple trick we are implementing by using 3d sound on 2d game. Camera all zoomed out, lower sounds, some of them (like the dying of a unit), you can probably silence completely. Then when you zoom in, localized sound gets louder (only for the area of interest). Requires some tricks to simulate in 2D but nothing that can't be done (hint, create a probe object that moves around according to the camera).

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
• [color=rgb(51,51,51)][font='Trebuchet MS']

### 3D Prospective in 2D - This is a painful chapter, one of the ones that requires more thinking and has a larger impact on the results. First of all, you are simulating a 3D-ish world on a flat plane, every single detail can immediately make your scene look like a drunk Picasso drawing, and not one of those that got famous.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]

1. [color=rgb(51,51,51)][font='Trebuchet MS']

### First of all. Depth-buffer. If you don't plan to simulate this, don't even start. The game elements "lower in the screen" will have to be in front of those "higher in the screen". Might requires some painful tuning for each sprite, but you can't skip this. Forget about having your terrain all in a single image, unless it is a flat surface with no props or stuff. Depth is vital for the brain.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
2. [color=rgb(51,51,51)][font='Trebuchet MS']

### Remember that speed of movement has to become "perspectivized". In simple words, if you want a realistic behavior, the on-screen vertical movement speed has to be lower than the horizontal one. Just a bit of map will do the trick, but don't ignore it. (I mean, if you have circular areas of effect that get squeezed into ellipses due to perspective, wider than higher, shouldn't the units employ the same time in crossing them vertically or horizontally? food for thought, but yes they should).

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
3. [color=rgb(51,51,51)][font='Trebuchet MS']

### Projectile trajectories. Here comes the math. This can sooo easily look wrong. They need two things, rather three things. First, write the formula for the real 3D trajectory (usually a parabola does the trick well enough). Second, transform the formula from 3 dimensions to 2 dimensions (ain't that nasty if you have hold of the math for it). Third, make the projectile realistically alive : change the rotation according to the trajectory, and play with the size. An object closer to the camera should look bigger than one further from it. This last trick, if well managed, can give a lot of realism to the effect.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
4. [color=rgb(51,51,51)][font='Trebuchet MS']

### You're not in a lovely 3d environment taking care of generating all the shadows nicely by himself. But you need shadow to avoid the game looking flat and fake. How to solve it as 2D sprites don't seem to like to project shadows on other sprites? Simple, you have the shadows on the sprites, but (huge BUT here), remember this : your shadows will not bend and model themselves after the terrain and other sprites, so KISS (keep it simple and stupid, not KISS like in Rock'n'roll all nigh and party every day). Small smooth shadows might be less impressive than longer thicker ones, but will have a much higher flexibility in adapting to the 2D scene.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]
5. [color=rgb(51,51,51)][font='Trebuchet MS']

### This is important. By implementing a 3D world in 2D you are "cheating", remeber this. Cheat coherently and thing on gameplay. A couple of degrees changes in perspective among some elements might not invalidate the graphical look of the scene, but might do miracles for the gameplay. One example, our towers perspective has a slighly different view angle than the map. Why so? Because if they had the same, our towers would look too "tall" and hide too much of what's behind them. This is a very sensitive part that is usually solved by testing directly and validating visually.

[/font][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS']

### Now, well, I don't feel like I unveiled any absolute truth, but i hope it might be a decent thinking guideline for someone approaching for the first time the problem.Much of what i described can't yet be see (we worked so far for some months on the core engine, and that's something you don't see until you play it, and we think we're doing well on that), but believe me, is the topic of endless brainstorming and talks between me and the graphics artist, cause everything is being built according to those guidelines i defined above and more.

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

[indent=1][color=rgb(51,51,51)][font='Trebuchet MS']

### Cheers,H

[/font][/color][/font][/color][/font][/color][/font][/color][/font][/color][/font][/color]

## It might not be the beginning, but it is a beginning.

Empires in Ruins was born one evening of three years ago in front of a roasted chicken and a beer, in my dining room in Tallinn. Outside it was around -20 degrees, no less than 50 cm of snow and the wind, man the wind!

It all begun when I and my good friend and 3D modeler, that for storytelling ease will be from now on 'G' - me about to begin my PhD in IT and he doing freelancing jobs - decided that there where probably more interesting and creative ways to employ the skills we had learned.

Much water has flowed beneath the bridge since that frozen winter evening...

The game that was born as a Motorcycle Club managerial went through a lot of transformations even before starting getting anything more than a post-dinner idea, and life with it.
G left Tallinn and found other jobs around the world and i got completely sucked in by the PhD nightmare and freelancing here and there in Scandinavia on projects related to my studies (virtual reality, stereoscopics, kinect&leap motion, touch screens, etc).

It was two years ago that I slowly started getting back again to the idea of the Game.

First of all, I am extremely afraid of games. The reason? First two years of university, now almost a decade ago, where basically spent playing hours and hours to games when I was not going to lectures or going out for the weekends.

Even before that, I remember when my father had to hide the floppy disks of Monkey Island or the whole Amiga keyboard to avoid me spending my whole childhood trying to get Guybrush to glory -the drama was at the end that Monkey Island I had an error on the floppy when you go to Stan's to face LeChuck with the root beer, and Monkey Island II had an error on the 11th floppy when you are in the place where you have to use the dance to open the passage, but this is another story.

Don't get me wrong, i love games. I think that if a game manages to capture so much the attention of a person as some of them did to me (and likely to other several millions of people), the author is more than a programmer, the author is closer to an artist and a genius.
Being so busy and being so afraid of spending hours and hours playing (that is awesome but can be productivity-wise a bit limited), i abandoned full games some years ago and, aside from a few temporary but brutal relapses I decided that the only ones i could play where browser games. Some can still be quite addictive, but nothing compared to a Civilization, Tropico or GTA:S.Andreas (jut to mention some of those that took the biggest toll).

It was then that I discovered Tower Defence games. I don't even remember which one i played first, but i soon became a TD addict, luckily avoiding to spend a full weekend playing them, but believe me, I spent quite some time on then.

In the while the idea of making a game never abandoned me, but I never even managed to realized it. Then, 2 years ago, one day I woke up, downloaded Unity3D and decided to learn how to use it by making a Tower Defence game. At first it was just spheres moving on a 3D path, then one day I wrote to G to check how busy he was. It turned out he wasn't too much, and the first Empires in Ruins begun. It was not even getting too bad, but you know how it turns out the first time that you develop a software of a certain type...the mess, no discipline in design, learning by doing, etc etc.

Not only that, but we needed to keep on freelancing to pay studies and life, and the game slowly faded away. One year later, approx one year ago, we made up our minds, made a plan and begun again. And EiR underwent another transformation and became a 2D game for a long series of reasons that I will explain more in details in other entries of this journal.

And that how it begun, and as this time it was a completely different story. Disciplined, modular, clean code, hires sprites obtained from 3D models ,etc etc. I think I will have time soon to talk about the details. In the while, check our galley if you see more about the actual state of the game, and take a look at this to see a mini-teaser of the game in action.

If you got to read till here my delirium, respect, and see you next time (soon).

Cheers,

H of H