Vapourware MMO GAMEDESIGN

[Lance Treiber]

Hello. Long time lurker.
I'm working on a small mmo project as a game designer and I want to milk you for ideas. I have some of my own that I want to share, too.

1. "Balance"

In modern MMOs there's this persistent idea that nobody should be OP, or else it's "unfair".

But in classic MOBAs or even DnD, if a player was "fed", he'll be so OP that he can often easily dispatch 3-4 opponents single handedly.

Let's take this idea and put it into an MMO. Let a "Death" mage spell kill anyone with less than 500 HP (tanks having 700-1000, mages 300-400). Let a "SILENCE" cleric spell drop a giant sphere into the room for an hour, and nobody can utter a word while in it.
But let these spells (they're learnable) drop only once or twice a year. Let them also require almost inexistent ingredients.

The guild that farmed this boss (equivalent of feeding a player) may get one of these spells. Now it can wreck havoc, but only if they protect their MVP in a big melee.

I don't see any problems with this approach, as long as the rest of game design accomodates it: very harsh penalties for death, PK-flags in world PVP, team oriented leveling. These things are great on their own, but also "dilute" the individual power of a player a little bit, making one guy with "Death" unable to go postal before running into serious problems himself.

What do you think? I'd like to hear your ideas on this or where you've seen examples of imbalance that does work.

2. "Role playing" classes

I loved when classes were clearly defined in the past.

Here's what I'd like to do:
- Rogue class doesn't fit into "raids" in my mind, but it's the only class that can "solo" a lot of content. For solitary players. They can also steal from players (with reservations).

- Clerics can't damage. No shadow priests bullshit, it only heals, deal with it. You'll be forced to make friends, so it's a social-oriented class. And it makes sense too, as girls often go for support classes and they're often social.

- Mages can cast invisibility and can fly (both lasting for half an hour or until dispelled). Maybe fly freely like in Morrowind (but how will you deal with them without a ranged weapon then?) or they lift off the ground and can fly above water, fire, etc. It still sounds class-defining enough. In WoW you could be invisible for 15 seconds only. Why so short - to tease the player?

- Rangers can track players/mobs. Literally see and read footprints, think Witcher 3. Useful for world PvP.

I'd love to hear more ideas in that regard. What should Paladins, Barbarians, etc be able to do exclusively? Something anti-undead comes to mind for paladins, but maybe it's not very useful in a game that doesn't revolve around the undead.

So far we settled on these classes: Warrior, Rogue, Cleric, Mage, Paladin, Ranger, Druid, Barbarian, Death Knight, Archer.

----

I'll keep it short for now, see if anyone even responds. I know the codex isn't actually big on MMOs.

 

[Nathaniel3W]

A small MMO, did you say? Best of luck to you. Here's my advice:

Don't worry about balance right now. Don't worry about classes or roleplaying or spells or hit points or the undead. Here's what you should do:

• Set up a server. Write a program that will accept network connections. Open a port in your firewall to allow that connection.
• Write a program that runs on the client's (i.e. player's) computer. Make that program connect to the server.
• Now make your program pass information from the client to the server. Just a chat message, for example.
• Now connect two people to the server. Make the server pass a chat message from one player to another.

If you can get that far, then start over and write a text-only MUD using Python and a networking library. Save player progress to a MySQL database.

If you can get that far, then start over and download Amazon Lumberyard. Build a 2-player PVP deathmatch prototype. Now build a 4-player PVE prototype. After you've spent a year or two doing that, consider making a prototype that has character classes.

 

[Lance Treiber]

Woah, surprised someone answered. Sure, programming discussion it is then!

I just figured game design is something everyone can talk about and contribute to, while programming - not so much.

I got years of programming experience for midsize studios that started out with good ideas, but then turned to shit and eventually tanked / got bought out. Personally, I think the entire approach that says "hey, let's invest millions of bucks into a project and hang the success of it on a couple of dudes with a shitty salary called game designer!" is hopeless. If they're a génius game designer, what's stopping them from making millions? And if they're just a cog wheel, well then, why are you investing into them? Those are just people, more often than not with no successful projects in their resume. What a joke.
When NDAs run out, I'll share a couple of stories that will make your hair stand up. Mismanagement on the level of Chernobyl.

As programming goes, the Lumberyard suggestion was... original! First of all, I'm making a 2D game (which is irrelevant as far as broad stroke game design goes, so I didn't mention it). And also because I do come from 3D engines and I did have a look at Lumberyard at some point. It's a hot mess. They took a small, fast CryEngine editor and pumped it with gallons of shit. Very quickly, cold-starting the editor got to 30 seconds from mere 5. That's a good indication of things going south. I'm not citing actual numbers, but it's in the ballpark. And the features that they pumped it with were useless and related to Amazon services. At least that's how things stood last time I looked at it.

CryEngine looks like a better choice. And its anti-aliasing is truly truly magnificent (compared to unity/unreal). But it's dead. Last time I gave it a try, there was a giant tutorial on how to import texture maps, because simply feeding it PNG or any other sensible format just wasn't supported. AFAIK it's got C++, C# and two different types of visual scripting. What a mess. They did have some very nice dedicated support for $50/month which got you a couple of skype hours with an engineer, which is nice. But then they removed it, I don't know what they replaced it with, but when I was trying it out, they had no support at all. They moved from one forum engine to another, and it effectively buried thousands of old threads with knowledge base. Like burning the Alexandria library.

And the usual suspects... Unreal is bloated and messy. Unity is doggone ugly and slow. I know some people disagree, and it's fine.

If I absolutely had to make an in-doors 3D game or an outdoors game but in the city, I'd go with Unreal, but I'd hate every minute of it. If it was outdoors 3D (nature, foliage, grass), I think I'd have to stomach CryEngine. Unreal's TXAA is so blurry, they actually recommend applying a sharp filter on top. Horrible. I played Vampyr recently and I turned AA off entirely, I couldn't suffer through TXAA. But without TXAA, foliage gets jittery. No good solutions there. Fine-tuning TXAA doesn't help.

So anyway, back to programming. Writing a server in and of itself isn't the difficult part for me. My current difficulty is that Tiled is the only 2d map editor that can do something that resembles what I need. But it doesn't do everything, so I had to dive into its code, which is in C++ and Qt. And my god, I hate Qt. Struggling with it right now, not much to say there.

Regarding prototypes... Not a big fan of it. I hated that part when I worked for the man. I have a cohesive vision for 80% of the game in my head and on paper. I constantly refine it, but it's ok. I don't want to do a quick mockup of an inventory system for a prototype, only to have to rewrite it from scratch when I start working on it for real. Always hated it. This time, I'm getting everything right from the first try, no prototypes. I can "play" the game in my head, always could. I noticed it about game designers: often they'd ask for a feature that I instantly knew was going to suck. But they needed visual confirmation, they needed me to code it to realize this. I'm not boasting, it's just that thankfully I can skip it.

 

[Otay]

Hello. Long time lurker.
I'm working on a small mmo project

"small massive" projects are my favorite kinds of projects

ill be lurkin

 

[adrix89]

We still don't have a good clone like Space Station 13.
40-100 players on a server, 2-4 hours rounds.
The theme doesn't really matter and can be very conductive to a "small mmo"

 

[Nathaniel3W]

Woah, surprised someone answered....

And I'm surprised you're actually not just an "ideas guy" who came here with his MMO idea with nothing else to offer. No offense intended. It's just that most of the time when I encounter someone who says "I would like to make an MMO, but like this..." it's almost always someone who doesn't have the skills to pull it off.

I'm not a fan of Lumberyard myself, but the AWS bloat is exactly the reason why I recommended it. The way I see it, if you are a solo developer or have a team of say up to three people, then you'll want to use as much off-the-shelf technology as possible. If a solo dev is going to manage his own servers--testing, patching, load-balancing, restarting, backing them up, making mirrors around the world for lower ping times, integrating databases, and on and on and on--I've never even made an MMO and I'm just imagining what a logistical nightmare it would be--anyway, if a solo dev is going to do all that in addition to making a game, then AWS integration will save him years of work.

So you don't want to build prototypes. That's fine. But I still think that "build it and try it out and then change it" is a more productive approach than brainstorming over a design document. I've just seen too many people think about doing things and never actually do them.

 

[Tavernking]

I had a friend that was making a MMORPG, similar to Realm of the Mad God. In its pre-alpha state it was browser based and you didn't need to register so I opened up 50 tabs and made characters. Apparently the server costs skyrocketed and he lost $200, he shut down the game after that

 

[hello friend]

We still don't have a good clone like Space Station 13.
40-100 players on a server, 2-4 hours rounds.
The theme doesn't really matter and can be very conductive to a "small mmo"

YESSSS

An SS13 clone would be a gift to the world.

 

[SerratedBiz]

This time, I'm getting everything right from the first try, no prototypes.

Famous last words.

 

[Lance Treiber]

40-100 players on a server, 2-4 hours rounds.
The theme doesn't really matter and can be very conductive to a "small mmo"

I didn't mean small in the sense of number of players.

I'm actually writing the server in Go to support high concurrent number of players. Started in Node.js initially, but realized I hated working without types, so I switched to Go. Gamedesign-wise, I'd like to aim for about 250-500 players online per server. With the way I'm programming it, it should support that number quite easily. If there's some special event where lots of players want to log in, there won't be enough player zones for everyone (I'm not going to do instancing/phasing out of principle), but the servers should do fine.

If a solo dev is going to manage his own servers--testing, patching, load-balancing, restarting, backing them up, making mirrors around the world for lower ping times, integrating databases, and on and on and on--I've never even made an MMO and I'm just imagining what a logistical nightmare

Regarding deployment of live/ptr builds (client and server) I'll write a small program for that, so it's all done in one click. Did this for the previous project I worked for at the studio, no biggie.

Database backups I'll relegate to a webhost, don't want to deal with it myself. No need for super quick and responsive databases for an MMO, you only load/save characters occasionally, which is not a time-critical operation. Plus some auction house operations, which also aren't time-critical.

Regarding load balancing, I once wrote a simple C# program that automatically ordered a hundred and fifty servers on Softlayer using their API, mounting a pre-configured image. Once I was done with them, the program shut them down. It was on a per-minute payment plan, so it cost me something like 5 bucks to keep them all up for 20-30 minutes. Load balancing is easy with modern tools.

Amazon I'm not interested in, because whatever they sell, it always costs 3-5 times more than specialized eastern european server rental companies like ipserver.su (check out their prices if you want, they offer servers around the world). And running an MMO is a business, so the difference in server costs between $500 and $2000 per month may be the difference between a viable project and a money hemorrhaging project. I'll keep a small program with Softlayer API running just in case it has to load-balance, but it's sort of a backup plan. I intend to soft-launch slowly in different countries and manage servers manually. As slowly as I have to, so again, no problem.

MMO projects may seem daunting and ambitious, but once you release one, they don't look so scary anymore. I worked for 5 years in total on various MMOs. Needless to say, I hated them all. On one project I'm not going to name, the designers seriously said that "PVE arenas are more important than PVP arenas", because according to them, "PVP is unsatisfying to players when it's not well balanced, and achieving perfect balance is very difficult, so let's release a PVE arena this year and we'll think about PVP next year ok?"
So yeah, I've been deeply traumatized by my mmo programming experience, but on the plus side I know how to make them.

The only thing I don't have experience with is developing for mobile devices. Hadn't mention it before, but it's a mobile game with the complexity of a PC game. Not sure how popular it'll be because of that, but I intend to release it on PC later too, with a different interface.

 

[adrix89]

I didn't mean small in the sense of number of players.

The 40-100 players on a SS13 server are a entirely different beast compared to 10,000 players in a MMO since they actually interact and affect each other and their environment.
And those 40-100 players are simultaneous in a single area, even a MMO can choke at 100 simultaneous players.

 

[Lance Treiber]

I was writing the client on Defold, but in the next couple of days I'll be researching the possibility of switching over to Unity. I have a distaste for Unity, but there are good reasons for switching. If Unity can do what I need, I'll briefly explain the why.
What I'll be researching is how difficult it is to hook up sockets, websockets, protobuf/messagepack, how well the export from Tiled works, and if the result deploys easily to all platforms.

I haven't used Unity in the last 5 years. I'm surprised to admit, some of its new features are in fact exciting.



I particularly like the "Lighting 2D" component out of the box. I never had to work closely with shaders, so this is convenient (I'll have to learn them eventually, but still). I also like the usage of normals on sprites, but it wouldn't work for my game because I have a retro JRPG visual style. Still, a cool feature to have out of the box.

The new DOTS thing looks interesting:
- https://unity.com/dots
- https://blogs.unity3d.com/2019/03/08/on-dots-entity-component-system/

From what I understand, in short the benefits are:
- ECS builds an array of structs, and the instances of structs are laid out sequentially in memory, which makes it highly likely that the whole thing will be cached. This can make your code run much faster. For example, in classical Mono you'll be calling time.DeltaTime a hundred times per frame, in ECS just once.
- You give up most of C#'s goodies, but in exchange you use a much faster compiler (Unity proprietary).
- JobSystem allows parallelism, so you'll be using multiple cores (at last) and it's difficult to fuck something up.

In conclusion, it's a great thing for bottlenecks. Kind of like writing a critical part of your program in ASM. Potential cons is that it might be tricky to debug.

The system isn't production ready yet, so I'm not going to touch it this year at least.

 

[Lance Treiber]

It is as I thought. I was able to set things up in Unity in 3 days, compared to 3 weeks in Defold.

Defold's community is very friendly, developers fix bugs on the same day you report them. Very cool, but the engine turned out very restrictive by design...

- You can't get a list of components on a gameoject.
- You can't get children of a gameobject.
- You can't use strings as exposed properties on a gameobject. (e.g. to simply name an NPC in a map)
- Gameobjects have to communicate using "messages". You can't just call a method on another gameobject's script and make it return something. You send it as a message, and it's sent to all gameobjects, and you catch it where you need it...

First eight days I spent trying to hook up some fast serialization library, i.e. Protobuf or Flatbuffers. The engine is using old Lua 5.1 (because it's fast), but all useful libraries are for newer Lua. There are dubious C++ libraries that backport some of new Lua to old Lua, but they're not made for Defold. You can hook them up, but you'll corrupt the Lua stack if you don't know how to do it right. No documentation for that. Awful experience, took me a long time to figure out how it works.

Next week I tried exporting maps made in Tiled to Defold. But turns out Defold doesn't allow multiple tilesets per tilemap out of the box. Why? "Because each tileset means a separate draw call, and we don't want to encourage bad practices". So it took me over a week to write a Tiled plugin that exports stuff to Defold correctly. Then, oh, I forgot about animated tiles. Defold doesn't support them either. Three more days improving the plugin.

By that time, it was almost three weeks of tinkering with the engine and I still hadn't started working on anything beyond simple movement. And I still only had websockets, but not tcp sockets.

Two days ago I snapped and installed Unity... Going back to C# makes me feel like I'm going back, not forward. Even now that Unity supports C# 6, it feels like an old, over-encumbered language.

BUT:
day 1: hooked up sockets/websockets and tested deployment on all platforms.
day 2: hooked up Tiled, had to heavily modify some marketplace code plugin, but still.
day 3: hooked up Protobuf and MessagePack for serialization.

It's sad that engines don't have this basic stuff out of the box. Last time I checked, lots of games need sockets, serialization, 2d world editors.

 

[ThisNameIsFree]

Pretty much sure in this case server and client will have quite a bit of shared code, however you picked 2 different languages for their implementation. As solo developer you should be looking how to decrease your workload, not increasing it.
As for "feeding" - it looked like some feature which can be used only by 0.01% of overalll population - seems like you are missing whole point of MMO at design stage already.

 

[Lance Treiber]

TLDR: programming sperging

Pretty much sure in this case server and client will have quite a bit of shared code, however you picked 2 different languages for their implementation.

Not really.

Since it's completely server authoritative, most, if not all of the game logic will reside on the server side. The only things the client and server are going to share are structs and enums, but no code. They'll also share data to some degree, e.g.
- World. Mob placements exist only on server, but navigation information exists on both.
- Items (only names and icons on Client, but not stats... I want identification scrolls/spells to be used extensively). Same goes for spells, abilities, etc. It's just json files anyway, they're easily shared between client and server.

No logic would exist on client and server simultaneously with the only possible exception of formulas (that is, if I decide to expose them to the client, which I haven't made up my mind about yet). The formulas would probably make up less than 1% of all code.

The client's code only concerns itself with the visual representation of the world and the UI. The client sends commands and receives updates about what's going on. All of the "game" proper runs on the server.

On an unrelated note, I'm still learning Go at this stage, but the further I go, the more I'm pleased with my choice. The goroutines and channels provide such easy to use multi-threading potential, that they're just pure fun.

Example:

The goroutine in red would never quit, but would sleep until something is pushed on the channel from anywhere else in the code. Then it wakes up, prints the int and goes to sleep again. Very nice.
I still haven't decided on the general server architecture vis-à-vis multi-threading (how many threads, which ones deal with what, how they communicate). Early stages... I'm considering hiring someone to consult me, any high-load back-end Go developer from codementor.io would do, they take about $80 per hour, and an hour is all I need.

 

[Lance Treiber]

Gamedesign philosophy sperging

As for "feeding" - it looked like some feature which can be used only by 0.01% of overalll population - seems like you are missing whole point of MMO at design stage already.

Let's not jump to such harsh conclusions for now?

Although it's not the centerpiece of the game, I think a lot of fun resides in the fact that only a handful of people will have truly "fed", powerful characters. There's fun both in participating in that race to be on top of the pyramid, and there's fun in watching others do it, fail it, fall from the pedestal (there's XP loss, possible level loss and full loot drop on death) and there's fun in the ensued drama of it all. Many games have demonstrated it in the past, from Eve Online to browser mmos like OGame.

An unrelated example from real life: there are tens of thousands of MMA fighters. Of them all, only a few will ever become champions in the most coveted organization (UFC), and even less will become champions in the most coveted weight class (heavyweight). Yet they all compete and they watch others compete, they constantly discuss if an undefeated fighter A could take on another undefeated fighter B, etc. Competing is in our nature. Imagine if there was no organizations, no belts, no nothing. Would they still do it? Some would do it for the health benefits, but the competing angle would be completely gone. There'd be no point, nothing to achieve.

Another good counter-example: I watched how WoW went down the road of "everybody wins", and how that made the game meaningless (to me and to the hordes of people waiting for Vanilla). Because when everybody wins, nobody wins.

Plus, I don't intend to make it "either you have it all, or you're nothing". It's a pyramid, it's gradual.

I know it's going to be harsh. It's my hope that people are fed up with namby pamby MMOs or at least some people are.

I think there may be a divide that has been brought to light by Sekiro recently. I'm on the "let games be hard if their creators want them to" side. It's ok if other people aren't, we can't all be of the same opinion on everything.

 

[ThisNameIsFree]

TLDR: programming sperging

Pretty much sure in this case server and client will have quite a bit of shared code, however you picked 2 different languages for their implementation.

Not really.

Since it's completely server authoritative, most, if not all of the game logic will reside on the server side. The only things the client and server are going to share are structs and enums, but no code. They'll also share data to some degree, e.g.
- World. Mob placements exist only on server, but navigation information exists on both.
- Items (only names and icons on Client, but not stats... I want identification scrolls/spells to be used extensively). Same goes for spells, abilities, etc. It's just json files anyway, they're easily shared between client and server.

No logic would exist on client and server simultaneously with the only possible exception of formulas (that is, if I decide to expose them to the client, which I haven't made up my mind about yet). The formulas would probably make up less than 1% of all code.

The client's code only concerns itself with the visual representation of the world and the UI. The client sends commands and receives updates about what's going on. All of the "game" proper runs on the server.

On an unrelated note, I'm still learning Go at this stage, but the further I go, the more I'm pleased with my choice. The goroutines and channels provide such easy to use multi-threading potential, that they're just pure fun.

Example:

The goroutine in red would never quit, but would sleep until something is pushed on the channel from anywhere else in the code. Then it wakes up, prints the int and goes to sleep again. Very nice.
I still haven't decided on the general server architecture vis-à-vis multi-threading (how many threads, which ones deal with what, how they communicate). Early stages... I'm considering hiring someone to consult me, any high-load back-end Go developer from codementor.io would do, they take about $80 per hour, and an hour is all I need.

Ok, i am looking forward how game with zero server simulation on client will operate in case of high latency. At which time you plan to show skill animation and world update on client? After client message probably acquired by the server (+1xNetworkLatency) or after acquiring regular message with world update from server (up to 2xNetworkLatency + ServerPeriodTimeout + ServerProcessingLatency)? Or maybe you plan some fast answer with world update after getting message from client so it will be (2xNetworkLatency + ServerProcessingLatency)? First case only possible if client can simulate server game logic. Second case may make game unplayable in some situations because of lag. Latter case may overload server + lag.
Don't see anything special about Go code - it just hides lock usage in the internal "message channel" implementation. Which is not ideal because you may make better "message channel" by himself depends on task. I am not Go expert though, so i have no clue how optimized Go multi-threading implementation.
Keep us updated about your MMO and Go exploration.

 

[Lance Treiber]

At which time you plan to show skill animation and world update on client? After client message probably acquired by the server (+1xNetworkLatency)

It's not guaranteed that your action has happened, so you can't display it yet. E.g. you cast "magic missile", but what your client doesn't know yet is that you've been silenced a couple of ms ago. So as a client, just send "cast mm", but don't display it until it's been verified to have happened.

MMOs usually only simulate:
- movement prediction
- channeled actions like spellcasting in wow (cancelling animation and particles if it turns out you couldn't start casting for any reason)

And this doesn't require code duplication on client&server anyway.

In this game, movement is grid-based, so movement prediction isn't strictly necessary. I'll experiment with it, but I've got other better ideas about how to improve its responsiveness.
And there are no channeled actions in this game.

Or maybe you plan some fast answer with world update after getting message from client so it will be (2xNetworkLatency + ServerProcessingLatency)?

If there was just one player, it would've been possible. With many players, I'll probably have a thread dedicated to reading all sockets once every 16ms.

Back when I was working with Unity 5+ years ago, a standard unity server running at a capped 60fps actually added around 100ms just to treat a message. And I'm sure they've reworked their network since, but then I remember Escape from Tarkov and shudder. It had a couple of seconds of discrepancy between clients when they were all on localhost.

Don't see anything special about Go code - it just hides lock usage in the internal "message channel" implementation. Which is not ideal because you may make better "message channel" by himself depends on task.
I am not Go expert though, so i have no clue how optimized Go multi-threading implementation.

Go has its own scheduler that runs goroutines on any number of OS threads. It's supposed to be pretty fast, with almost no overhead compared to classic threads in other languages. It also schedules threads only when they can do useful work, e.g. when a channel gets something pushed onto it.

I'm new to multithreading, to be honest. Never had to write engines, I only used them. In standard engines, all your game logic runs on the main thread, and other threads don't even have access to your engine API. You rarely have to put something into a separate thread. Typically, sockets communication and maybe a loading screen, not much else.

 

[Lance Treiber]

Had a bit of a surprise with Go.

How I expected the server to handle tcp connections: one goroutine iterates over connections, sees if there's anything to read on it, does so and then moves on to the next connection.

The problem is that all Read methods are blocking. And there's no Peek() methods to see if there's anything to read yet. Weird.

So only two solutions come to mind:
- launch one goroutine per connection
- or use SetReadDeadline(timeout) which will timeout any blocking read, in an attempt to make it non-blocking by tinkering with the values. Sounds horribly hacky.

After asking around, people insist that a couple of thousand goroutines is absolutely fine, that they're cheap, go ahead and use them and stop worrying.

Huh.

I'll trust it for now. Considering that I have no control over the scheduler, I may have to end up binding all I/O goroutines to one CPU core, so that they don't risk interrupting the game logic goroutines. And then cross my fingers and hope that no important goroutines are put on that core, I guess.

 

[Lance Treiber]

Now that technology has been researched, I'm diving in.

Plans for May:

On client:
- Async loading of levels when player gets close to them, without stuttering (and subsequently unloading when leaving them behind).
- Camera follows character with a gentle lerp, displays sprites with a x2 pixel-perfect zoom.

Client/server:
- Players connect, a character gets created and possessed, then they can walk around the world. Polish the movement, make it pleasant.

On server:
- Detect disconnects, detect spammy clients (disconnect when receiving >10 messages per frame or over 10kB per frame)
- World (made in Tiled) loads on server, navigation data exists for walking, objects like Doors exist.
- Spatial hashing and proximity based replication (sphere of influence).

Then I want to record the first video (10-15 seconds) of two players just walking around.

 

[Lance Treiber]

Each folder with code in Go is a package, which is a sort of a namespace.
Packages can't have circular dependencies. In C# it's not a problem for classes or even namespaces, in C++ you can forward declare classes. In here, you just can't do it.

Which means your entire project hierarchy has to be flat. Everything is intertwined in games. So all code files have to reside in one big directory.

For example, I have a WorldLoader package that reads .xml files from Tiled and creates *World, which has navigation data. The navigation data is an array of Cells (or grids... I have grid-based movement). Cells can have *Players on them. Players are in the Game Package. Game package uses WorldLoader. Circular dependency.

On the plus side, it builds fast...

A nice thing that surprised me - you can build to any platform from any platform out of the box.

Found an interesting thing for Unity: https://github.com/jacksondunstan/UnityNativeScripting - You can code in C++ and it builds faster. I'd rather not, though.
Also found this: https://github.com/RobinKa/netprints - god it's ugly:

 

[Norfleet]

I hope you've already started thinking of your game's security, because if security and validation of input aren't built into the game from the beginning, your game is gonna get torn a new asshole.

 

[Lance Treiber]

Sure. The only thing I haven't thought about yet is how to handle DDoS.
Recently Steam introduced a new network feature to their SDK which allows you to reroute all traffic through their servers, and it's got biult-in DDoS protection. Unfortunately, only for Steam games and I'm developing a mobile game here. There must be some services out there for us non-steam devs, but I don't care about it yet.

Anyway, wanted to share these findings:
https://github.com/hwaet/UnityProjectCloner - allows you to launch multiple instances of your game on Unity using symlinks. Useful for launching multiple clients to debug online games. Very cool.

Found this gem and it's very similar to what I'm making, both in terms of graphics and gameplay, and it's got 5 million installs. Very nice and confidence-inspiring.


Interesting Go stuff: https://songlh.github.io/paper/go-study.pdf

 

[Duckard]

I don't care about MMOs, but keep posting technical stuff. It's interesting.

 

[you know what time it is]

MMO from a GD perspective is a fucking nightmare, I remember trying to pen down a basic systems concept one day...

But you seem to progress at a steady pace and have a different outlook on the whole thing which is nice to see.



Keep us posted on the tech stuff.