Member Avatar for PirateTUX

So it's been a while.

In case you weren't already aware, MMORPG software systems are complicated. Very, very complicated. I mean, you're creating a whole world as a software system! So it's taking a while.

We have made progress, however.

My brother and I recently created a networked system to control a floating ogre head (those of you who have used OGRE before will know exactly what I'm talking about). My brother's WinXP based client software sent "requests" for motion to my Linux based server software. The server software then validated the request (i.e. "Will it run into a wall?"), and sent back the ogre head's new coordinates in space. The client then had the job of animating the head from it's current position to it's new position. The head could move along the X and Y axis, as well as rotate.

It was an interesting little exercise, taking us about 3 hours total to build. Obviously, it is of very little value other than academic, but it certainly taught us about network communication. Also, the server was multi-threaded, which means that a number of clients could connect to the server. We took take of representing multiple clients on each client machine as well, having multiple floating ogre heads.

So what's next?

The next task to take care of is how to represent terrain. I've been investigating different methods of storing terrain data. So far, the two most intriquing methods are bitmap terrain maps and database table storage. I'm leaning toward database storage. I understand that terrain maps are more compact, but the ability to change the terrain on-the-fly sounds very interesting to me. Just imagine: dynamic terrain, with the ability for players to terra-form. Volcanoes that can be triggered to actually create more landmass. Pretty cool stuff.

So that's what's going on now. Thanks for reading!

  • 2 Contributors
  • 2 Replies
  • 112 Views
  • 5 Months Discussion Span
  • Latest Post Latest Post by PirateTUX

Dani AI

Generated

A short, practical roadmap that builds on 's networked prototype and 's point about content: dynamic terrain at MMO scale is best handled as a hybrid system where the runtime world is chunked and cached in memory, and persistence is handled with a durable store that supports versioning and fast partial updates.

A minimal, safe persistent schema (example) that supports chunked updates and rollbacks:

CREATE TABLE terrain_chunk (
  chunk_x INTEGER,
  chunk_y INTEGER,
  lod INTEGER,
  version BIGINT,
  data BYTEA,                -- compressed height + material arrays
  last_modified TIMESTAMP WITH TIME ZONE,
  PRIMARY KEY (chunk_x, chunk_y, lod)
);

CREATE TABLE terrain_patch (
  id BIGSERIAL PRIMARY KEY,
  chunk_x INTEGER, chunk_y INTEGER, lod INTEGER,
  patch_data BYTEA,
  applied_at TIMESTAMP WITH TIME ZONE
);

Key engineering notes and recommendations:

  • Chunk size and LOD: pick a chunk resolution that balances network, memory and CPU. Common starts are 32x32 or 64x64 samples per chunk and a small number of LOD levels.
  • Data format: store heights as int16 or float32, compress blobs (zlib/LZ4). Keep material/metadata separate when frequent small updates are expected.
  • Concurrency: use per-chunk version numbers or short-lived leases to avoid write conflicts; persist patches as an append-only log so you can replay/rollback.
  • Performance: keep a hot chunk cache in-process or in Redis for fast reads, and batch disk writes on a background thread to avoid blocking simulation. See Redis for caching patterns.
  • Storage choices: relational DB + spatial extensions (for queries) or an embedded key-value store for very high write rates. Postgres/PostGIS is a good durable option for spatial indexing (PostGIS). RocksDB/LevelDB are good choices for compact chunk stores (see RocksDB: https://github.com/facebook/rocksdb).
  • Network: send compact deltas (changed vertices or modifiers) instead of full chunks; use interest management so clients only receive relevant updates.

Content pipeline: combine artist-authored assets with procedural generation to reduce manual content load, and keep authoritative validation of terrain changes on the server to prevent cheating and maintain consistency.

Avoid micro-writes, profile I/O early, and validate a scale-test with many simulated clients before committing to a persistent format. For background reading on the basic heightfield concept, see Heightmap.

Member Avatar for crioto

I do not think that two people could have a good and full MMORPG. The creation engine - this is not the end. Where harder IMHO - to create an interesting and exciting game world, as well as providing a new idea. In all other MMORPG - bored quests "Kill 10 rats and bring their tails."
But if you have the time to explore all the MMO creation projects, you are quite in demand and can get a good job, because MMO growing very rapidly

Member Avatar for PirateTUX

You're right. The content is everything on one of these games. This is more of an exercise in "what are we capable of?". Also, we have an older brother who is a fantastic artist. We'll be looking to employ his talents when it comes time to seriously build some content.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.