• Created procedurally generated real time strategy game
• Created node and time based resources
• Prototyped online gameplay
Using a procedurally generated asymmetric board (more akin to a tangled web) consisting of nodes of variable inputs between them, I intend to create a strategic multiplayer experience where players are constantly scavenging the map for information. In doing so, I will make a real time strategy experience in which players will spend time reading the map to inform their decisions about their resources and territory placement verses their enemies; highlighting elements more akin to real war: uncertainty, territory, tactical planning, and inquiry.
Research and Development:
While conducting research into strategy games, a major component in them was the replay-ability factor. Some games do this well like rogue-likes, but for a real time strategy (RTS) multiplayer game, I found that most games devolve into a dominant map controlling play-style. To avoid the strategy of the game becoming more about execution, I implemented a procedurally generated map that would provide a new experience for players to wrap their heads around.
At the same time, I wanted to avoid the traditional RTS logic of: 'whichever player has the most actions per minute wins!' I devised a resource that didn’t require management, but was just something that actively grew. As the player experience at this point in development consisted of players reading the map, it made sense to make time the resource, as it could reward players for short bursts of conquest, or a large spending of resources.
Overall, I thought I had a pretty interesting idea going in. All I needed to do was get the mechanics, and a real-time network simulation up and running. I felt this was the only way to truly test the experience, although I could have abstracted it to a turn-based format. This way would provide a more accurate simulation to the experience I was trying to build.
Early procedural generation tests
While I only had two weeks to finish the prototype, it wasn't enough time to fix all the networking bugs that comes with making an online multiplayer prototype. The game's architecture supports up to unlimited players, as long as the colors are serialized. For this reason, I originally capped the max number of players at eight. However, with some testing I found that this many players caused the server solution to become unstable. I lowered the amount of players to 4, but the problem still persisted. So I eventually decided to advertise the experience as just being 2 player, and to add more players at your own risk.
Another problem I had was syncing all the clients up with the host. As I was using HTTP Get Requests for the server, I needed to make sure every data point was verified, so the map successfully carried over between the host and all the clients. I added a loading screen which depending on how many players would enter the game, would be insanely long for a couple of minutes of game-play.