Continuous Integration and Scrum on Goldsource mapping

Posted 1 week ago2021-07-20 20:55:21 UTC
I somehow convinced myself it would be fun to integrate some of the principles I learned in Software Development back in my mapping methodology (assuming it even existed back then).

For this reason, I made use of the brief period of free time I had between quitting my first job and starting my second one to do just that. (Please don’t comment on my use of free time, I know I’m not doing great.)

First of all, I adopted and adapted the Scrum methodology to Goldsource mapping. I first established a constantly growing list of features to implement and other to-do’s on Google Sheet (the product backlog) with their estimated effort (or story points, as Scrum calls them). I set the Sprint duration to one week. This meant that every week, I would first have to decide on a list of items to try to implement during this limited amount of time, implement them, and make the whole map look like somewhat "devilerable" product by the end of the week and test it (with other players, since it is for Sven Co-op). I also had an idea of how much I achieved by looking at the sum of the story points.

I also tried to use Continuous Integration for my map. I actually don’t think what I did really qualifies as CI, but I’m pretty sure this is as far as anyone will ever go to add CI to a Goldsource mapping project anyway. This first meant using Git (which is already extremely useful, even if not doing CI or Scrum). I included the executables the map relied upon for compiling in the repository (Resgen, the VHLT…), and made a script for compiling the map!
Now making this script was tricky but worth it. Choosing Batch wasn’t the best choice I could have made, but it does the trick. My script takes the map name as the first parameter, and the profile mode as the second (dev or prod). In prod mode, it compiles with higher VHLT parameters but, more importantly, it removes all the entities that start with _dev from the map file. These entities, when they are not removed (i.e. in dev mode), make the map easier to test and debug by removing certain doors, NPCs, turrets (damn turrets!), and giving me more weapons for instance.
The map file can be generated automatically using HLFix, and all the custom resources the map relies upon are automacillay copied in the build directory thanks to ResGen.
Thanks to this script, I can not only create a clean, redistribuable copy of my map whenever I want to (without fearing to forget files or include obsolete ones since the build folder is cleaned before each run), but I can also test my map using Travis! This means everytime I back up my work online (push it to Github), Travis can run the script and check that all is compiling well. Admittedly I don’t do this very often since it’s kinda useless to test the compilation process on a remote server and I don’t want to spam Travis too much.
And now, thanks to WadMaker, I could even go further and just store the original JPG files (or maybe even XCF files) in the repository and create the WAD on the fly in the script.

All in all, having a script streamline the compilation process makes things really much easier. Everything is included in the folder and I just need to move it to the game folder, or share it, which is really useful when testing regularly with other players. Having a dev mode also solved a problem I had whenever I started mapping. (Forgetting temporary dev entities in the final map, or on the opposite sitting through playing the map in its entirety just to test one room.) And for course, not having to run Hammer to build the map can also be convenient too.
I found that Scrum fit somewhat nicely the mapping process, although I’m not sure it always does since mapping is sometimes an erratic and unpredictible process. Having to test my map regularly was really useful too, first of all by making me find a way to easily make a redistribuable copy of the current version of my map, and also by allowing me to detect problems with my map early, be they gameplay or technical problems. I was thus able to review early the direction I wanted to take with my map and correct technical issues before it was too difficult to change things. This included wpolys too high, the map being too big because of its textures, or a puzzle that was too difficult…

If this script interests anyone, I’ll share it. :) What about you guys, do you also use similar methods or not at all?

2 Comments

Commented 1 week ago2021-07-21 06:58:17 UTC Comment #103618
I liked the part about automating the process! gj :cool:

Made some basic scripts to move stuff around and export and import entities in the past but had no need to go further.
Having a script to remove dev entities might be really useful, though!

Scrum.. now it feels more like product development rather than a hobby :biggrin:
Commented 1 week ago2021-07-21 11:50:31 UTC Comment #103619
Oh, nice! I really like your idea of of using _dev entities for test builds. I'm sure your script would be useful for some people. :)

This is giving me some ideas for improving MESS, a compile tool I made a while ago. Automating and speeding up the level-design process is an important reason why I made tools like MESS and WadMaker (and SpriteMaker, soon), and I'm thinking about making a 'smart' compile script that only runs csg with -onlyents if it does not detect any brushwork or lighting changes since the last compile.

You must log in to post a comment. You can login or register a new account.