Comment by Danieru | Hacker News Reader

Comment by Danieru | Hacker News Reader

This thread is speaking to how regular programing and game play programming vastly differ.

In regular programming scopes are small, small enough for programmers to accomodate all expected logic. In games interaction scope is unlimited, or atleast that is what the game designers want.

If you try to program every expected system interaction you would never finish. So instead game programming is about making systems flexible. For example, as far as the gameplay code is concerned the inside of players ship is just yet another level. The bounds of any level are defined by what the map designers have layed out, not any pre-planned "ship area".

There are no meetings where project managers request "more playable area for level 7".

Likewise the systems programmer who made the furniture system was not the script writer who created the ladders. The script writer likely thought it was brilliant and elegant to split the entrances and exits, because in game programming it was indeed brilliant. It allowed the save system's existing code to handling what would have otherwise been special handling. It allowed the existing combat logic to handling what would otherwise be special handling.

Of course regular programming is different. In regular applications if a user's data is being sent to a server there is no secondary system which needs to be allowed to kill this data. Nor is there any save system which needs to be able to save and restore an in-progress action.

Games programming is all about figuring out ways to allow more varied and more complex interactions without exploding the implementation exponentially.

This was an extreme insightful comment.

Originally, when I read the article, I thought that the issues described may be a result of bad software design.

But maybe it’s because applications are about strictness, and games are about freedom.

In application programming, you should be in a defined state most of the time, and make state transitions short and atomic.

In guess that in games, you are really in one huge, never-ending state transition.

I would also add to this that in my opinion often the best games (from a design perspective) are the ones that lean into this sort of freedom. This line of thinking has very much influenced game design trends, at least within certain genres. For example, simulation and survival games usually try to expose the game's systems to the player in a way that lets the player be creative in the game (Minecraft, Prison Architect, RimWorld, Factorio, etc). Even in games that aren't based on simulation or user generated content, designing the game's systems in this way gives the level creators freedom to do more without having to write code specific for every level.

Plus let's not forget the game industry is not known for great working conditions and lax deadlines and perfect specs.

Why is this a difference between "regular" programing and game play programming? Any kind of programming could have complex interactions between component. A few well known examples: OS kernel and drivers, VM manager, internet browser. The list is long, and there is a lot of programming of complicated products in the world - not everything is web development or CRUD apps.

Regular programming and game programming have different constaints and goals.

Yes regular programming could indeed add a system where numbers might be animated. During the animation maybe you want another system to be able to change the number. Maybe the number disappears, make sure you're front end can handle not having the requested data arriving. Maybe you want systems which add extra fields to user data, maybe you want anytime a user attempts login that there is a 1% chance they receive a reward determined by their "user rank".

All these are "possible" but do not happen in regular programming. If a user attempted to log into your application, and instead a window popped up saying "you have died from starvation, please recreate your account and play again" rightly so your users would be angry, not impressed.

Different constraints and goals lead to different priorities. Games on a per screen basis have a lot more budget available. Imagine if your application's login screen took 2 months to program and required the full time effort of multiple artists.

”Regular programming” and ”regular programming” have different constraints and goals. Unless you think that e.g. a sound card driver and a web browser are developed with the same goals in mind and under the same constraints, you agree that games are not exceptional in this regard.

IMO it is more useful to think of software and its development as simply more or less complex.

Also, your whole post basically ignores GP’s argument that not everything is either a CRUD app or a game. Maybe it would serve your argument better if you took care to read and respond to his.

I’m not a game programmer, but in complex systems I’ve programmed in the the past there are state machines that help you avoid problems.

It’s hard especially if functionality gets added mid process (the companion can die now).

I had a piece of code log (“you should never get here”) once before crashing. Some programmer long gone put a constraint check with that strange note.

I’m not a game programmer, but in complex systems I’ve programmed in the the past there are state machines that help you avoid problems.

It’s very hard especially if functionality gets added mid process (the companion can die now).

I had a piece of code log (“you should never get here”) once before crashing. Some programmer long gone put a constraint check with that strange note.

Games usually have state machines as well, but you can't have a single state machine for the whole world. So it ends up being a state machine per actor, usually - and every actor can potentially interact with most other actors.

If you think about it, games are by themselves are a prominent software engineering antipattern - what they model is a huge pile of global mutable state, where everything potentially depends on everything else, and changes happen asynchronously.

Oh that is a good way of thinking about it.

In a game, you often want unexpected and whimsical emergent behavior. You want designers to build new and exciting things the programmer never expected. Game logic is about fun. Correctness is very low on the list of requirements.

This is not the same kind of thing as bank software.

Regular programming is not different. You mention the case of users data being sent to a server. There is so much which can go wrong there when authentication, load balancing, session management, data storage, and network latencies interact.

It's not games that are the issue. Games like checkers or chess have less of this property.

The type of programs where things like this occur are called simulations.

Rather checkers and chess are just simpler games.

Much of what player consider progress in games is the industries ability to add more complexity. If you look at the contemporary equivalent to chess that would be the spin-off of MOBAs: AutoChess.

AutoChess may bare a similar name to chess but it is a vastly more complex game. In theory AutoChess could have been created on the NES, but no one would have understood how to keep the implementation reasonable.

Instead it took a progress, from Chess we got turn based strategy games. From TBS we got real time strategy games. From the early RTS games, we got the story rich Warcraft. From Warcraft came extensive modding support and story based characters. With said mod tooling and characters a series of mods became what we now know as LoL and MOBAs. Another decade and another set of mod support brought AutoChess.

Yes simulations are complex games, but what used to be a defined genre is now an aspect of most big games. Western RPGs certainly try to push the boundary of coplexity, as to tycoon or simulation games. Still, all genres are tending towards more complex systems.

While bugs in game programming are quite obscene, and the task of making a game quite arduous, all this tweet did was demonstrate how really bad code design will bite you in the ass if you're making games.

What exactly indicates that The Outer Worlds has really bad code design?

Reply on news.ycombinator.com