Developing as a game in itself?

[jamespetts]

I have recently been watching some interesting Youtube videos on the channel, The Game Maker's Toolkit, and happened upon the following video:

In it, the person who runs the channel discusses the difference between games that set specific puzzles that have a pre-set solution, and games (such as Civilization) that are entirely open and allow for the player to design their own way of doing things. Simutrans, of course, falls into that latter category, although he does not mention us, sadly (perhaps we should all post comments on his channel urging him to talk about Simutrans).

What is particularly interesting, however, is that he speaks of many independent games recently using coding/programming as a game mechanic in and of itself. Is there a certain sense in which those of us who work on developing this game are getting the same sort of rewards by developing the game as people can get from playing these coding based games? That certainly seems to match my experience: I do enjoy seeing the transport networks that people create with Simutrans-Experimental and then modifying the game design to make the players play more realistically and eliminate exploits (such as excessively short runways for aircraft, networks of underground 'bus roads in every city, or using the most powerful express locomotive for every train to the exclusion of all other rolling stock).

Does this fit with others' experiences of developing, too?

[DrSuperGood]

I am an electronic and software engineer. I just like most code and the elegance of it. Even if it is something quite boring such as a data compressor I might look at the code and absorb and appreciate how the solved the problems. Simutrans fascinated me because in the end the answer to all game questions is there in the source code everyone is free to download, modify and build. It is also one of the few, well developed, games that are like that so the idea of seeing how a game worked would be most enlightening.

When I looked at the code I was not too happy with some of it, which is why I created several patches (*cough* one still pending *cough*) to try and improve on it. However simutrans is not the only game I am involved with. Long before I found Simutrans I was messing around with Warcraft III which pretty much was king of independent modding for nearly a decade before other games like Minecraft and engines like Unity came about. In fact WC3 inspired me to go onto study programming and all the experience I had with it likely ended up helping me.

[jameskuyper]

I haven't done game development, but I have played around with scenario development for several games which provide that option. At times, I've found myself trying to do things using the scenario scripting system that would be easier to implement as changes to the game code itself - if I knew how to do so. As a player, I find the concept of programming as a game mechanic very interesting.

I gave some thought recently to the fact that, with every game of the type I most enjoy, sooner or later I reach a point where the game ceases to be fun, and just becomes work. I realized that I don't want to get involved in the detailed operations of an Empire (Civilization III, Freecol), City (Caesar III/Pharaoh/Emperor, SimCity) or a transportation network (Railroad Tycoon, Simutrans). What I want to do is design those systems so they run automatically, and then sit back and watch my automation run (and periodically intervene when it doesn't work right). Caesar III/Pharoah/Emperor cities run fairly automatically, once set up. The same might seem to be true of Simutrans, because you have a lot of control over the transportation lines. However, the available technology is constantly changing, and if I do a good job of serving my city's needs, new factories pop-up faster than I can build new track and buy new trains to serve those factories.

What I would love to do, in any of those games, is just write a subroutine which gets called each turn (I can enjoy playing pausable real-time games like Simutrans, but i prefer turn-based games), and is given information about the current game state, and which has available to it tools which can be used to perform any action that a human player would be permitted to perform. In it's most sophisticated form that subroutine would analyze the information about the game state, present that analysis to me in a convenient form, make suggestions about what decisions I should make during the coming turn, and provide a convenient interface to modify those decisions (along with analyses of the consequences of my modifications).

For Simutrans, for instance, one of the key things I'd like such a subroutine to do would be to determine the configuration of the most profitable convoy type for transporting a given good along a given path. There's so many decisions to make: which way-type, which track-type, which vehicle type. For road transport, I have to consider every combination of one tractor and one trailer, which for some pak sets and some time periods can be a lot of combinations. For the other land way-types, it's worse: I need to also decide how many cars to put in the convoy. There's one particular convoy configuration that is most profitable, and being the kind of person I am, I need to perform the calculations to assure myself that I've found that most-profitable configuration. I'm not comfortable with just guessing or using simplifying assumptions. This, in turn, means that I need to transfer a lot of information by hand from the game to my spreadsheets. It would be much simpler if I could easily write a routine which interfaced with the game program itself, and extracted the information programmatically.

One of the key pieces of information I need for my profitability calculations is the round-trip travel time - this determines how many copies of the convoy will be needed to transport the specified amount of goods each month. That in turn determines how crowded the track will be, and whether I need to create multiple parallel tracks to deal with the load, or whether the track will be under-used, allowing other goods to be transported on the same track. The travel time should  ideally be calculated taking into consideration the time lost due to acceleration and deceleration, including for curves and slopes. Currently, the only way to determine that value is to run tests. When there's dozens of possible configurations for a convoy, that's way too many tests to perform for this purpose. However, the information needed to calculate the round-trip travel time necessarily resides within the game code, so with programmatic access to that information, I could directly evaluate the round-trip travel time for each possible convoy configuration, in order to determine the most profitable one.

[jamespetts]

Interesting. If you like automation, apparently the game "Factorio" might be of interest to you, if you have not already discovered it: I have not played it myself, but have heard from somebody (who is a professional software developer) that he finds that it provides hours of amusement, and he has great fun in just optimising his automatic setups.

As for round trip time, this is calculated in Simutrans-Experimental, albeit only from actual data collected in game from travelling convoys, so this is not available in advance (which would be much harder to implement).