Lead Developer, Stardock Entertainment
Published on November 13, 2009 By CariElf In Elemental Dev Journals

We actually made a fairly major change to the code this week so I thought that I'd actually write a dev journal about it: CodeCritter and I gutted the movement code and re-implemented it.  For the developers out there, that meant creating a branch which generally makes me a bit nervous because I always worry that merging the branch back into the trunk is going to go poorly. But making a branch was essential in case it took us longer than a week to get the code to the point where we could subject others to it.

I'd actually implemented code over a month ago that prevented a new turn from happening until all of the units (including AI units) were finished moving, but it took forever even for the very first turn when there weren't a lot of units.  I did some investigating, and eventually found out that it was just that the movement code was really inefficient.  It was moving all units pixel by pixel, even the ones that were offscreen or under the fog of war.  Besides taking longer, this meant that it was hard to catch targeted units because they were moving at the same time as their pursuers.  It also didn't check to see if a tile was blocked before a unit moved into it, so if you decided not to attack another unit, you had to be moved out of the tile.

Now, the developer who coded this is not a bad coder; he's actually one of our best developers. But this code was written in the VERY early stages of engine development, probably before we started working on Twilight of the Arnor, and certainly before we even had the concept of game turns in the engine.  Sometimes you have to get code roughed in and move on to other stuff before you can come back to it, particularly when your betas are more like alphas.  Also, it wasn't really bad code.  It mostly just wasn't scalable.

At the time, I couldn't start work on fixing the movement code because I had probably 5 other critical things to work on and I knew that it would take at least a week to fix the movement code.  So I had to comment out my code that made the new turn code wait for all the units to start moving, and put in code that just checked for the local player to be done moving.

So while I was working on other stuff, I kept the movement code on the backburner of my mind.  It was probably actually a good thing that I had other stuff to work on because you have to do a lot of thinking before you can start coding something this critical.  I'd done the moving code for all of the GalCiv titles (1 and 2) so this wasn't new for me, but frankly the movement code for the GalCiv games sucked.  Those of you who played any of the GalCiv games probably remember the stuck turn button bug.  The main problem with the movement code in the GalCiv games, especially by the end of Twilight of the Arnor, was that it was too complicated.  So I needed to come up with a design that was fast and simple and scaleable.  I actually came up with the design while I was getting ready for work one morning, proving yet again that the best design is done away from a desk. 

In GalCiv2, ships that were off-screen or under Fog of War were teleported from tile to tile until they ran out of moves or became visible.  This was definitely one thing that I wanted to do in Elemental, but it had always bothered me that there were 3 different movement functions in GalCiv2: Move, QuickMove, and Teleport.  (QuickMove actualy called Teleport), and there were 6 different collision detection modes: pathfinding, move check (before moving into a tile), move, (on moving into a tile), quickmove (when calling QuickMove, was kind of a combination of move check and move) and teleport (used by Teleport and was just a check to see if you could teleport or if you need to fall back into moving pixel by pixel).  That was way too complicated, and every time we made a change to the moving code, we had to change it in 3 locations. 

My idea was simple but elegant: What if all the units used the same movement code and then if they were on-screen, have the graphics animate them moving, otherwise just teleport them?  I bounced the idea off of CodeCritter (who is our graphics engine guru), and he thought that it would work and agreed to take care of the graphics code side of the problem.

The first thing that I did when I started working on the new movement code was re-enable my code to force the turns to wait for all the units to stop moving.    That way, I'd be able to tell if my code was doing what it was supposed to do: going faster and not making the turn button get stuck. 

Next, I created a static variable in the base mobile object class, g_bQuickMoveAlways.  If true, it would just move the units from tile to tile (rather than pixel to pixel) whether or not they were visible.  This will be a good option for multiplayer, and it made it easy for me to test. 

Then I just had to look at the existing moving code.  I copied the existing function, renamed it, and started stripping out anything that had to do with graphics or animation.  I also broke the code that actually handled moving into a tile into its own function, to make it really clean.  All I had left to do was make sure that the unit actually did a collision detection before moving into the tile.

This was actually the most time-intensive part of the operation for me.  I had to go through all the different kinds of objects (units, goodie huts, improvements, etc) and make their hit detection functions handle two modes, MoveCheck and Move instead of just Move.  For most of the objects, this was fairly simple, but the units have to check to see if they're going to attack.

At this point, I realized that I was going to have to work on more than just the movement code.  We'd been planning on making it so that you have to be at war with the owner of another unit before attacking it, but that required interface code we didn't have, and player relations code that we didn't have, so units could attack at will.  I had two choices: hack something in so that it would work and change it later, or start laying the groundwork for the real code.  I decided that it wouldn't take me that much longer to write code that wasn't a hack, and it would save me the trouble of having to rip out the quick hack later.

There was rudimentary player relations code in that was based on GalCiv2's relations code, but it was missing some key concepts.  It didn't have checks to prevent your relations from improving from being at war to being merely hostile.  It didn't have checks to prevent your relations from just dropping into war, instead of requiring the player to declare it.  It didn't have a concept of being permanently at war, which we used for the pirates and Dread Lords in GalCiv2, and space monsters in GalCiv1.  I added all the necessary checks, made some wrapper functions for checking to see if you were at war with another player or if you were allied with them, and went to work on the existing DeclareWarOnPlayer function.

The DeclareWarOnPlayer function was just setting your relations to being at war, and it was only doing it on one side.  So you could declare war on the AI, but they wouldn't be at war with you.  It also wasn't moving all enemy units out of the territory.  So I made the war declaration mutual (easy) and started working on the problem of moving all enemy units out.  The same code in GalCiv2 was very simple, it just looked for the first tile out of enemy territory, which might be 1 tile away.  This was pretty cheesy and ineffective at preventing sneak attacks.  So in Elemental, I send the units to the nearest city.  However, what if you have no cities?  While I figured that this probably wouldn't happen very often, I had to account for it. 

Luckily, each player keeps a list of all objects that they know about, including forests and mountain ranges.  So all I had to do was go through the list and move them to one that wasn't on a tile owned by the enemy player (or someone you're not at war with). 

My next problem was that I had no interface for declaring war.  So I made it so that if you right click on a unit, it would pop up the prompt that asks you if you want to declare war on that unit's player. It's kinda lame, but it gets the job done and even after we get the interface in, it might save you some clicks.

So now that you had to be at war before attacking another player, that made it much easier to finish the unit movement code.  If a unit tried to move into a tile with another player's unit that was not its destination, it would be blocked and have to re-calculate its path.  If the tile was its destination, it would bring up the declare war prompt. 

If the unit passes its collision detection check for moving, then it moves into the tile and calls the collision detection with the mode set to Move and performs any necessary code like merging armies, collecting the goodie from the goodie hut, etc.

I was now ready to test.  I loaded up the game and started moving my sovereign, and building units. I had to tweak the code a bit as I caught bugs that made units get stuck, and the attack code needed to be tweaked a bit since attacks were now initiated before the attacker moved into the title.  Once it seemed to be working as it should be, I committed my changes to the branch and let CodeCritter start working on the graphics part of it.

While CodeCritter was changing the code to only move the unit model smoothly (as opposed to teleporting it) if it was visible, I worked on a few movement bugs that were now easier to fix after having rehauled the movement and collision detection code.  The first bug was that if you built a city and your sovereign had no moves left, he would neither move off the city tile nor be stationed within the city.  This was a quick fix, as he just wasn't being added back into the list of moveable units after being given another move to get him off the city. The second was that units leaving a city didn't do any collision detection on the tile that they landed on, so they wouldn't automatically form an army with another unit, or get the goodie from the goodie hut, etc.  Since I had my new handy MoveToTile function, I just made it use that instead of setting its position on the tile directly.

CodeCritter and I merged the branch back into the trunk Wednesday night, which mostly went smoothly.  We both nearly had heart attacks when CVS told us that we needed to update before commiting our changes, which meant that someone had checked in code after we'd started the merge.  I started shouting death threats and CodeCritter put his head in his hands, but we only had 3 minor merge errors to deal with so I didn't actually have to kill anyone. 

We're still tweaking the movement code so that the units move smoothly while on screen at all zoom levels, but we've made huge progress. Since the code is now much simpler than our movement code has ever been in any game, it should be less prone to cause bugs like the stuck turn button.

Anyway, I hope that I haven't bored all of you to tears.  I've been very excited about this new code, so I just had to share.  

 

 

 

 


Comments (Page 4)
on Nov 26, 2009

It all depends on how "conflict" would occur as well. The point is to not allow total destruction of an opponent on a sneak attack. If you were able to completely disrupt your opponent's ability to wage war on a sneak attack, when you would not have been able to do so otherwise, it is an anarchistic system. Therefore I would suggest that troops garrisoned in Cities should also be unabled to be attacked (other than simply disallowing a "city capture" to also disable attacking a city at all, in any way). This could represent a government's unwillingness to target the enemy civilian population before full-scale war is declared. (Only assasins could target troops within cities, and even then only very specified targets (you tell the assasin the parameters under which he selects his target, and then he goes after the weakest soldier/unit that fits the parameters, unless you specifically directed in your parameters to targer the strongest within applicable group) and even then an assasin cannot target the last troop remaining in a city. (so you can leave one person/unit in the city, and field your army, yet risk losing your army without support from that person or unit).

If however, you could use "conflict" to Von Claussevitz' type of destroying their main forces with your main forces, at any time during the game and under no special extenuating circumstances, then you will see a largely anarchistic world.

Usually, people can attack at any time, therefore its largely an anarchy where anyone can declare war at any time. However, with certain restrictions in place there can be at least a some-what sense of order. Civilized peoples were rarely in times of complete anarchy where war was constantly re-declared. To semi-represent this trend, a restriction was placed in Civilization that required most trade deals to be followed by 10 turns of mandatory peace. Im not saying that abritrary restrictions have to be in place in order to have a playable game ... but it makes for a game with better gameplay, to not allow cheap exploits which "cheapen" the experience of playing the game.

on Nov 26, 2009

The point is to not allow total destruction of an opponent on a sneak attack.

Well, I want to be able to do that. If a player can see your units and lets them near all its cities when you pretend you're sending them all to someplace and obviously your units aren't going there, then he deserves what's going to happen.

If the ai can't be coded to avoid that, then sure take counter measures, but don't have them prevent simple things like attacking the city on your border until the opponent had 5 turns to bring in reinforcements.

Also, I'd rather have the sneak attack a possibility with drawbacks rather than just denied. For instance declaring war with someone with whom you have a right of passage would cost you a lot of prestige. Cancelling a right of passage when you have units in their territories would cost a lot of prestige. As a result, people wouldn't flock to yoru cities and would likely leave them (you're an untrustworthy tyran after all), and other nations would see you for the untrustworthy traitor you are and never agree to rights of passage with you again.

 

Being unable to declare war for a time after a treaty is totally different in my book and perfectly acceptable. Probably even needed for the ai in most cases.

As for anarchistic periods, about all of Roman history except for a century or two were rife with civil wars and factions fighting each others, kingdoms declaring war as soon as the previous king died, etc.

on Nov 28, 2009

I am fine with the 'port 'em out mechanic for now. I'm actually of the hopes that the AI will allow this code to be removed at a later date.  "Yes, we have a right of passage,  but you moving that mammoth army towards my capital is totally unacceptable."  Even better if the AI does it in  some sort of United Nations meeting.  Severe diplomatic drawbacks to violating treaties should be doable with the experience stardock has been getting with AI's.  The biggest one would be that no one would sign treaties with you.  It is the reason you don't do things like this (at least not and get caught) in the real world.  Fear of a permanent and massive backlash by the other AI's and even players would prevent you from forming treaties in the future, and probably throw you into a permanent war with several other factions at the request of the offended party.

 

This leaves only the late game when it is just you and a couple opponents, or maybe even just one.  At this point the AI should just flat out refuse right of passages for troops.  Because the AI should know that there would be no real reprocusions to violating your word.  

 

Porting all of a particular factions troops out of  your land if they attempt hostile actions against you would make a GREAT defensive spell.

on Nov 28, 2009

I suppose the real question is ... if your setting up such an obvious sneak attack, and the opponent knows about it, what options do they have? If your troops are already in their territory then its too late right? So what are they supposed to do, declare war upon you?

I think there should be an option of "Eject Player X's troops from our borders" option. Is the only possible defense vs sneak attack, which is ALMOST like declaration of war = troops teleport out, although its up to the defender to do such a thing, and it has to be done during peacetime.

Actually I like this idea more and more. At any point in time during a turn you can immediately expell all forces of Player X from your borders ... so long as there are still peaceful relations. So if you move too many troops through an AI's territory they will expel you (or if you move too close to their cities)

Im not saying that there shouldn't be ways to perform a sneak attack, but a sneak attack should be the exception, not the norm. You should provide some significant investment to perform a sneak attack, something significant in both single player as well as multiplayer. (like following a Shadowy cult/Assasins Guild)

on Nov 29, 2009

If your troops are already in their territory then its too late right? So what are they supposed to do, declare war upon you?

Yes, declare war. Probably declare war before they reach your heartland. A good way to simulate that would be to provide open borders only through certain parts of your territory, like through a corridor leading to common enemy land rather than through all the territory. It might be painful to draw the corridor and would need some uithinking but it could be interesting.

Also, sneak attack would be exceptional as noone would trust you again afterwards so you'd never get another open borders agreement.

on Nov 29, 2009

Also, sneak attack would be exceptional as noone would trust you again afterwards so you'd never get another open borders agreement.

 

This is exactly what I mean.  A spell that ports enemy troops out of your lands I think would be a much more fun strategic option than automatically porting them out upon war declaration.  I think we are all sort of thinking back to the broken AI of master of magic, where little hobo armies from every other wizard wandered randomly through your territory.  I think it is safe to expect no such issues.  I did have another idea.  "your territory" has the potential to be rather encompassing in this game as we have seen so far.  Perhaps "vital territory" and "non vital territory" could be flagged for this purpose?

Vital territory would be any area within striking distance of one of your cities.  Also, since your essence is imbued into the land, it is logical that your troops might find the terrain more hospitable, and quicker to travel on than your enemies don't you think?  

Other ideas would be "laying siege' to a town before you are able to assault it, giving the defending player a few rounds to rally some defenses. This has alot of historical merit, and would prevent the sneak blitz provided the defending player is strategic enough to have a sizable army close enough to bolster any of his cities.  Preventing the need to have a huge army at EVERY city, Just a few here and there garrisoned in case of attack.

on Nov 29, 2009

This was pretty cheesy and ineffective at preventing sneak attacks.

Cari, sneak attacks Are going to be possible in Elemental, right? They better be, or at least they Should Be. Betraying a Alliance or Non-Aggression Pact at a key moment can be a very effective Strategy. It may be dirty and underhanded, but if yours is the only nation left alive after such a tactic is employed, it's you writing the history books anyway. If some kind of sneak attack isn't available in Elemental I think the game will be missing a big chunk of strategic depth. It doesn't necessarily have to be a sneak attack that has something to do with when you declare war though. It could be a lot of things. Maybe turning a army invisible for a short time with a spell, or by casting a very high cost teleport spell at a magical warp location to send a army to a enemy city.

Being able to decide to betray a alliance while your armies are in the target land though should still be a option Without it automatically teleporting your armies out. When you give another Sovereign permission to move a army through your land you'd be pretty stupid if you didn't keep an eye on that army and always be aware that betrayals Do happen. Though if it's a Sovereign you've had alliance with for hundreds of turns/years, then the chance for betrayal should be low. The stronger the alliance, the less chance they'd betray you. If your families are intermingled, you share bloodlines and trade routes and your population is intermixed and has been for years, that faction would almost never betray you. If it's a Fallen Empire who's often betrayed his allies, then the player would have to be very cautious when allowing a alliance or pact for them to move armies through your lands. This adds a lot of depth to both strategies of where you move your armies and to diplomacy because you have to think about the mentality and habits of the Sovereign you're making alliances with.

on Dec 02, 2009

It's a nice thing to be able to share the inside creation of a game. And given your account makes me part of it all.

 

Keep wrinting it's really nice

on Dec 03, 2009

At the very least we can probably turn off the teleportation code for multiplayer games.

on Dec 04, 2009

Well, in Fall From Heaven, sneak attacks were possible, but only by factions that met certain requirements. In this game there are seven Guilds* you can join. And if you join the Guild* council of Esus, you can perform a sneak attack at any time. Also, if you follow the Guild of Esus people don't see, and theoretically can't tell, that you are following that guild.

Also, if you have the guild headquarters, you can see all troops stationed in any city that also contains the guild. The guild also gives special benefits to Recon units, like rangers and assasins. If a recon unit specifically follows the guild, then they can "mask" themselves in order to pretend they are a barbarian unit. Now, this might not mean a whole lot in small numbers ... but with enough units with mask (or the Svartalphar whose worldspell turns all units HN), you can use it to gather all forces next to an opponent's hero and kill him off without declaring war. These masked units, however, cannot capture cities. Therefore you would have to declare official war in order to take his cities. The attacked player must make the choice of waging war against the felon, or to simply try to cut their losses .... since after all, a giant army of their opponents is freshly in their borders, and perhaps they still want the flow of trade routes, and perhaps you could still kill their army before they unmask ... so many things to consider. Anyways, I hope something like this is used instead of disabling auto-teleport. In fact, I kind or prefer auto-teleport at war declaration for most/mundane circumstances. I also like how units move slower in enemy territory (cannot use enemy roads) ... EXCEPT* for nations that have invested in the Raider trait, which grants most units the ability to move on roads (seige units like cannon and catapult never have this ability, however, and are extremely limited in promotions in general)

So yes, there is a Guild which allows for all-out sneak attacks, and their is an ability for a group of units or an army to temporarily act as if they are barbarian (always hostile to all nearby units**)

*=for the faint of heart

**= always hostile will not attack your own units, nor will they be hostile to team-mates, AKA people sharing your research and line of sight.

on Dec 04, 2009

Now that I think about it however ... it would be a GREAT idea if we could get Rites of Passage to be extremely specific. Aka, "you are only allowed to march along this dotted line or you declare war on my by default!" kind of thing.

 

Also, keeping trade relations Seperate from military passage would also help. Civilization unfortunately kept them both in an all-encompassing "open borders"

Meta
Views
» 14007
Comments
» 56
Sponsored Links