Network simulation

I’m starting to play with ideas for the network simulation to be used in MMORPG Tycoon 2. This is, I believe, the last major gameplay system left to implement for the game.

In the original MMORPG Tycoon, we had a simplistic simulation; each world region could support up to 100 connected users. If the region had 100 people in it, and someone else tried to enter it, they’d be disconnected and there was a small chance the region server would crash, which would disconnect everyone else and also require you to reboot the server.

That was simple and cute, but it never really felt fun to me (anyone disagree?). In MMORPG Tycoon 2, there currently is no limit to how many users can be connected at once (either in a particular region or overall), but I’m getting ready to add one in. Here’s my current thinking:

The network system design is roughly based upon the plumbing system you find in many city builders. That is, beneath the map you provide a network of… well… network “pipes”. These cables carry network data to and from different regions of your game world.

So you’ll place Internet connections, and string out connectivity from them to your towns, to your questing zones, and to other structures. In the same way that water pipes provide water to nearby buildings in most city builders, network cables will provide connectivity in this game. And if you want to support more simultaneous users in an area, you’ll be able to add more network connections, to provide bandwidth to support them.

As in the last game, if you overwhelm your bandwidth limits, things will start to fail; buildings and services and NPCs might stop working, or players might get disconnected, or a whole region might overload and crash. So don’t do that! :slight_smile:

I’ve gone back and forth on precise designs for the system. Originally, I was thinking of a literal “water pressure” simulation, where network connections provided “bandwidth”, which flowed through the system like water, with its own simulation, to be consumed by users and buildings. This sounds interesting in that a sudden spike of users in an area could cause a temporary shortage of bandwidth in that region, which slowly repaired itself as bandwidth flowed back in. It’s very much a “water simulation” approach.

But in practice, real-world networks don’t actually work that way. It doesn’t really feel right to me, even though I can see how it could make for interesting game situations. A more ‘realistic’ system would treat all in-world network traffic as being handled instantaneously, and as long as you don’t surpass the maximum bandwidth output you’re okay, and everything just gets throttled once you reach that outgoing-traffic cap. I don’t think that provides visible game behaviours which are as interesting, though; when you run out of network juice, you’re likely to just get a lot of failures more or less randomly scattered across the whole game, whereas under the ‘water simulation’ approach, they’ll tend to be localised into a single area, which can be solved or repaired by more clever routing in that area.

When I started writing this post, I had convinced myself to do the more-real-network simulation, rather than the water-simulation. But now that I’ve laid out the case for each, I feel like I’ve convinced myself back in the other direction; to do the whole “flow of water” thing, just because I think that’s more interesting from a game perspective. But I haven’t convinced myself, yet. Anybody else have opinions?


Don’t forget making MMO Website and MMO Forum and MMO Launcher :stuck_out_tongue:

1 Like

try making one fusion of the two,if its well connected the cables,the internet will be better and will support more players

Little update on this.

Yesterday I powered through most of the rendering issues involved; I now have a “network” view of the game, with the ability to draw networking elements composited into the scene in a really interesting way. (I’ll post some video soon. Tomorrow, maybe.)

I also settled on a general framework for how the system itself should work. I would have been prototyping that today, but I’ve come down with a pretty unpleasant cold, and so haven’t really accomplished much. I’m hoping to have recovered, tomorrow. (Although I can already tell that I’m going to lose my voice for a couple days)

I’ll post more updates soon!


I’ll throw this into the mix and i’m sorry that its just a brain storm and I have no idea how hard/easy to fun it would be.

But how about each region being treated as its own cluster and so you have like the kind of water system you mentioned but you also have each cluster connected to a single bandwith “Pipe” which would use the more realistic second idea to represent the “Company’s Server”. and through research and investment you could upgrade clusters and this main “Pipe” to handle more traffic.

The benefit is that each region can be managed and upgraded at different rates as the game progresses but you alway have the secondry overall pipe that you have to manage and potentially use to manage progression speed.


I think that’s a very reasonable design. I particularly like how it ties into upgrades, which I hadn’t even considered. It’s almost always good design when you can tie two different systems together!

I think we’re thinking along very similar lines, actually. My current design calls for two different types of “pipe”; one which transmits data quickly and efficiently between nodes, and one which transmits data slowly, but provides access to bandwidth along its whole length. The normal use case for them would be to use the “fast & efficient” ones to transmit bandwidth quickly between regions, and to use the “slow, with uplinks” ones to provide bandwidth for objects inside the region. I think this models exactly what you’re talking about, re: one system within a region vs. another system for communications between regions, but it does it using just a single system.

I’m feeling a bit better today; I may take a first stab at implementing this system, and see how it goes. (Or alternately, if my brain isn’t up to the “write new code” challenge today, this may wait until tomorrow).

Also, I can confirm that I’ve partially lost my voice, as predicted. It’s gone Darth Vader-husky. Not nearly as bad as it usually gets after that type of cold!


Little update:

I have the first bit of the system implemented; the nodes, but not yet the connections between them. In doing this, I stumbled over a neat little code architecture to hook the systems up such that I could create new node types entirely in data; no need to recompile the game or anything to expand the system. It almost could be done for regular buildings as well. And definitely could be done for paths, if I someday want to go back and refactor that code.

Things have taken longer than expected; after being sick at the start of the week my brain has been fuzzy for the last few days, and it’s been a little difficult to really focus properly and be productive. The weekend should be quiet, though, and I’m hopeful that I’ll be able to power through the remaining work on the network simulation proof of concept.

Note that as usual, the first build will contain only programmer art (right now, I’m just using those spheres from the ‘shaders’ thread for everything). Additionally, the system will probably be completely unbalanced and exploitable, initially. But it’s coming along! :slight_smile:

Stuff remaining to be done for the first proof of concept:

1. Place network pipes.
2. Be able to select network nodes/pipes, and display information about them in the selection box.
3. Be able to destroy network nodes/pipes.
4. Implement bandwidth flow between nodes, via pipes.

5. Set up buildings and zones (and NPCs?) to automatically connect to the nearby network infrastructure (if any). If there’s no bandwidth available near them, deactivate them and display an “offline” indicator. My current thinking is that I want this bandwidth-requirement to replace the “A developer must visit the building to activate it” requirement.
6. Make in-game PC actions consume bandwidth. If no bandwidth is available, start knocking buildings/zones offline until there’s enough bandwidth available to complete the PC action. (Consider: do I want to keep the old “sometimes crash the whole region” behaviour, here?)

Edit: Updated with what I’ve gotten done so far today. Still needs lots of visual work, but it’s coming together!


hey trevor,i liked the ideia of pipes :smiley: …but theres more minigames like the pipes but different? PS:IN NOT STARTING A DISCUSS,just asking about minigames like the pipes :stuck_out_tongue:

1 Like

This isn’t a minigame. It’s a part of the game simulation. It runs continuously, and affects and is affected by everything else going on in the game.

Minigames are typically entirely separate games which only affect the main game in whether you won or lost. For example, “win” at a lockpick minigame in Skyrim, and the door unlocks. Lose, and you lose a lockpick. “Win” at Ghent in Witcher 3, and you earn some money. Nothing happens inside the main game while you’re playing the minigame; the main game is effectively paused.

That’s not what this network simulation is. It’s always running, and always affecting and being affected by what’s going on in the rest of the game simulation. It’s part of the game; not a minigame.

1 Like


but still in the way of the minigame being a MINI Game
yes this would be a mini game,like this is a game inside the game but its “Mini” and can be used as other game,for example skyrim,imagine the minigame of the lock,imagine one game made all of this mini game,welp it works,now imagine one game using the pipes ideas of network simulation,following this logic,like you can make a game of this mini game and this is a MINI game,the network simulation could be easily a mini game,but the main game not stop :stuck_out_tongue:

1 Like

A post was merged into an existing topic: Ideas for the game :smiley:

i think in going to stop posting…
i make mewse split the post even when i do not wanna

1 Like

If you want to post ideas for new features, post them in the ideas thread so that they can be found later. If you want to discuss the design for the game’s network simulation, then go ahead and post that here.

I don’t think I’m being unreasonable.

1 Like

Here’s a quick work-in-progress shot of what I’m working on. As I mentioned above, currently all programmer art.

The circular green spot near the middle of the shot is the network uplink. Bandwidth comes into the game from that point. The fine green line is normal network cabling; it provides bandwidth to all the area around it, highlighted in blue. That the line is green tells us that it has enough bandwidth for current demands; if demand on bandwidth goes above the available network bandwidth, that green will change toward red.

Of course, nothing is actually making use of bandwidth right now. That’s my next step; make the monster zones (the grey rectangles around the left and bottom of the screen), and the buildings (dark grey shapes on the right of the image) require bandwidth to function. In this view, they should lighten, and/or become more colorful, when they’re functional.

Today’s work went almost entirely into making that blue ‘area which can access bandwidth’ preview. I’m pretty happy with how it came out. Making me more confident in this design.

(The colored lines in the bottom left corner of the screen are a debugging aid for me, and don’t appear in release builds of the game.)


i thinked this was a minigame :stuck_out_tongue:
ok so… idk how this gonna work but really,as i can see you need to connect the cables
great work,i just wanted more challenge : P

1 Like

General update: the basics are all working now. Both zones and buildings connect to the network system, and that’s visible from the network display. If something runs out of bandwidth, the zone or building goes offline, and will attempt to automatically reconnect after a few seconds.

Right now, all buildings use the same amount of bandwidth, and all zones use the same (larger) amount of bandwidth, regardless of their size. I need to tune that. When a zone disconnects, all monsters in the zone de-rez. They’ll slowly come back once the zone is back online.

I still haven’t actually set up most buildings to not function correctly when they’re offline. This will involve a bit of code refactoring, since half of the buildings function from within AI code. Which is very bad code design, but is what I have right now. I’ll fix that in the next day or two!


Looking forward to getting my hands on it :slight_smile:

1 Like

The first revision of this is now up on Steam, for those who are testing.

Note that it’s all still programmer art, and has only vaguely been tuned. Expect big changes to the specific values for things! Also be aware that the tutorial hasn’t been updated to include this stuff yet; the only instructions about how this system works is currently this post. (Apologies!)

It’s worth noting that there are just seven things left on my “to do” list for the Milestone 13 build, and three of those are about updates to the tutorial. So I’m going to be focusing on the tutorial a lot, in the next few days!

Some comments on the network system. Note that all the numbers which follow are just the initial values, and are very likely to change quite a lot in the near future, based upon feedback and my own testing!


Nodes are simple objects that get placed into the network layer. Most of them have a function. All of them can hold some amount of bandwidth, a few generate it, and most will slowly consume any excess bandwidth they’re storing. Here are the current types:

  • Uplink: Creates 50 units of bandwidth per second, and can store up to 50 units. Expensive.
  • Pool: This can hold up to 500 units; useful if you have something which infrequently uses a lot of bandwidth, but normally doesn’t. Expensive.
  • WAN: This will hold up to 20 units of bandwidth, but serves it to the game world in a huge range. You can probably provide complete network coverage for a whole region using just two or three of these. Absurdly expensive.
  • Junction: You can’t create these intentionally; they get placed at the ends of any pipes you create which don’t go to an existing node. Junctions hold a small amount of bandwidth, but mostly just provide a connection point for another pipe to attach.


Pipes are used to connect nodes together, to move bandwidth around. Here are the types:

  • Cable: Inexpensive cabling which is mostly used for providing network bandwidth along its length (its bandwidth is accessible to game objects up to 200m away in every direction). Cables transfer bandwidth at a rate of 10 units per second.
  • Fiber: Expensive cabling which provides no network bandwidth to the world, but instead simply transmits bandwidth very quickly from one node to another. Fiber transfers bandwidth at a rate of 50 units per second. Unlike cable, fiber can be laid crossing up to one region boundary, which means that you can use the uplink in one region to power the network in another region, by carrying the bandwidth across the region border using fiber. (By contrast, a run of cable must remain entirely within a single region).

Cables and Fiber are each divided into segments 20m long, each of which can hold a certain amount of bandwidth (0.3 units for Cable, 1 unit for fiber). Cable lets nearby in-game objects connect and use this internally-held bandwidth, but fiber does not; the bandwidth held inside a fiber is basically inaccessible to the network. (Fiber is useful because it moves bandwidth around quickly, but is wasteful because it’s expensive and it effectively “consumes” a lot of bandwidth that could have been used for something more useful)

Bandwidth usage:

  • Every building (including scenery buildings) requires half a unit of bandwidth per second, to remain active. Additionally, they require one unit of bandwidth each time a PC tries to use the building (Buying things, becoming a resident at an inn, respawning, etc). Subscribers cannot visually tell whether a building is online, and will feel frustrated if they try to use a building but the building isn’t working because of a lack of bandwidth.
  • Every monster zone requires bandwidth based upon its size; larger zones require more bandwidth. Additionally, they require one unit of bandwidth each time a monster respawns, and each time a monster attacks. As a general rule, assume that a small monster zone will use a fair amount more bandwidth than a small town. If a zone loses its connection due to lack of bandwidth, all monsters in the zone immediately unspawn.
  • If a building or a monster zone goes offline due to lack of bandwidth, they’ll be drawn in dark grey. They will periodically attempt to reconnect, and will return to normal appearance once their connection is restored.


Some general thoughts:

  • Cables “fill” somewhat slowly, which means you might be waiting a little while for bandwidth to be provided along their whole length.
  • Remember that each uplink provides 50 bandwidth per second, and each building consumes 0.5 bandwidth per second, and each monster zone consumes (as a rough estimate) 2-3 bandwidth per second. This gives you an idea of how much stuff you’ll be able to support off a single uplink, assuming you have an efficient network to get the bandwidth to where it’s needed.
  • Also remember that pipes do contain bandwidth and tend to fill up; so long cables/fibers which aren’t serving a useful purpose are just holding bandwidth that can’t be used elsewhere.
  • You can make a cable “fill” faster by connecting both ends to bandwidth sources, so that it fills from both sides, instead of just one. You can do this by connecting both ends to a single uplink, or to two different uplinks, or just to two different points on your network which are already full of bandwidth.
  • Things which are taking bandwidth from a cable pull that bandwidth from a particular point on that cable. If too many game objects are pulling from that same area, the cable could run out of bandwidth there, even if there is plenty of bandwidth available elsewhere in the cable. Those “empty” areas in a cable are drawn in red, in the ‘Network’ view. (Similarly, “empty” nodes are also drawn in red)
  • If a cable runs through a congested area (say, a town), often that congested area will completely use up the cable’s bandwidth supply, so the cable won’t be able to provide any beyond that congested area. In this case, running another cable through the congested area can help relieve the load. Or else, run fiber from an uplink to provide power to the other side of the cable, so it can fill from both sides. Or just use a WAN to cover the congested areas, since WANs aren’t affected by local congestion in the same way that cables are.
  • Junctions generally slow down bandwidth propagation through your network. Try to use as few of them as you can; connect pipes directly to nodes which do things instead of adding junctions, when that’s possible.
  • WAN nodes are generally awesome. Probably overpowered and underpriced. When just starting out, you can probably just place an uplink near your starting area, place a WAN next to it, and connect the two using fiber. After doing that, you likely won’t need to think about networking at all until it’s time to expand into a level 2 region.
  • I’m legitimately not sure what the best strategy is once you’re expanding; whether you’re better off buying new uplinks in the new regions you expand into, or whether you’re better off running fiber between the regions. If building more uplinks is always better, then I need to make fiber cheaper. This will be one of those fun areas that I’ll probably never finish tweaking.

Eventually, there will probably be far more node types, and maybe more pipe types. But until it’s all settled and I’m starting to get real visual models for these things, I’ll probably hold with this set of components. This isn’t intended to be a major area that you spend a lot of time looking at; you really ought to be looking at it maybe 10% of the time or less. Place some new objects in the world, quickly pop over to the network view to make sure they get connected and nothing is catastrophically failing, and you’re done.

1 Like