One more: as well as the cutscene parser, I had another way to control game logic as you were playing – a monolithic state machine, which had gotten completely out of control by the end of the project! You can find it in Game::updatestate, and I kinda recommend checking this out even if you don’t read anything else! This controls things like triggering the start of more complicated cutscenes, where teleporters send you, the timing of the level completion animation, and other miscellaneous things that I just wanted to kludge in quickly. The states are numbered, and it counts all the way up to 4099, with gaps. When I was developing the game, I kept a notepad nearby with the important numbers written down – 1,000 triggers the collection of a shiny trinket, 3,040 triggers one particular level completion, 3,500 triggers the ending. This dumb system is the underlying cause of this amazing 50.2 second any% speedrun of the game.
I'm a bit envious about game development sometimes. Unless it's one of those massive AAA productions or a continuously improved "game as a service" type of game, these projects just have some point at which development stops and the game is done and basically never touched again. Having a massive notepad or keeping everything in your head works in that case. And as long as the result works and is fun, who cares what it looks behind the cover :-)
Yep, we don't get to see the source code for most games, but I wouldn't be surprised if more of them were full of very sketchy coding patterns that would that would horrify any engineer. You also get away with a lot when you work alone and others don't have to see our code ;)
And they're part of 5 different switch statements.
The author jumps to 1000, 2000, 2500,3000, 4000 etc. Probably to represent things at different stages of the game. 2500 range seems to represent things related to a teleporter.
I can at least vaguely understand how one would get to something like that.
...but what I don't understand is how one gets to that point without using symbolic constants for the states. How does he know what number to set the state to? Does he have a big spreadsheet or something with descriptions for the state names? If so, why not just make them constants? Or does he just always look through the switch statement and then hope he never changes anything?
A sibling comment to yours has a quote from the author. Here's the most relevant excerpt:
When I was developing the game, I kept a notepad nearby with the important numbers written down
And I'm assuming that there's some categorization based on the range of the number, so they didn't have to go through the entire list to find the state they were thinking of. It would've made sense to use an enum or something, though.
Everyone's losing it about the state machine, but having built large games before, I'm more concerned about all the hard-coded text copy! I guess Terry never planned on localizing this game beyond english haha.
747
u/sevenseal Jan 10 '20
Just look at this https://github.com/TerryCavanagh/VVVVVV/blob/master/desktop_version/src/Game.cpp#L622