#Vvvvvv not as i do code#
You have write more code and do more complex things to get the same level of flexibility, and it'll be harder to debug since the call stack will have to jump around throughout the layers of abstraction. It creates limits to scope and requires more explicit names for things. When someone is trained in OOP, the requirement "flexible behavior" triggers a search for answers through polymorphism, but polymorphism is much more structured than a copy-paste-modify code path. Where this style applies the most is with hardcoded assets: initializations and runtime behaviors that require an unknown degree of flexibility. They are just optimizing for different scenarios. That does not mean video game devs are bad coders. You can't get away with the same type of spaghetti in your ACL checking that you can in the code that handles player physics in a platformer. Bad code is 100% counter to security - it's those edge cases where assumptions fail and you lose big time.Īs a counterpoint for example, code running on servers should totally be built for the long haul: it's gotta evolve continuously with requirements, it has to cope with edge conditions and especially it has to be secure. Additionally, games do not have to deal with security issues as much most code is running on trusted data sans networking features. It does not make sense to pour so much time into making code reusable and clean if it is not going to be built on continuously for long periods of time. If it's really successful it may get additional ports or content expansions. The key insight is that most games are released largely once, and then only minor work is done after that. In my experience, this will reduce the amount of insanity in the project towards the second half of the development cycle.īut I am always more impressed by ugly code behind a good game than I am by clean code behind an unreleased, unfinished, or unfun game. It’s not really different in style from the Celeste Player code.īut if you’re writing a game of this size or complexity, I recommend doing some refactoring work along the way. THAT SAID, This is not really out of the ordinary for successful, released, real games.
There are a few WTFs in here, like the "int i, j, j " in Script.h.
There are magic numbers ( ) all over the place, plenty of god classes ( ), and in general you will have to do a bit too much archaeology to figure out what a particular class or member function is supposed to do (the function and class names don’t give you enough, and there are no comments to help out). My impressions: The source code is a bit of a tangle here. I will note that this is actually the source code of the C++ rewrite! The original game was written in Flash, and this version was apparently written by Simon Roth. It’s always great to be able to study the source code for successful, released, real games.
0 kommentar(er)
