Ask HN: Why don't games allow you to automate some gameplay via programming?
Wouldn't this be a great way to encourage young people to learn programming?
For example, a game like No Man's Sky could have a python-like language that you can use to automate some repetitive tasks.
41 comments
[ 2.1 ms ] story [ 89.4 ms ] threadPlus, there's no reason why the entire game couldn't be automated, at which point it's no longer a game.
But, I agree it would be cool if at least some of the logic was exposed an editable. One tricky part would be endless loops or overloading memory, so they would need to be careful about the actions that they make programmable.
Might even be a fun way to recruit future dev talent for the gaming company.
[1] https://battlecode.org/
I say this as an experienced programmer who never modded a game before and was induced to write one [1] by this capability. It also made me learn Lua, and I'm glad I did!
To more directly answer your question, it's a lot of work for developers to permit any kind of UGC (user-generated content) and modding definitely falls in this category. One reason Lua is so popular as a modding language is that it creates an absolute sandbox and can even individually sandbox functions and language elements, making it ideal for allowing users to code against some aspects of the game but not all of them -- and not giving access to any of the game's code itself. These are always factors if you allow any user code.
[0] https://mod.io/g
[1] https://mod.io/g/foundation/m/barrel-ofish
Because FFXI was released as a PS2 game, it had a ton of limitations, most notably around gear swaps. In the game, you had 16 gear slots on your character, but hundreds of pieces you could equip in there that would improve various actions, abilities, or spells. The built-in macro system had to be PS2 compliant, so it was only capable of swapping so many gear pieces with any given button press (basically like five pieces, when you really might want to swap all 16).
While not supported on the PS2 versions, third-party tools such as Windower allowed folks to install extensions that were Lua programmed that brought a ton of additional functionality to those playing on PC. One of those was the "Gearswap" extension, which allowed you to finally swap all 16 pieces of gear simultaneously, and even do so based on actions that weren't button presses (such as say, if I'm poisoned, equip gear that enhances regen effects).
This sort of thing was such a game-changer (literally) that you basically couldn't play the game effectively without it. Square-Enix even sort of turned a blind eye to it, despite breaking their ToS rules against third party tools, simply because most players had started doing it and they knew they weren't able to program around the PS2 limitations.
It was definitely my first intro to Lua within FFXI, and it helped foster a great love of programming that I turned into a career. I believe more games should make this sort of thing officially available, it's just plain awesome.
For some time I played MtG competitively, an activity that involved me paying money for pieces of cardboard.
Treating a game as though it's productivity software is an incorrect point of view.
[0] https://www.jstor.org/stable/186102
2) The goal of a game designer is to create fun experiences that you actually want to do. If game designers announce they're including scripting for the purpose of automating repetitive tasks, it would probably feel embarrassing to them because any boring and repetitive parts of their games should feel like kind of a personal failure on them.
3) I'm not a full-time professional game developer, but I'd imagine that trying to implement some kind of highly polished scripting that's user-accessible represents a significant additional effort in many cases for very marginal financial benefits. It's not just building this feature that would be required, but you'd be introducing a potential new security/stability risk that would need to be extensively checked, as well as having a big system that needs to be documented and supported for users.
Also, you don't want to make it easy for gamers to use other people's code.
Rather, you want gamers to write their own code.
That era is gone. Devs want more control now and most games have elaborate cash-shop business models. They don't want the gameplay to be modifiable.
That said, I still think that this kind of feature is a non-trivial amount of extra work to polish up enough even for advanced users.
In 2006 Square-Enix shipped a simple programmable system for gameplay automation with the gambit system in Final Fantasy XII. It let you put together a hierarchical list of if->then statements for how characters behaved during battle. It essentially let players "equip" a battle strategy the same way they would equip weapons or armor. This seemed like something highly desirable, since Final Fantasy (and JRPGs in general) had lots of repetitive, grind-y encounters where the tactics didn't change from battle to battle.
People hated it. The popular dismissive criticism was, "Who wants to sit and watch a game play itself?" Players were used to picking and timing all their actions by hand during battles. Many Final Fantasy players back then resented the game "taking away" something they expected and wanted in the game. (It didn't; you could turn gambits off at any time and play the old way, but players got mad anyway because the gambit system seemed like how you were "supposed" to play it.)
In the years since there's been a much more positive re-evaluation. As of the 2017 release of the remastered Final Fantasy XII: The Zodiac Age, most of the retrospective reviews had come around to "actually, the gambit system is really clever." But the initial response was so strongly negative that we've never seen the like again in a Final Fantasy game.
There are some games where things not being automated is, for many players, the whole point.
By automating combat Final Fantasy XII basically made a big hole in the very heart of the game.
Contrast that with something like Minecraft where ComputerCraft is very popular. CompterCraft allows you to program robots to do boring, tedious tasks using Lua. It frees up the player to do more exploration or building, which is the heart of Minecraft.
I personally find it less engaging and very MMO-like - I'm not an MMO guy so I would not want to see the gambit system come back. I respect it however and am glad they tried something new. Its influences can be seen in later games.
Programmers do. Everyone else, not so much. For those of us that do though, there are a lot of good games to that effect, like Factorio, Rimworld, Dwarf Fortress, RimWorld, etc.
On the other hand, people modify and script games anyway. It happen for both games that permit it, and games that condone it, and even for games that try to prevent it. It takes the form of mods and cheats.
And lastly, as other have pointed out, there's plenty of games that are actually designed to be played through scripting. I'll add one example here that I've enjoyed playing a little: https://screeps.com/
Several major early, famous Kickstarters were "teach programming as a game" games such as Codemancer and (board game) Robot Turtles.
It will likely never be a mainstream thing in games. There are too many risks that giving access to programming scripts inside of games might accidentally "ruin" the intended experience: both in terms of users automating a game too much and finding it boring, and in users finding exploits and hacking the game into unintended states.
Still, it's always great to see explorations of it even if it is kept mostly to its own mini-genre. I know that some of the programming-inspired puzzles in The Castle of Dr. Brain and the Island of Dr. Brain were quite influential to me at certain ages.
It’s kind of unfair to bot. You would need to create a game that has unfair systems that would be cruel for a human being to play manually. Then programming the game becomes fun.
Early WoW grinding was a little unfair (many MMOs can be). I wish I could legitimately write bots for Eve Online for example. The current incarnation of dealing with said cruelty is auto-play (your character literally plays automatically, like a bot) in mobile MMOs, but I can imagine developers getting some joy out of an absurd MMO where programming what your character does requires scripting it. These would very advanced and niche games though.
There are some games where the core gameplay is programming, but those are their own niche.
>Wouldn't this be a great way to encourage young people to learn programming?
I don't see how it would. To be quite honest most this is how we teach kids software ideas are completely out of touch.
Nobody wants to play a game about shooting aliens and flying around a galaxy, but then suddenly has to figure out how to learn some stupid scripting language to minmax.
The reality is that most children (and adults) do not care about software and never will. You shouldn't be appealing to everyone, you should be appealing to those who show interest and engagement. Give them something to experiment and break, that is how you learn.
You learn this very rapidly in IT. Eventually, you learn that the reasoning you give people is "because you called me to fix it". They dont care, they just want to make sure you arent jipping them. But if they cant understand, they cant be sure! It makes a lot of hover-bodies that make a lot of annoyance.
Still has a pretty active community, and the gameplay revolves around programming your 'Leek' to fight other leeks in a battle-bot type situation. The language you write the code in isn't python-like (it's called LeekScript), but it's easy to pick up.
At the end of the day, games purposely put challenges in front of you because they are games, not because they are trying to optimize for efficiency.
There are factory-style games where the game IS about making algorithms and dealing with bottlenecks and such (Factorio, Satisfactory, Dyson Sphere Project) and/or programming games like Leek Wars or Autonauts and/or idle-battlers (especially on mobile) that automate much of the fighting and looting and such (Necrosmith).
The selection "games that would be improved by end-user programming without being made trivial" is probably pretty small. Most games aren't really that hard, just grindy and/or twitchy.