This week for Video Game Tuesday I’m going to cover a topic I’ve been meaning to cover for a while. It’s all about Enemy Programming!
Enemy Programming?: What I mean is what goes into programming the various enemies you face in a game. For example in a First Person Shooter how to deal with enemies without them becoming too hard for the player to deal with.
Too Hard?: Yes too hard, most enemy programming nowadays at least when it comes to their behavior coding needs to be tuned lower so players can actually win against them in most AAA games. This has been the case for over a decade and this was one of my first lessons in Game Design and Programming. You had to plan out where and how enemies would act, where they would generate (spawn) and how they would approach the player. In most games this means giving them a specific path or paths you intend for them to deal with so they don’t just pop up from behind the player and waste them.
Pop up behind?: Yes, the enemies would actually flank the player and or leave a building and re-enter it to hit the player from behind. Think of it like this, when you command a large squad of Zerglings to attack a Terran Bunker and you don’t actually tell them to go surround it, no you just point them at their target and they do their thing, automatically swarming and circling the structure. This applies to pretty much most enemies in games. But say if that Bunker only had so much space to attack on certain side because it’s at the top of a ramp, but that same plateau it’s placed on has another entrance you’ve scouted out that would let your Zerglings attack it’s other sides. Well those extra Zerglings would move around to attack the other sides by going up that other ramp. In a First Person Shooter that would cause most players lots of issues, thinking that they only need to watch a certain angle and deal with it from there. That’s what I’m getting at when it comes to Enemy Programming.
What else?: Well this is where stuff gets fun or hilarious. Issues like this are what cause some really fun strategies to occur, like the infamous Atheon cheese of Destiny fame where you just used grenades to push him off the edge and instantly killed him and completely ignored the encounter’s mechanics. The programming was so constrained in certain ways to allow the players to actually beat the fight, but didn’t have certain other coding to prevent the Atheon from falling off the platform thereby completely preventing the fight from becoming trivial. Most developers have to take these sorts of scenarios into account for every encounter a game has in it. Most do a pretty spectacular job, although some like Bungie have failed spectacularly at times.
That’s it for this week’s Video Game Tuesday, see you next time.
This week for Bookish Wednesday I’m covering the first entry in a series I started a few weeks ago. It’s Off to Be the Wizard, Book 01 of the Magic 2.0 series, by Scott Meyer!
Plot Synopsis: Martin Banks is just a normal guy who has made an abnormal discovery: he can manipulate reality, thanks to reality being nothing more than a computer program. With every use of this ability, though, Martin finds his little “tweaks” have not escaped notice. Rather than face prosecution, he decides instead to travel back in time to the Middle Ages and pose as a wizard. What could possibly go wrong?
Plot: This is more of a comedy than any serious novel. It makes fun of pretty much everything nerdy, and while it did make me laugh there were a bit too many cringe inducing moments for me to call it a quality novel. That or I found Martin to be a bit too stupid.
Characters: The cast for the most part is actually fairly good, but I just can’t stand Martin. Martin is a bit too stupid for me to really enjoy this book. However my favorite character is probably Gwen, because she doesn’t take Martin’s bull at all seriously.
Overall: This might be a fun read for most people, but personally I found the comedic parts grating more than amusing.
For those who like: Comedy, Fantasy, Sci-Fi, Amusing Cast of Characters.
Not for those who don’t like: Any of the above, or a really stupid lead character.
This week on Video Game Tuesday I’m still straying off my usual path to talk about what goes into making a video game.
Game Designers: They are the people who come up with the idea of making a game, they decide what the team is going to work towards. A Designer doesn’t code or make the artwork, but knowing the basics of each is very useful.
Concept Artists: They turn the ideas of the designer into pictures that will inspire the rest of the art team to make what the end user will experience.
Modeler: They turn the concept art into 3D models that go into the game. They do not make them move, that’s another persons job.
Animator: They are the people who make the models move, they are responsible for bringing the artwork to life through motion.
Skinner/Texture Mapping/Visual Effects: They make the models come to life through colors and other techniques. Sometimes a modeler does this in addition to their own job, but it is often a separate job.
Programmers: They make the game work, these are the real hard workers of the team and everything will fall apart if they make a mistake.
QA: These are the game testers, they often repeat a level or section of the game over and over again trying to break it, and find any bugs in the code that the Programmers might make. Also they make sure that the actual gameplay is fun and balanced. It’s not fun and games to be a QA person and it’s often filled with long hours of doing the same things over and over again in an attempt to figure out exactly how something might be broken.
That’s it for this week’s Video Game Tuesday, sorry for the short post today I’m still getting over this blasted cold.