I recently left my job at a startup in Los Angeles, CA and moved back to Madison, WI to start my own game studio. It was not an easy decision to make but I decided that I wanted to work on something of my own again. Once I got back to Wisconsin I got started right away and created a new company called Boppy Games, LLC. I needed to come up with a company name quickly and Boppy was a nickname I had been using over the last few years. Its likely the name of the company will change in the future, but for now it’s fine. I’ve been back for about a month now and I thought I would share my progress. I think I will release a blog post on a bi-weekly schedule just talking about the things I’m working on since I’ve gotten quite a few requests from people who are wondering what I’m doing.
The way things are listed here isn’t the order in which I did things but I thought I would list what I’ve been working on in order that makes the most sense for the reader.
Procedural Terrain Generation
One of the first things I knew I wanted in my game was a large map. I wasn’t sure right away if I wanted it procedurally generated but I thought I would give it a try because I hadn’t done it before and after a few hours I decided it was within the realm of things I could do well.
The primary objective of my procedural terrain generator is that I wanted to be able to modify the terrain generator at runtime and regenerate the terrain. This is important because I knew the terrain would be a critical aspect of the game so iterating quickly on the algorithm was crucial. I decided that the actual algorithm “code” will be done using Unity’s Bolt plugin. This was just done by attaching a macro to the terrain and then at runtime using a custom event that starts the macro and works on the data attached to that object.
Here is an example of the code that generates the dirt texture:
To explain this script simply, the input is just a Vector2 of the position that needs to be generated. The ouput will be a float value between 0 and 1, which determines the “strength” of this particular generator. You can see the source of the noise I’m using is perlin noise and I’m just using some custom clamping and interpolation functions to cut up and resize the noise. All of the generators I’m using right now are basically the same as this one with different values for clamping and resizing.
Here is a top-down view of the output of the terrain generator:
So far on this map we just have grass, dirt and some simple resource patches that I will explain in a later blog post.
I’ve been doing professional game development for over 3 years now and I’ve decided that I want to get things started on the right foot for once, so I spent about a week building a testsuite that will run on my code whenever I push a branch. The testsuite is running on a VM on my server which I will talk about in the next section. My testsuite program was built using Windows Presentation Foundation (WPF). I had some basic requirements for the testsuite, the most important is I wanted to be able to quickly start/stop/restart the testsuite program and also run the testsuite program manually on a branch if I want. Here is the UI I came up with:
Its not fancy because the amount of time I’ll actually be looking at this UI is very small. Also the only things I’ve redacted from this image are the hosting prefix which contains the IP address of the server and the email configuration, everything else is left untouched. This program is running on my server that I really never log into unless there’s a problem which there hasn’t been yet since I started the server.
The way this program works is when I push a branch to my private Github repository, Github will send my server an HTTP request that contains the name of the branch that was pushed. I take this information and I do a local git fetch, checkout, pull on that branch. Then the testsuite program just runs a script within the project. When the script execution completes the testsuite searches the output for “Testsuite passed” and if it doesn’t find that string then the testsuite failed. When the testsuite run is complete an email is sent which includes the status of all of the tests that were run and the amount of time it took to complete the run. Here is an example of what one of those emails looks like:
This testsuite has been extremely useful so far and I will continue to make improvements to it in the future.
Before I could get started writing game code I wanted to get some simple development infrastructure working properly to speed things up significantly. This is actually what I spent most of my first week on.
I knew I was going to be using a lot of VMs and I needed a file share for sharing documents and builds on the local network. Its extremely useful to have a file share connected to your workstation and all of your VMs so you can quickly move files in between machines and have certain files (ssh keys, common scripts, etc.) available to all machines. In order to address these issues I’m using UNRAID on my old gaming desktop. With UNRAID you can create protected shares and VMs quickly and everything just works properly right out of the box. You can even pass through certain hardware, like your graphics card, directly to a VM. For example, I have a windows instance running in a VM that has direct access to a GTX 1060 so it can run Unity really well even from inside of a VM.
That wraps it up for this post. I will do another post in 2 weeks which will have a lot more updates related to actual gameplay. I want to try to release some playables if I can and the game I’m working on is multiplayer so I will eventually do public playtests in the future where everyone can play together. The game is still too small and underdeveloped at this point for me to make a Discord server but I will make one in the future.
Thanks for reading!