Lead Developer, Stardock Entertainment
Published on September 24, 2010 By CariElf In Elemental Dev Journals

It's been awhile since I've written a dev journal and we've got some new faces around here, so I'll take the opportunity to introduce myself. I'm Cari Begle, and I'm Stardock's Senior Game Designer and the programming lead on Elemental.  I've been working here at Stardock for 10 years.  

Today I'm going to talk about Multiplayer.  I'll start with a quick rundown of the features for the people who haven't tried the beta,  and then get into some techie talk for those of you who like to peek under the hood.

Elemental is true client-server where we host the servers, rather than the host player's machine acting as the server (which is a modified version of peer to peer) or true peer to peer where all the clients are connected to each other.  This means that shouldn't need to open ports, and if the host player drops, the server picks a new host and the game can continue.  

There are two multiplayer modes: quick match and custom games.  In quick matches, you choose either 1 v 1 or 1 v AI, pick your sovereign and faction, and you will be matched with another player on a randomly chosen map. In custom games, the host picks the world settings and how many players and then waits in a lobby for other players to join by clicking on the game entry in the available games list.  

With 1.09, we're enabling multiplayer save games for custom and 1 v AI games.  Only the host can save, and the game also auto saves periodically. The save games overwrite, so there is only ever one save per game, and if a host player quits or disconnects before the end of a game and the new host saves the game, the original host's save game is removed so that the new host is the only one with a save for that game.  Save games are also automatically removed when the end game results are posted.  Save games are saved to the cloud, so they can be loaded from any computer as long as you're logged in as the player who saved it.  

In order to help you out at the beginning of a multiplayer game, you start with a spouse.  Also, all the multiplayer maps have gold and fertile land placed around the starting locations of the players.  If you let the game pick the map randomly, it will attempt to pick one that has enough starting location for all the players, but if you open up additional slots you may need to return to the world setup screen to pick a new map.

All battles are instant battles like in Civ5. We won't be enabling tactical battles in multiplayer until after they've been revamped.

To chat, hit the quote/single quote key.  Currently, it only supports chat to all because I need a better dialog for it with tabs or something. 

Multiplayer is interesting to code because you can't simply do something, you have to send a message and wait for the response so that all the clients stay in synch.  This means that you can't code linearly, and you have to handle not receiving a response.  It's much like programming a multi-threaded application, except slightly more complicated because you're sending and receiving data from other computers, not just other threads.  It requires you to think a different way when writing your code, and unfortunately most schools don't really do a good job of teaching this, even the game development schools like Digipen and FullSail.  At least the graduates from game dev schools generally have more practical programming experience than schools with a traditional computer science degrees.   

Say you want to move a unit to a notable location.  If you were only concerned with single player, you'd simply translate the coordinates of the right mouse click to world coordinates, set the destination so that the unit can calculate a path, and boom, it starts moving as soon as the path is calculated.  In multiplayer, there are more concerns.  

To start with, every object in the game that is not purely cosmetic has to have the same ID as the corresponding object on the server and other clients so that it can be identified.  This allows us to send events which can originate either on a client or the server with the data needed to perform the desired action, and an identifier in the event to indicate what the action is.  When the event is received by the server, it processes it and either marks the event as failed or succeeded and in most cases forwards it to the clients to be processed. In some cases, like when the player requests a new turn, we just want to notify the server and not forward the message to the other clients.  Then when all the players have requested a new turn, the server sends out an event notifying the clients.  When the server or clients receive an event, they use the data stored in the event to access the objects that sent the event and perform the action that was requested.

For example, if Unit A attacks Unit B, I create an Attack event and store Unit A's ID as the attacker and Unit B's ID as the defender.  The event is converted to a block of bytes and sent out to the server.  The server restores the event from the block of bytes and gets pointers to Unit A and Unit B.  If unit B isn't already dead from a previous attack, the server performs the attack and stores the results in the event, which it forwards to the clients.  The clients receive the event, get pointers to A and B, and process the battle results (brings up the results screen, levelupwnd, etc). Now, since turns are simultaneous, it's possible that Unit C may have also tried to attack Unit B but was a little slower and so its event arrives on the server second.  If Unit B is already killed, the server simply marks the event as failed and forwards it on to the clients so that they can handle the failure.  Otherwise, the event is processed normally.  

Well, I've stayed up working on this journal later than I intended, so I'm going to call it a night.  






Comments (Page 4)
on Sep 27, 2010

untimate elemental wrote: 

"Thanks for the update.

I hope multiplayer won't suck up too much of your resources.

The main thrust of the game is single player and their are still bug fixes (out of memory crashes), ui improvements, ai improvements and balancing issues + magic system improvements + combat system improvements that need to be done. I hope those areas get the most focus going forward."


I wholeheartedly agree:   And I hope frogboy reads this.  I would especially like to see the tactical system fixed via some sort of:

Primary quick fix = each unit moves/attacks/fortify /casts/etc. based on its individual initiative relative to all other units in tactical screen.  This replaces all of one side's units 'acting', then all the other side's units 'act.'    The number of action points = number of 'moves/attacks/casts that unit may attempt.  Initiative is how quickly the unit will decide, if enabled to act, and begin using that turns action points.  Action points = how 'much' a unit can attempt.  Initiative = the sequence  in which it may begin 'moving/acting/casting/fortifying' relative to ALL other units on the battle screen

Then, perhaps, address fixing the tactical system completely:

1. bow attenuation = attack strength that decreases as range to target increases, each bow type has max range.

2. casting time as related to complexity of spell and Magic user's current level.  The length of time to prepare casting spells may be shortened based upon how  much the caster's current level exceeds the level of spell being cast. Example:  Level 5 caster casts a level 2 spell much faster that casting a level 4 spell, etc.

basic commandsMove = unit attempts to move towards selected square.  Attack = unit attempts to attack enemy unit. Fortify = unit attempts to fortify in current location (must currently have fortify skill from tech research).  Cast = magic user attempts to begin casting selected spell (which, obviously, must already be known by the magic user). 

New basic command: Follow and attack = melee unit attempts to close with the selected enemy unit and melee attack it.

conditional commands: are set of  'reacting' commands given to units that don't move/attack/fortify/cast.  These commands may be attempted by the unit IF the enemy does certain things.  Reaction commands may be given to appropriate units that are not given a basic command.

Melee charge unit moves towards and melee attacks first enemy that approaches within # squares. 

Missle attack = archery unit launch arrow volley against first enemy unit that closes distance to set # of squares.

Missle counter volley = Archery unit fires back at enemy archers that fire on it. Decisions for player: do you want your archers to fire back at other archers?  or save their arrows for a possible melee against themselves and/or nearby friendly melee units they are supporting?)

Skrimish away = unit will move away from approaching enemy so as to maintain a specifically chosen # of squares between it and 'approaching' enemy unit, and generally towards the 'friendly' side or nearest friendly unit. Unit always saves enough action points to melee the first enely that moves adjacant.

NOTE: This eliminates the massive, and game unbalancing 'which side moves ALL its units first in battle' issue.

other comments: perhaps a particular units initiative might be 'increased' based upon physical nearness to senior commander in battle (SOV, heirs according to place in line of succession, tactical commander (new unit/skill not made yet, like administrator/farmer/miner).  Also, this system would create a real use for 'rockslide spell, etc.  This basic system would not need the develope to create 'facing' for units. 

Run away, conceilment, etc would be great to add on, but only when facing for units is (hopefully) added.


on Sep 27, 2010

Will custom sovereigns and custom factions be added into multiplayer at some point? The customization features are such an integral part of this game, it's really a shame if they were to be left out of multiplayer!


Carielf, what's the point (in terms of amount of gamestate information) at which you have to ditch something like a client-server model and implement a simultaneous simulations model?

You can do a simultaneous simulation using client/server for the network code, because you're still exchanging data to make sure that you're staying in synch.  Client-server just refers to how that information travels. Peer to peer or modified client-server where the host acts as the server (which is a form of peer to peer) just means that you don't have to have dedicated servers.  

how about this for the multiplayer:

The turns themselves are on timer (configurable)

but, there is no 'Pass' or 'End turn' button.

The time flows normally... you decide what to do with your time... move or wait and plan....

So if you want to sit and stockpile resources, just wait... 

if you want to move, attack, conquer, cast magic, you have an allotment of time (yes, real time)... 

That way, the server counts down, and then renews all resources at once... 

That will have to change your approach (server will not be able to determine who attacked who first - and resolve that, the clients will do that - Peer to Peer, with server only marking who won [died] and who is still alive at that location [giving the new attacker quite a surprise]).

That opens a lot of new possiblities, such as sneaking on opponents (if you have an invisibility spell.... ), waiting for the last second of a turn in order to ambush a weakened opponent after a series of fights and more... 

I find this idea very appealing and in the spirit of Elemental:War... 

What do ya think?   

We would not have to change to peer to peer for automatic turns.  The network model is independent of game mechanics.  That being said, I don't think that this would be less annoying than having a turn timer that is started by the first human's turn.  

ElanaAhova (and this also goes for everyone else too), please don't hijack people's threads.  That goes for any of the developer's threads or other users.  It's hard enough for us to sift though everything without having people reply to a thread and start talking about something completely different. 


on Oct 03, 2010


We would not have to change to peer to peer for automatic turns.  The network model is independent of game mechanics.  That being said, I don't think that this would be less annoying than having a turn timer that is started by the first human's turn.  

Can't agree with that. This is the most annoying system I've ever seen in my life. Not all turns need to be the same length, depending on what I'm doing. When I get one of my short turns (units are on the way to X, towns are already building, not a lot needs doing), I can effectively grief the other players by simply ending my turn instantly and block them from doing almost anything even if they happen to need one of their longer turns (setting up buildings, making units, combat, etc).

And if co-op play existed, it'd just force me to not end my turn at all until my teammates are ready for me to, because I don't want to stop them from doing stuff.

on Oct 05, 2010

We've added in options to turn off the timer entirely and a slider to increase the turn time. They're currently only on the options screen under game options, but we'll probably be adding a multiplayer options screen to access off the world setup screen at some point.

on Oct 07, 2010

We have been playing MULTI GAME several times by 4 or 5 ppl.
1.09b is more better than 1.08b.

BTW, we may not often notice that a turn has already begun.
We'd like to see message "Turn xxx start" in every turn.


on Oct 07, 2010

We have been playing MULTI GAME several times by 4 or 5 ppl.
1.09b is more better than 1.08b.

BTW, we may not often notice that a turn has already begun.
We'd like to see message "Turn xxx start" in every turn.

We've also added a turn start message.

on Oct 08, 2010

Thx CariElf !

on Nov 28, 2010

there going to be LAN?