I’m not sure how AAA game publishers roll out online games, but I always envision layers of complex interactions between multiple on-prem and cloud services securely talking business while getting the job done. I may be giving them the benefit of the doubt, but this is what I like to dream, at least.
My Vision
It’s my hope to have a fairly sustainable method of maintaining and managing the game environment while keeping layers separate from each other. The goal is to have three main ways to interact with the API:
- The client website (the actual game)
- The management website
- CLI Tools
The Client Website
This will be the most daunting task for me as I really want to use something JavaScript flavored. My strong point is not JS right now, so it will take a lot of heavy lifting to translate what I know about Python to JS. I know that the way forward is a JS framework (Vue, React, Nuxt, etc.), but I don’t have the free cycles just yet to learn JS web development. I may do some prototyping in python + flask for now.
The Management Website
This is an important tool in the mix as it will serve as a way to observe and manage the running instances of the NTW games as well as manage users and interactions (such as sending mass notifications). You already saw a preview of the interface in my last blog entry about building my own blogging platform. Managing the game blog and the running games will be driven by the same management platform.
The key concept is that the website will not be able to make game breaking changes—only smaller changes such as tweaking systems or specific configuration changes. Major changes will be handled by a CLI tool.
CLI Tools
The final piece of the puzzle is the CLI platform. This is a very low level interaction that creates instances of the game, populates the game with star systems, planets, NPCs, and star gates. The CLI will be the only tool that can do things like delete and create. I am using the CMD2 library for Python to create the CLI shell. I’m still in the planning phases for features between CLI and management website, but between the two of them I will create the suite of tools I need to ensure a smooth gameplay (at least from a back-end perspective). The major takeaway for the CLI is that it cannot interact with the user layer things (such as accounts or settings/preferences). It will only have the ability to adjust the core game.
I recently modified the backend library from CMD to CMD2, so I am sorting out some differences, but I’ll show off the game instance creation process when that gets sorted. Below is a small glimpse as to what I have built out so far.
Parting Thoughts
One of the main security aspects that I am looking at is being able to scope each tool of the game into being able to only interact with the things they should be able to interact with. I will deploy each with their own API key that will ensure they’re able to talk where I intend them to. It’s not Fort Knox, but it will definitely help keep everything safe.
I’m looking forward to sharing more as I continue this development process! Check the development blog for a new faction preview of the Nanoforge Syndicate.