Last night I finished updates that focused on how these procedurally-generated planets are textured and I will be sharing screenshots of that progress later this week. Beyond that, the majority of work since my last article has been behind the scenes stuff. I had originally planned on making the custom software I am creating to help manage this game be the focus of this article, but the software isn't quite ready for that yet. I add features to my admin program as I need them, and as I find myself needing - and then adding - more features, I'll eventually reach a point where it warrants its own post. For now, suffice it to say that it makes managing my database records much more intuitive and efficient and so far has proven to be much more time-saving than time-consuming.
Project Vague has undergone some major changes since we first started the project. We didn't add the game to IndieDB until after these changes had been implemented, so today I figured I would take everyone through the process that led to its current state.
MMO's are a unique beast in that they generally exist in a persistent world and that any number of players can play together in the same persistent world. Personally, I have always loved MMO's for that reason: I always started with a plan, but that plan would almost always go awry in the best ways possible. Maybe I had intended to do a specific raid but instead came upon a fairly inexperienced player along the way and saw that they could use some help. What had started as a short trip to the city ended up in an hours-worth of fun helping someone learn the ropes, and the reward I received from the game itself was non-existent beyond simply playing. I never needed to leave my game when my friend popped online either; I simply grouped up with them and then we would meet up somewhere in the middle. This world we were in had existed long before we ever rolled new characters and it would continue to exist if we decided to play another game for a few months.
That's why I love MMO's. My time never feels for naught because what I have done has been done permanently. I have not played World of Warcraft for years, but I know that if I logged in today that my nifty little weather-maker would still be sitting in my bag - a rare item I received from a pack of WoWTCG cards back in my 20's. I loved that item not because I never once ran across someone else who had one (I'm sure plenty do, I just never happened upon one of them myself), but because it was a great conversation starter. I'd be riding on a zeppelin and spawn a rainstorm over my head and every once in a while someone else on the same ride would ask about it, and every once in a while that person and I would end up questing together. I rarely felt the need to quest with that person again, it was simply a day spent with a stranger due to the fact that we happened to be logged in at the same time at the same place. That weather machine is still there in my pack even though I can't remember the last time I played WoW.
Behind the scenes, an MMO works similar to a standard multiplayer room with one big exception, and that difference is often referred to as a player's Area-of-Interest (AOI for short). This feature is essentially what allows for the first M in MMO; it's what allows the number of players in the same room to be a massive number.
If you take your standard multiplayer game then chances are you have a relatively small number when it comes to the maximum number of players you can have per room. The reason for this is that every player in that room is sending a lot of information to every other player in the room; as the number of players increases, the server not only is now receiving even more data than before, but it needs to send that data out to every other player in the room. Add to that the fact that now every other player's data now needs to be sent to the new player as well, and you can likely see how you can reach massive amounts of data with just a few dozen players.
MMO's circumvent this issue by maintaining the world and the player's within it and delegating who needs what data and when. My netcode does a lot of things, but one of the most important things it does is to serve as a sort-of switchboard operator, constantly checking to see who is where, and where that is in relation to other players and objects so that the data that is sent back to that player (and all other players) can be stripped down to only what is necessary.
When I first started this project I created the video below to demonstrate how an AOI works. You can envision the AOI as a bubble that surrounds the player, and as the player moves through the world the server determines what has entered and exited this bubble. Move too far away from another player and that player's data is now inconsequential to you; move back towards them and once again you will need to know where they are in the world and what they're doing. The client is a dummy in this aspect: it serves its purpose as an interface for the player to send/receive requests to the server and also as a visual representation of the data that the server sends to the client, and that is about it. The world exists on the server in the form of database records which the server interprets, calculates, and categorizes; when needed, it sends this data to appropriate players and the dummy client is updated to render these changes in a way that makes sense to the player.
In the video below the AOI is represented as a semi-transparent green box that surrounds the player. For the purposes of this demonstration the AOI has been significantly reduced in scale in order to exaggerate what happens as the player sends position updates to the server. What is important here is that the client is only representing what the server has said needs to be represented; when the server says "this guy is outside the AOI," the client responds by removing that player's representative gameobject. The client is only doing what it's told while simultaneously giving me a means through which I can ask the server for permission to perform certain tasks.
The video starts with a birds-eye view and then moves to the third-person view that is used in-game, and lastly the AOI gets increased and hidden to provide an example of how increasing the size of the AOI can become effective at hiding when other players enter/exit its bounds.
The system works very similarly when it comes to NPC's and any world-object that a player can interact with. A treasure chest would be a great example of an MMO item, or an item that the server needs to keep track of. If a player opens this treasure chest then all other clients within the AOI will need to know that it has been opened and play the appropriate animation as well as set ownership to prevent other players from looting the chest while someone else is looking at its contents. This happens by the client sending a request to the server which then determines whether the player has the authority to open the object as well as whether the players current position is actually within range to open it; the server then sends a response to the player that lets the client know whether their attempt was successful, and if anything has changed that other players in the are might need to be aware of, it also sends that update to everyone in that items AOI. Conversely, players that are outside of the AOI don't need their clients updated, but rather would only need to know the state of the chest if they entered the AOI and begin receiving updates for it while they were within the AOI. Once they leave this range, their client no longer cares what happens to that chest.
Project Vague started as a fantasy-themed MMO that took place on a relatively flat terrain; I have spent months updating the server-side framework to use these same concepts in a simulated universe, one in which the player is not limited to walking on the ground nor are they limited to a single planet. When another player is on a different planet than the one I am currently on, my client doesn't need to know much at all - if anything - about what they are doing or what is going on around them; that data only becomes relevant after I jump in my ship and travel to an area of the system in which our AOI's intersect. Since everything is procedurally generated server-side, what would have been the starting area of a single world has now become a starting planet that the player is free to roam around on, collecting whatever it is they may need (potentially with the help of friends or even strangers) in order to get their ship ready to take off and go wherever fate takes them; while all of this happens, seasoned players who are in different planetary systems are none the wiser as to what is happening on this particular planet, and so all the data that they would have needed is no longer needed by their client.
I still have a small checklist of items to fix before this game is ready for a demo. My warping system is only half-done and at some point I'll need to dedicate the better part of a weekend to finishing it. I have two remaining bugs when it comes to ensuring clients are in sync when they first enter each others AOI's. Everything works fine if both players start in the same place and if any entering/exiting of their ship is done within range of each other; however, if I exit my ship while outside a remote player's AOI and then we come within range of each other again, I'll only see an avatar floating in deep space when they come flying by. In all honesty the fact that this bug is fairly amusing to see during gameplay is one of the reasons I haven't put the time in to fix it yet.
I can, however, fly all over a planetary system - both entering and exiting remote players AOI's - and there are no issues whatsoever. If I warp to another planet (currently empty space, but there will be a planet there soon) and then a remote client warps in, everything happens as expected since the player was inside the ship before and after my warp. The amusement stems from a remote player warping when the bug presents itself, resulting in what can only be described as Flash on steroids in outer space.
The first major goal for this project is to get a single planetary system in place and ready to demo, with as many bugs as myself and those involved in alpha testing can find getting fixed, which should provide me with more than enough room to accommodate a few hundred players at the very least. With 80 square kilometers available on this one planet and 4-5 planets planned for this system, I think there will be plenty of room for anyone who wants to give this game a try. I am expecting a lot of bugs in those first few trial runs, and have been adding more and more to my custom admin system to make the process as simple as possible. As I stated earlier, I will go into details on the admin software at a later date, but I do want to point out that players will be able to report bugs while in-game and do so without interrupting gameplay, and the server will hand that report off to my admin dashboard which keeps track of all bug reports, bugs, my to-do list, and many other aspects of the game. Organization will be key to the success of this project, and any time I can put in now to make things easier for myself and anyone else in the future is time well-spent.
It likely seems like a fairly simple process to go from a flat terrain and a fantasy theme to spherical planets and a sci-fi theme, but there are quite a few issues on the server side of things that come up when you do this; issues that took me a long time to solve and only came about after several failed attempts to get it right. One of the bigger issues I faced was coming up with a way to allow for tens of thousands of resource deposits per planet without bogging down either the server or the client. Another issue comes from the extra data required to share the position and rotation of space ships that players are piloting. In fact, the list of issues was so long that I all-but disappeared from the internet for several months as I worked (or more accurately, fought) to come up with solutions. I'll be sharing some of these solutions in future articles, but for now it's back to the salt mines so that I can start getting a demo in the hands of players.
