🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Good turn based online game architecture

Started by
3 comments, last by hplus0603 2 days ago

What do You think is the best software architecture for turn based online game? And what do You think of that one:

Advertisement

@tomcio , your diagram is very hard to read, and you posted it in the wrong forum. I'm thinking it belongs in Networking and Multiplayer (not Game Design), since your diagram shows a back end. So I've moved it to that forum.

Welcome, by the way, and good luck with your project.

-- Tom Sloper -- sloperama.com

Your diagram is completely unreadable to me, words are too small.

As for your question, “the best software architecture for turn based online game” doesn't exist. It's a nonsense question.

Any program / game has a lot of properties that you want to have. For example., minimal bandwidth, optimal precision, low cpu usage, fast response time, massive ammount of players, low memory use, etc etc etc.

Many of these properties are contradicting with each other. You cannot have massive numbers of online players and low memory usage. You cannot have optimal precision and fast response time without burning many cpu cycles.

Best in everything is impossible thus. You can optimize one property at the cost of other property(ies) though, but then we're talking “best wrt to some property(ies)”.

This also means there is no single software architecture used by all turn-based games. You make different choices while building it, depending on what you;re aiming for.

I'd suggest you let go of “optimal” or “best”, and aim for “working” instead. In any case, working non-optimal beats optimal non-existent.

I agree that the diagram is hard to read. Make the text bigger, and make the arrows bigger, and label the arrows for what they mean. Ownership? Communication? Reactivity? Dependency? Usage?

But, also, I think your architecture diagram seems to mix a bunch of different layers of abstraction.

How about you first write down a sentence of about 10-15 words for each of the layers/problems you're trying to clarify, and then draw the diagram to clarify that part. “Which pieces of functionality are broken into separate executable processes, and how are those processes scaled over physical infrastructure” is a different question from “how and where do game rules get applied an updated” is a different question from “where is persistent game state stored while a game is active, versus while a game is suspended, and is there a difference?”

To illustrate why this matters, a turn-based game of Iterated rock-paper-scissors has different requirements from a turn-based game of Civilization has different requirements from a turn-based game of Go.

enum Bool { True, False, FileNotFound };
Advertisement