Update 4: Continuous Deployment with Docker, K8S & JPMS
So at the end of update 3, I mentioned how I had stabilized the game into a demo-worthy state which allows for basic multiplayer battles. I just uploaded the following video which contains some of the gameplay we've had with friends and illustrates that state:
First combat interactions video on Youtube
That's about when I decided to pause functional development for a bit and focus on things like packaging, public server deployments, and continuous integration. The reason behind that is that these things need to be implemented sooner or later and once they're in place, they save everybody a lot of time (both developers and players). So I went ahead and automated the packaging of the Windows version of the client as a state-of-the-art, native JPackage MSI installer for Windows which you can see the following short demo video:
JPackage native installer demo video on Youtube
But you can of course also install the client yourself and give the game a shot (check out the FAQ section to grab the installation link). As far as the build automation platform, I decided to start designing my build pipelines in TeamCity Cloud (https://www.jetbrains.com/teamcity/cloud/ ) which is wrapping up its open-beta and currently offers free build agents.
With that done, I dockerized my server runtime image and started focusing on a second build automation pipeline, based on linux agents this time, which not only build and publish the corresponding docker image for the game servers, but also deploy that new image automatically on a development instance of the server, both in European and in North-American clusters.
You can check out the details about my build pipeline and continuous deployment strategy in the following screenshot:
I basically designed the pipeline so that changes pushed to the code repository are reflected within less than 5 minutes on the development servers, and with minimal service interruption (about 30 seconds of downtime), thanks to Kubernetes (https://kubernetes.io/). Images as well as deployments are tagged with the corresponding VCS (git) revision so I know for sure which version of the code is currently deployed. Kubernetes has the perk of coming with a nice monitoring dashboard so it's easy to track what your pods (in my case, my game servers) are doing and whether they're in a healthy state or not. The production servers on the other hand are only updated and redeployed when I explicitly request it, i.e when I increment the root version of the project. And so when you install the client as a player, by default you are directed to the production servers but if you wish to do so you can can change the config to access development instances. This by the way, is the way the European cluster's dashboard looks right now: you can see the active deployments for development and production (labeled "dev" and "prod"), the corresponding pods, the software images they're currently running as well as a real-time overview of their CPU and Memory usage:
This one point regarding having to change the client's config to log onto different server types and server realms leads me to my next task and the final piece of this big CI/CD puzzle for this phase at least: the auto-updater. It's nice to be able to redeploy server software automatically and almost instantly, but it's of little use, or at the very least, it's pretty painful, if people wanting to play on the development instance to provide feedback need to constantly uninstall and reinstall the client manually. That's why I started implementing a smarter, lightweight version of the client which will not only figure out automatically which version you need based on the server you're attempting to connect to, download and start that version of the client for you, but it will also contain a visual menu that will allow players to pick which realm (Europe or North-America) and which instance type (development or production) they wish to connect to. With that, I hope iterations with our players will be blazing fast, effective and as smooth as can be. I feel it's the least I can do for the people who care enough about what we're doing to take the time to log on and play with us!
In the next update, I will go back to addressing topics related to the core combat interactions as well as pure gameplay. I might mention a few things about website development as well! Peace.
Project Visionaries - MMORPG
An isometric post-apocalyptic MMO RPG focused on replayability
Status | In development |
Author | PVDev |
Genre | Role Playing |
Tags | 2D, Action RPG, Isometric, libGDX, mmo, MMORPG, Multiplayer, Post-apocalyptic, PvP |
Languages | English |
Accessibility | Configurable controls |
More posts
- Update 17: Item Management & new assetsNov 23, 2021
- Update 16: Loot, UI work & scalabilityAug 21, 2021
- Update 15: New skills, map & UI featuresJul 30, 2021
- Update 14: Fog of War and Network issuesJul 02, 2021
- Update 13: Multi-world management and more UI workMay 30, 2021
- Update 12: Asynchronous rendering & asset loading, UI skinningMay 12, 2021
- Update 11: Tile interactions & merged renderingApr 21, 2021
- Update 10: Pathfinding, Lighting, and a New map!Apr 21, 2021
- Update 9: The foundations of PvMApr 21, 2021
- Update 8: Reworking animationsApr 21, 2021
Leave a comment
Log in with itch.io to leave a comment.