View topic - ANN: Spring fork starting development


All times are UTC + 1 hour


Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: 31 Oct 2012, 09:33 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
Thought I'd let you guys know about a project I'm undertaking. I've mentioned before I'm working on a game, and have been for a few years now but time constraints have been a huge issue.

Because I regularly have to stop and start, sometimes weeks or months apart, I keep finding the Spring codebase has changed and generally in a different direction to my requirements. I've also changed my requirements recently to require support for 100+ player persistent games (MMORTS) and non-x86 client platforms like Android, iOS and WebGL.

For that many players and platforms to ever have a chance of working I have to ditch Springs' peer-to-peer synchronisation model and switch to a traditional client-server model. It's worth noting at this point that peer-synced sims have a historical justification due to bandwidth restrictions. Age of Empires was the first game to openly use the technique and it was developed in 1997 when 28.8k modems were still common. Given that a typical internet connection in 2012 is approximately 50-100 times faster than back then I don't believe the bandwidth problem is as critical as it once was.

There's a really good article on the tech here. It includes a quote from an AoE programmer that goes: "A few quick calculations would show that passing even a small set of data about the units, and attempting to update it in real time would severely limit the number of units and objects we could have interacting with the player. Just passing X and Y coordinates, status, action, facing and damage would have limited us to 250 moving units in the game at the most. "

I can see how that was an issue back then but if we assume a conservative 50x speed for DSL vs 28.8K modem then (50 x 250 = 12,500). That means I can theoretically send data for 12.5K units per update and i've yet to see a Spring game come close to that for total units in-game let alone units visible on screen. In short I believe peer-synchronised RTS is a largely obsolete technology due to significant problems with desyncs under different client architectures, languages and compilers (32 vs 64bit, x86 vs ARM, Java vs Obective-C vs C++, VisualStudio vs GCC, etc).

I also plan to increase the time between "frames" by up to 0.5 seconds and let the clients handle animation and tweening in a way that fits their capabilities. That is to say the server will treat the game as turn-based and tile-based but clients are free to disguise this by faking smooth movement and projectile effects between states. The goal here is to recover some of the bandwidth we lost in the switch from peer-sync by removing some precision. In RTS precision and response time are typically not as important as an action game and I intend to exploit that. Players will notice a small delay between giving an order and seeing the correct outcome but in general the game will still appear fluid.


The planned changes are:


  • Complete seperation of codebase for server, clients and AI.
  • Game simulation to run entirely server-side (x86(64) only).
  • Clients send input to server and selectively render game updates based on their capabilities and needs. For example the client could request updates only for the part of the map currently in view. The server only sends updates for units in LOS for efficiency and cheat prevention.
  • AI to be implemented as remote clients, not compiled into server. As far as the server knows they are just another player and have the same restrictions with respect to LOS and updates.
  • Support for WebGL/Canvas and OpenGL ES2 clients (Mobile)
  • Simplification and unification of lobby and autohost protocols
  • Reworking of projectile code to minimise update bandwidth
  • Non-lua widget support. Clients can implement their own native widgets in whatever language they are written in (eg, Javascript). These widgets communicate to the server using the same protocol as used for player input and AI.
  • Remote OpenGL proxy. This will extend the work zerver has done on his GML rendering proxy (for spring-mt) to pass server-side OpenGL calls and assets over the wire to a client.
  • Remove FPS unit control. This has always been buggy and crap anyway but it becomes even more unusable when combined with my changes

I'll be disabling as defaults or removing some existing features from the default x86 client due to incompatiblity or code-bloat. I especially have my eye on things like offscreen rendering (LoadingMT=1) and some of the hardware audio effects code which cause issues on non-nvidia/creative hardware and/or low-end machines. Spring enables risky features by default to get more widespread testing but at the cost of some users being unable to play at all. I personally prefer stable releases to actually be stable and use beta versions for testing new features. I've crossed swords with at least one Spring dev in the past over this issue but our priorities are different. Forking means I can prioritise as I like without disturbing others.

Obviously there are too many major changes to support existing Spring games directly however I do plan to maintain compatibility wherever it makes sense. Ported games would need to rewrite their widgets as gadgets (or native widgets) and modify some incompatible assets but should otherwise not require a total rewrite.

Once I have a working alpha I'll give the project a name, post code on github and update this thread. This announcement is just a heads-up for anyone interested in collaboration, testing, advice, questions etc.
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 12:38 
Moderator

Joined: 05 Aug 2009, 19:42
SpliFF wrote:
For that many players and platforms to ever have a chance of working I have to ditch Springs' peer-to-peer synchronisation model and switch to a traditional client-server model. It's worth noting at this point that peer-synced sims have a historical justification due to bandwidth restrictions.
Just passing X and Y coordinates, status, action, facing and damage would have limited us to 250 moving units in the game at the most. "

That means I can theoretically send data for 12.5K units per update and i've yet to see a Spring game come close to that for total units in-game let alone units visible on screen.

Does one need to have an either/or scenario? Could you have both, and what would be the benefits/flaws of such a design?
What I'm thinking is, if you want to have clients in an asynchronous state towards most parts of the world, you could just synchronize them when needed, which would basically be just implementing a load/save mechanism, that is, a faster rejoin mechanism.
As shown in the below picture, imagine if your client would synchronize with the server (world) using only a part of the screen (green part), depending on what your client sees (blue part). If that green part would be much smaller than the whole world, f.e only a single planet in an MMO galaxy, or something similar in proportion, would it still allow a huge scale MMO while allowing for sync-level latency?
Image

In fact, in an asynchronous system, your clients are more or less synchronizing with the server by receiving updates, and initially they could be as large as the full synchronous update (depending on the map visibility).

Also, how does the fully asynch system scale up when it comes to long battles with a lot of clients involved? While you will usually never have 1000s of players, the EVE-size of battles (1k vs 1k) is something one could expect in an MMO RTS, probably even scaled up a bit. From what I recall reading about the way EVE works is, they don't even send some "basic" information to all the players, f.e the actual dmg and hp of ships you aren't targeting isn't known. You only see the hp and dmg of ships you are targeting, when someone starts/stops attacking or otherwise negatively influencing other ships, and that's that. And with only that much data, they tend to run into bandwidth problems often, which they recently attempted to solve by slowing the game speed locally (time dilation http://community.eveonline.com/devblog. ... og&bid=900). Still, I expect an MMORTS will also have to send data about hp changes for all visible units, which requires even more bandwidth, so I'm not sure how much an asynch engine can really scale - can we see some math (how often do you intend to send game updates)?

Btw, there is already an open source (engine) that has a server/client model, if you think you can get anything useful from it: https://skatgame.net/mburo/orts/.

Quote:
In short I believe peer-synchronised RTS is a largely obsolete technology due to significant problems with desyncs under different client architectures, languages and compilers (32 vs 64bit, x86 vs ARM, Java vs Obective-C vs C++, VisualStudio vs GCC, etc).

I feel you are tackling a different problem here. I'm not sure the benefits of having less to worry about desynchs will outway the added requirement to create and maintain a new engine for each of the different platforms. Besides, do you really need a Java/Objective-C version of the game, or will a 32bit/64bit difference even have any effect on the speed if your server is doing most of the computation, also not sure if the compiler really matters. The only thing that may be of importance is the x86 and ARM difference, and are you sure Spring (as it is) couldn't be made to compile and run on ARM? Do the libraries that ensure flops are executed properly work on ARM?

Going to try to interpret this as I understand it:
    Quote:
  • Complete seperation of codebase for server, clients and AI.

  • Pros: Cheating prevention, AI crashes don't take down the game. Clients and AI can easily be made in different languages as long as they support the specified protocol.
    Cons: Larger bandwidth requirement, slightly slower AI.
    Quote:
  • Game simulation to run entirely server-side (x86(64) only).

  • Pros: Easier to have closed source games. Game is less intensive for client CPUs. No need to use libraries that ensure cross-platform calculation correctness.
    Cons: A separate simulation (interpolation) code must be done on the clients, based on the server data.
    Quote:
  • Clients send input to server and selectively render game updates based on their capabilities and needs. For example the client could request updates only for the part of the map currently in view. The server only sends updates for units in LOS for efficiency and cheat prevention.

  • Pros: Scales up to large maps.
    Cons: Client requests need to be sanitized and verified for potential cheating.
    Quote:
  • AI to be implemented as remote clients, not compiled into server. As far as the server knows they are just another player and have the same restrictions with respect to LOS and updates.

  • Pros&Cons: Can be seen here: https://skatgame.net/mburo/orts/.
    +AddedCon: If your AI is to represent a large faction, it would incur a large extra bandwidth due to a large amount of updates/reads.
    Quote:
  • Support for WebGL/Canvas and OpenGL ES2 clients (Mobile)

  • Pros: A reduced CPU requirement would allow a wider variety of platforms to be targeted.
    Cons: Code must be created for each of the new targeted platforms.
    Quote:
  • Simplification and unification of lobby and autohost protocols

  • I don't see this being related to the original (asynchronous) move of this thread. I assume this is a sub-project, care to elaborate?
    Quote:
  • Non-lua widget support. Clients can implement their own native widgets in whatever language they are written in (eg, Javascript). These widgets communicate to the server using the same protocol as used for player input and AI.

  • Couldn't this be done with Spring as it is? Someone may need to create a C API and then just generate interfaces to a bunch of other languages?
    Quote:
  • Remote OpenGL proxy. This will extend the work zerver has done on his GML rendering proxy (for spring-mt) to pass server-side OpenGL calls and assets over the wire to a client.

  • No idea what this means, but I assume you want to have an opengl server with clients connecting to it and just executing the opengl commands locally, as computed on the server?
    Well, I guess Pro: Even less CPU/GPU work on the client. Cons: Having to create an OpenGL proxy and protocol. And couldn't it be done on the Spring as it is extending by just the OpenGL proxy, which is a Spring P2P node?
    Quote:
  • Remove FPS unit control. This has always been buggy and crap anyway but it becomes even more unusable when combined with my changes

  • Well it is useless now, yes, but wouldn't asynchronous mode allow for more freedom - you could display FPS mode as you want.
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 13:29 
User avatar

Joined: 02 May 2005, 02:56
Location: Canada
For good or ill, and despite any reservations I have about your philosophy, I'm glad to see something like this happening.

When something is first done it takes a lot of work to get it just "working" but by then you've learned a lot about what should have been done, could have been done and what can no longer be done easily because you've programmed yourself into a corner. "Starting Again" with the assumption that much can be salvaged but nothing should be kept, just because it's already been done is very painful for an active project but it's also very healthy in the long run (like pruning a grape vine).

Good luck dude... now when people come and ask us for crazy ass features that Spring will never be capable of we'll just tell them to bug you instead. Happy Forking!
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 14:59 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
@gajop: Thanks for the feedback. I ran into Orts years ago when I was looking for an engine but I'm pretty sure I had some issues with it. So long ago I don't remember. The remote AI appealed to me, seems to be its focus.

You pointed out there are things in my list not related to the networking model. As you suggest the reason is simply that if I'm going to break compatibility anyway I might as well remove/clean as much legacy stuff as I can. Being a fork it's basically up to me to decide what's important and what isn't. Since I already have a game planned I have a reasonably good idea what I'll be focusing on.

Your thoughts on mixing async/sync are interesting. Right now I want to keep things really simple. The client will hold as little state as possible about the game world. It will basically be along the lines of:

C: Tell me what I can see in sector 234,234
S: Unit 453 of type 23 on team 2 has appeared at 34,324 aiming weapon 5 at unit 7
S: Unit 674 of type 13 on team 2 has appeared at 73,45
S: Unit 3 destroyed by weapon 3 on unit 86
S: Unit 59 moved to 45,23
S: Projectile 73 explodes at 534,23 coming from vector 234,342
C: Select units 234,435,74567,345,352,45,367,453,436,234,482
C: Move selected units to 932,65
... etc ...

The AI or client may wish to cache some of this state information but the server will simply abort any actions that don't make sense due to subsequent sim changes.

The whole desync thing is a huge pain (especially to debug) but Spring has done some nice things lately to mitigate this (esp. rejoin). Still, I believe the amount of work to write multiple unsynced clients would still be less work than completely solving desync across non-x86 architectures.

The OpenGL proxy is largely optional and might not even happen but the idea is to help support games that render elements via LuaGL to route those elements to the client for client-side rendering.

@SinbadEV: Er yeah.. thanks. ;) Though to be clear I'm not adding anybody's feature requests until my own game is running. This fork is more about solving my own problems than satisfying everyone elses. Having said that the license is still GPL and I have no intention of hiding behind any server-only exemptions to providing source. All my changes will be released so if somebody wants to fork it or merge features back into Spring they will be free to do so (assuming the Spring devs want them that is).
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 15:00 
Spring Developer

Joined: 08 Oct 2006, 15:58
Oh look, another giant wall of text filled with grand ideas that will likely never materialize.

Take a reality check at some point maybe?
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 15:27 
Spring Developer

Joined: 16 Dec 2006, 20:59
Kloot, even if you think so, please don't kill him before he even started.
SpliFF wrote:
[*] Remote OpenGL proxy. This will extend the work zerver has done on his GML rendering proxy (for spring-mt) to pass server-side OpenGL calls and assets over the wire to a client.

I assume you will stream textures, models and such from the server. This is doable but requires a clever implementation. I hope you realize that streaming all the rendering (GL) calls from a server would never give acceptable performance. 100+ megs of rendering bandwidth is needed for that, and it does not seem like a very good design choice IMO.

Good luck!
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 15:38 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
I don't consider them grand ideas. Most are reasonably straightforward. Half of the propsosal involves removing existing features or splitting them into different executables (like spring-dedicated does). The clients and networking protocol are the hardest parts but the x86 client can just be a stripped down Spring and the web client will likely start life as a spectator-only feature much like Spring started as a replay viewer. The clients are essentially "dumb terminals" to handle rendering and input - they won't need to be all that advanced. In fact the game i'm developing wouldn't even care if the client rendering was 2D since it will be intended to play from a top-down view.

The primary drive to fork is that to make this viable I'm going to be stripmining features out of the engine and that would clearly not be possible while meeting the needs of existing games.

@zerver. Yeah I'm not expecting to replace a 4-6Gb/s PCI-E transfer rate with a 1mb/s DSL line and get realtime rendering. I was thinking more in terms of the type of streaming of display lists used by WebGL. I mentioned your code because it already handles serialisation. TBH streaming GL in realtime is actually about the lowest priority I have and I regret mentioning it at all now. It makes my system sound needlessly complicated.


Last edited by SpliFF on 31 Oct 2012, 15:50, edited 2 times in total.
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 15:39 
User avatar

Joined: 02 May 2005, 02:56
Location: Canada
zerver wrote:
Kloot, even if you think so, please don't kill him before he even started.
SpliFF wrote:
[*] Remote OpenGL proxy. This will extend the work zerver has done on his GML rendering proxy (for spring-mt) to pass server-side OpenGL calls and assets over the wire to a client.

I assume you will stream textures, models and such from the server. This is doable but requires a clever implementation. I hope you realize that streaming all the rendering (GL) calls from a server would never give acceptable performance. 100+ megs of rendering bandwidth is needed for that, and it does not seem like a very good design choice IMO.

Good luck!


I understood him to mean he would have the assets local and just send the "tell GL to draw this thing here and that thing there" stuff over the network.
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 15:56 

Joined: 29 May 2010, 22:40
I'm not into engine programming, but I'm technically curios :)

Calculating the sim on the server doesn't lower the amount of calculation that has to be done. For a game with 100 players you'll need 16x the CPU-power a 8v8 match needs atm on spring-headless.

_Maybe_ that works on a 16-core or dual xeon with perfect spring-sim-MT, but with 200+ players pathing on a 256x256 map it won't! So my question is: do you want to use a cluster???

If that is the case (and assuming you're not into HPC), you must distribute the load in big chunks, and in this case that'd be big parts of the map. Maybe even with moving "chunk-windows", to have as little interaction as possible between the nodes. The clients get the response from the currently responsible node. --> The nodes are not only servers, but also clients to each other - on their "chunk-edges". Shared data would need to be either broadcasted and held in sync or stored centrally.

That'd be a p2p network again. And may even be possible to do in spring. Actually it sounds a lot like spring - with a load distribution system. Then no -insanely expensive- server farm would be needed!

Now please reply that you want to make it clusterable, and I didn't write all this text for nothing :D
Top
 Offline Profile  
 
PostPosted: 31 Oct 2012, 21:47 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
Sending assets over the network as a feature might be a nice idea for some features, but as a primary mechanism for content it sucks considering the cost vs the ease with which one could just transfer a lot of the pain in the initial download as local content.

Spliff I would note that it would be nice to be able to configure game frame time to something other than 0.5 should someone who wants to use your fork but has ever so slightly different requirements comes along. Perhaps they want a per second or .1s time.
Top
 Offline Profile  
 
PostPosted: 01 Nov 2012, 01:21 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
@dansan: The overhead of increasing unit counts tends not to be 1:1 dues to the interactions between units (esp. collisions but also los, pathing). Having 10x the units may actually cause 1000x the load. I was able to mitigate this a little in some experiments I did by changing how collisions work (making them less accurate and removing sliding/bumping behaviour which seemed to cause runaway processing in the collisionhandler. I suspect this is due to units constantly ping-ponging between two or more obstacles. By disabling collisions entirely (like StarCraft) I was able to get a 5000 unit game running on dual-core + ati 1950xt (low end pc) at around 5-10fps. I believe that with the right simulation settings a high-end server could handle 10k+ unit games provided some loss of precision/features is acceptable. The choice would be up to game devs (more precision vs more units) by enabling/disabling simulation options.

As far as scaling to huge games my initial plan is to stick to one instance of spring per map and allow whole armies to be transported to another map/instance. Each instance will communicate with a common database to synchronise transfers. At this stage I'm not planning to make transitions seamless. To clarify, each server instance (a single physical server could run multiple instances) is responsible for one standard-sized map/game at a time but many games could be running in parallel and sharing a common "universe". This is essentially no different to PlanetWars (hardly anything I'm planning for the new engine is really new or original).

@AF: I want to investigate using delta compression for certain gamestate changes and once I have code for that it should be trivial to use it for file/content transfers as well. Delta compression is the technique behind Git and Rapid for example, you only send the differences between what the client has already and the new content. It's especially effective with certain types of content where changing a part of a resource (like a few pixels changed in a texture) does not modify every other byte in the file. It's important to me to minimise the number of additional client tools required to play so I want to integrate existing lobby and downloader features directly into the client (like LuaLobby).

I'm all for giving people options provided the options don't create too much work. I don't believe altering the time between sim steps would require anything that Spring can't already do with +/- speed changes.
Top
 Offline Profile  
 
PostPosted: 01 Nov 2012, 12:56 
User avatar

Joined: 30 Nov 2008, 04:31
Location: the flow
I keep reading this thread over and over and trying to guess what ANN has to do with it >.>
Top
 Offline Profile  
 
PostPosted: 01 Nov 2012, 13:05 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
It's short for "announcement" and it's often used in thread topics on modding forums to indicate a new project announcement (as opposed to a REL: or [REL] prefix to indicate a major release of a mod). I thought it was common knowledge but maybe I just spend more time in modding forums than your average person.
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 08:42 

Joined: 29 May 2010, 22:40
I see - thank you for the explanation.

Still - even if you lower the computational cost as much as you say (which btw. is "wow - I didn't know that!") with enough simultaneous matches/units you'll need a lot of processing power.

So if the game is successful it'll need financing to pay the servers. A skype-model, where powerful clients help the central nodes will not work, because of the bandwidth demand - or am I wrong? ...oh... wouldn't work anyway, as clients are not persistent... :D

I have no problem with commercial games btw... just asking. There are also very successful donate-services like soma.fm, that pay for server-farms and lots of bandwidth.

btw2: I don't want to discourage or criticize you (great idea you have imo!) just curious- I hope it doesn't steal to much of your time :)
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 09:33 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
in the AOE example calculation, they used 6 parameters per unit. that is maybe 10 bytes.
in spring, that is maybe the state of a projectile, but a unit is more like... 10 times as much, isn't it?
i don't think that unsynced is feasible for spring-style-epic battles or bigger. if you limit the number of units, it is of course possible.

that aside... i am happy to see a fork. though i am not sure if writing from scratch might not be better for you. you could still copy paste stuff from spring, if you find something worthwhile.
i personally would have other goals for a fork, but i think new wind is good anyway. it is possible to see changes that neither jk nor kloot like!

so... if you want to support all kind of clients.. also low spec ones.. i guess you plan to have a game with not too epic proportions anyway, right? or do you plan to have a super good GUI that allows to nicely handle 10k unit games on a schmart-phone?

good luck! :-)
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 10:18 
AI Coder
User avatar

Joined: 14 Sep 2004, 10:32
Location: Cookieland
Depends how you do it, eitherway we won't have to wait for long, Planetary Annihilation is using the same asynchronous model and a playable version is being released around the end of the year for certain backers
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 12:57 
User avatar

Joined: 02 May 2005, 02:56
Location: Canada
There seems to be concern on the overhead of a server but doesn't spring already run everything on every instance?

Assuming matches of comparable size, in the Fork you would have 16 clients with very low system requirements and 1 server with very high system requirements as opposed to the way the current Spring works where all 16 players are held back by the capabilities of the worst computer in the group. So a net gain.

Assuming that the servers run on something akin to auto-hosts (which already run multiple simultaneous instances of Spring) I think it's realistic.
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 13:45 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
Yeah depending on the number of clients connected to a given map the server will need to do a little extra work packing up and sending updates but that would probably not add up to much. Actually since the server is headless (no graphics, no sound) and probably wouldn't be running any AI or widgets locally a typical sized map should in theory require less resources than it would running on a normal spring peer.

If the goal is to increase the maximum map size I'm going to have to simplify the pathfinder and particularly the collision handlers considerably to reduce the overhead on the server. My tests show that these systems consume a large percentage of the CPU and it increases almost exponentially as units are added. In real terms that means units are more likely to clip features and each other but I can live with that. It may mean removing features like reversing. Simplifying the collision handler may also mean replacing Spring's realistic ballistics model with something more traditional like a random "dice roll" for hit chance and damage. I'm not going to make any decisions without thorough testing - there's no point crippling perfectly good systems for a couple of FPS.

The good news is I have access to some pretty sweet servers and wholesale bandwidth so hosting costs aren't likely to be an issue early on.
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 18:13 
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
Quote:
replacing Spring's realistic ballistics model with something more traditional like a random "dice roll" for hit chance and damage.
I think with the planned slower simulation speed that would be needed .
Spring style physics would be pretty hard to make with only 2 physics update per seconde, even if clients make the visuals go smoother. Thinking about how a fast plane might cover a large distance in half a second and that many projectiles do not even exist for so long.

How do you plan to have midgame join? With 100+ players you will need it, I thought in spring that was "impossible" because serializing all the stuff was too annoying?

Gameplay: With 100 players, eventually one player might grow so large that he has half the map - How will that still be fun? Both for the other players and for the guy who has to controll the stuff of 50 players?
When will games end? I can not think of a good way how a 100 player can be finished in a realistic timeframe. (say 2 hours or so)
Similiar: How will games start, the ones who join first get a headstart?
Or it just an endless brawl and if you disconnect your stuff is gone?

From time to time stuff might need to be restarted, for changes in engine or game. Will all the hundreds of players just be kicked and have to restart from scratch?
Top
 Offline Profile  
 
PostPosted: 02 Nov 2012, 19:23 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
The game I have in mind wont have persistent battles, just a persistent metagame (like planetwars except the "universe" is just one planet). Each battle will still have a start and end within a reasonable timeframe (I'm thinking about 1:45 hour sessions with 15 minute breaks between). Therefore the game length alone should cause no technical or balance issues.

Having said that, just like any persistent universe there's going to be long term players and factions whose superiority can't be challenged and I plan to counter that to a degree by creating incentives and triggers for factional breakdown and civil war once a single faction controls more than about 60% of the resources. Basically large empires will suffer inefficiencies and internal corruption which in turn lead to stagnation, infighting and eventual breakdown and decay.

Within a faction there will always be a "ruling class" or "inner circle" - a small group of players receiving the lions share of perks. Faction players outside the inner circle will therefore have to choose between the safe path of obedience and poverty or the risky path of rebellion and great reward (or total destruction). The rewards of rebellion and the imbalance of resources grow as the faction becomes larger which not only encourages civil war but also discourages new players from joining the "winning" faction since they will generally be personally worse off than if they join a smaller clan. Ultimately no faction will ever be immortal or invincible because history shows that all civilizations, no matter how great, become dust in the end.

Balance within any single battle will be handled differently. While new players or impoverished factions might not be able to field equal armies in a given battle it wont matter at all because the game will reward players based on what they achieve with the resources they have. In other words you will be given a set of objectives and the value of completing them will be inversely proportional to the size of the army you field. To put it more simply than that: if you bring twice as many men to the field as your opponent(s) then you'll also need to be twice as effective to achieve the same amount of reward. Victory is determined solely on your completed objectives so even if every unit you bring to the battle dies you can still win the round if you are more successful at completing objectives. A good player will be one who is able to command effectively regardless of the odds.

EXAMPLE: The objective is to capture a civilian. Your opponent brings 100,000 men and an armoured column. You bring 5 men and a helicopter. Before your opponent covers a kilometre of map you've already flown in and grabbed the guy and fucked off again. You win.
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: Bing [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.