Collision Resolution with “Pseudo” Normals

In working on my 2D side-scroller game, one big part of work came from collision handling. I felt a tile-based approach was inefficient and archaic (and rather unsuitable in any case), so I went with a polygon collision system using the Separating Axis Theorem. You can find specific details of the implementation/idea here at metanet software.

In short, you project each vertex of two polygonal shapes onto each perpendicular axis of one shape, then you test for overlap. If the shapes do not overlap on ALL axes, then the shapes cannot be intersecting (and thus are not colliding).

This implementation is pretty straightforward, and is explained in a lot of places on the net. What does not seem to be explained, however, is how to resolve the collision after one has been found. While this varies from situation to situation, my focus was on player-to-world collision, which meant leaving the world still and moving the player out of the world’s geometry whenever a collision was made.

This is actually simple enough to do if you are already using SAT; just store the overlap value and which axis it occurred on, and correct by the smallest amount of overlap so that you will be pushed correctly out of the object.

However, in my game problems began to arise when I started introducing slopes into the mix. Originally, I was calculating the displacement of the polygons in a manner like this (excuse the pseudo-code):

disp = dotProduct(mtv.axis, dir);
if(disp < 0)
	mtv.axis = -mtv.axis;

this would tell us if the correction (or ‘push’) vector and the world polygon were in the same direction. We don’t want that; it would push our player further into the world geometry, instead of away from it (and ultimately, with enough corrections, could push us through the other side, or get stuck in an infinite loop in some cases). If the displacement is less than 0, we flip the correction axis to fix this.

But the problem is, with slopes, the displacement varies. For example, look at this mockup shot below (hastily done of course):

As you can see, on the slope, the displacements are all over the map! At the bottom of the slope, he’s to the right and below, at the middle he’s above and to the right, and near the top, he’s to the left and above! This causes the displacement to flip the correction vector incorrectly in about half the positions on the slope, not to mention it totally screws up with ceiling slopes; the player’s push direction is completely wrong if we cannot tell that the player is coming at the slope from below! Compare this to the two players on the left near the rectangular object; the displacement is always correct because there can only be a single general direction for the player to be relative to the polygon.

How do we solve this?

The answer is with a sort of trick, something that actual physics engines would implement on a full scale, and that is to calculate a sort of normal direction (a unit vector with a length of 1, indicating as such a direction) for the polygon surface. Now obviously it’s not a true normal; we are not calculating in 3D and therefore are not making use of tangent space (although maybe my terminology is wrong, so forgive me).

The way I implemented it was to calculate the midpoint of the polygon edge, and subtract the pre-calculated centroid of the polygon shape from that midpoint location. Luckily, I managed to make this quite efficient by modifying SFML and having it calculate the centroid for me whenever the polygon received an “update” (I can post the code if needed). The code for this whole fix looks like this:

	// Get normal direction
	mp = Midpoint(getPoint(shape_1, i), getPoint(shape_1, next_i));
	sf::Vector2f normal = mp - center1;
	normal = unitVector(normal); // normalize
	// perpendicular axis is not the same for the slope
	// we must change it
	mtv.slopeAxis = unitVector(side);
	mtv.slopeamt = std::abs(mtv.slopeAxis.y / mtv.slopeAxis.x);	// rise / run = slope
	mtv.axis = normal;
	// Don't change x movement if a floor slope
	// only push the player on both axes if
	// the slope is on the ceiling
	if(normal.y < 0)
		mtv.axis.x = 0;

And that’s it! Using a sort of “fake” normal (while very approximate, good enough), we can tell which side and where the player is relative to the polygon, and this gives us enough information to know if we should flip the correction vector or not!

Site Cleanup

Yep, I’m still here. More than 2 years since my last post…yikes!

I’ve gone through and cleaned up all the spam users and such, and upgraded all the site’s backend software. More posts will come sometime soon as I do have plenty of things to talk about.

EDIT: And I have now also enabled CAPTCHA for registration. Should put an end to all those spam accounts coming up. :)

WhoDunIt Mod for Zandronum Wins A Cacoward!

The news is a bit late. I’ve been really busy and haven’t had much time to write any more articles for this blog. But now that there is a slight lull, there will be a few new articles posted up within the coming days.

To start things off, the WhoDunIt Mod for Zandronum, a Doom source port I may have mentioned previously, won a Cacoward over at Doomworld is frequently sited as one of the biggest networks for Doom news, and includes a mirror of the /idgames archive, a massive library of released Doom mods and levels. Each year, on Doom’s birthday (that being December 10th), a panel of folks review nominated mods released within the year and select the 10 best releases for awards, with several miscellaneous awards given out for best multiplayer, etc. Winning a cacoward can be sited as a great achievement worthy of some bragging rights.

The three men gaze at each other in silence. Yellow’s eyes dart back and forth, contemplating whether to fixate on Red or Blue. Once a party of six, only three remain, their dwindling numbers a testament to the raw fear that had been eating away at Yellow since awakening in the dusty old museum: a murderer had been walking among them. Yellow’s trembling hands grip the pistol tightly as he spares a glance at the old mirror in the room, once more spying the desperation in his own eyes. A sudden burst of movement and a thundering crack later, and Red is on the ground before Yellow becomes conscious of his own actions. The murderer now lies dead at his feet. He was sure of it. All evidence had pointed to Red: the suspicious movements, the time he spent wandering alone. It had to have been Red, right? Yellow’s final question was answered swiftly as he felt the icy blade of a knife piercing his back…

That’s not an excerpt from a (rather bad) mystery novel. That’s a description of actual gameplay from WhoDunIt, a brilliant new gameplay mode for Zandronum (formerly Skulltag) centering around deception and paranoia. It’s a simple enough concept: each round, one person is secretly declared the Murderer, and it’s their job to silently kill off the other players while remaining undetected. What really makes the gameplay shine, though, is the chaos that often results from the “innocents”. The beautiful film-noir-esque maps are littered with improvised weapons and the occasional firearm, as a means for innocents to defend themselves… in theory, that is. In practice, a “suspicious” act by an innocent can find him slain at the hands of his fellow non-murderers, a deed which does not go unpunished. Matches often slide in the murderer’s favor in such a manner, with the evildoer himself rarely getting his hands dirty. Now, who’s the real monster?

This sort of tension is unlike anything I’ve ever played. I’ve fond memories of hiding in dark shadows on a server somewhere, huddled behind my knife, silently gazing onward as rampant paranoia claims yet another victim. It’s not often you find a gameplay conversion of this scale turning out so well, even moreso in a multiplayer setting. As such, even in the face of solid CTF sets like Velocity CTF X and 32in14-12, WhoDunIt takes the crown in my eyes.

Of course, that won’t be stopping everyone from playing nothing but dwango5, but if that describes you, you may want to watch your back. There might just be somebody creeping up with a knife…


You can read the full cacowards article here. The awards came late this year due to some circumstances, instead arriving on Christmas. Quite the Christmas present, I’ll say!

Competitve Gaming — A.K.A. The Fewest Random Factors

I once read a post on a particular forum stating that “any game or mod can become competitive, given time.” I then started actually thinking about just WHAT makes a game capable of being competitive, and why eventually, given a non-distinct amount of time, any game could possibly become a candidate for “competitive play”.

What I guess is that with time, people become accustomed to the random factors that may reside in a game, and thus players with the right skill set have adapted enough to the point where the random factors no longer strongly affect a skilled player.

Let’s take an example; id Software’s Doom. Still actively played today (though not in professional, sponsored tournaments), Doom has been ongoing with competitive gameplay for many years. I estimate that around the early turn of the millennium is when the combination of modernized, useable modding tools, source ports, and player base all merged enough to form a competitive field for the game. Take this with a grain of salt, as my knowledge of the full-blown, global, internet-based competitive scene is a bit limited although my strong background with the Doom communities has given some reasonable foresight into this (CSDoom’s source emerged around early 2001, which is the time ZDaemon and SkullTag emerged as the go-to multiplayer source ports).

Doom’s fast-paced action made it a game of accuracy and reflexes…for the most part. Players moved at insane speeds and weapons did a lot of damage most of the time. Capture The Flag (CTF) and Duel modes are the most common competitive modes, and while Duel focused greatly on the combat aspect, CTF focuses on a team aspect. Doom does not have many illogical random factors in it, but there is one that stands out: the RNG used to determine weapon damage.

Doom’s weapon damage formula for guns (any weapon that shoots hitscans and puffs or bulletpuffs) was


This doesn’t have a huge impact on the main weapon most players used–the Super Shotgun–but for some weapons that don’t kill in a single hit in close range, like the Shotgun or the Chaingun at any range, there can be some luck involved in the outcome. While I don’t intend to spark any outcry from any Doom players who read this, it is a matter of truth that there is a tiny bit of luck involved in how much damage the weapon deals. I’ll give it that about 95% of most scenarios will not matter, as generally one guy is skillful enough to make the kill no matter the random factor, but in some instances it can have an effect. From a professional, completely objective standpoint, any sort of complete luck involved with dealing enough damage to kill your opponent generally makes a game unable to be taken seriously at a very highly competitive level.

So what is my point with all of this? Well, what I’m trying to get at is that for most games to be entirely competitive, the best choice of action is to eliminate as many random factors as humanly possible (within the means of game balance, of course). I’m going to list a few pointers I’ve come up with that may keep things in line (along with some balance tips as well).

–Never, ever have random damage
This sort of goes without saying, from my example mentioned above. Skilled players will instinctively know how many hits their opponent can take before dying, and as such, randomness played into that makes it impossible to actually determine that. This means no random damage for EVERYTHING; guns, melee, etc. However, introducing a weapon with randomness as part of it’s play style or as a feature of the particular weapon may prove interesting and can be acceptable, though it will still likely not be allowed in a competitive setting.

–Stick with a general system for your weapons, and make unique ones differ from it
For instance, say you decide to make all your guns deal reduced damage the further away the target is. This basically means that all your weapons require close-quarters fighting to be effective. This makes combat really boring. So, what you can do is introduce a weapon (say, a long-range rifle) that actually deals normal (and by normal, I mean above-average) damage at all ranges, but actually deals LESS damage up close. This changes the player’s play style to that of a long-range role, and mixes up the gameplay considerably.

–Random spread is OKAY for competitive play…within limits
Let’s take the previously mentioned system–all weapons dealing less damage the further away the target is–and also add random spread on top of that. This would make the required close-range combat extremely frustrating! Sometimes you’d land a shot you aimed correctly, sometimes you don’t. It factors in luck and luck is not competitive because it interferes with skill. Removing random spread in this situation is generally a good idea, because then one’s aim at close range actually allows their skill to be fully realized. This is likely the primary reason Team Fortress 2’s competitive play disables random spread, as it uses the exact damage model I have described. ON THE OTHER HAND, if you have a damage model that uses the same damage per hitscan at any range, then random spread is acceptable. This is because then, assuming they had a reasonable amount of thought put into them, the weapons will be designed to have random spread that is equivalent to their assumed effectiveness of range. For instance, a shotgun may have extreme (random) spread, but at really close range, which is where it would do the most damage and thus be the most effective, the random spread is almost a non-factor. However, randomly spreading at longer ranges, thus more likely missing your target and being generally unreliable for damage designates that longer ranges are outside of it’s specialty, and as such random spread can only help balance such a weapon.

–Sniper Rifles should never, ever be used like Shotguns
So you decided to add a semi-automatic sniper rifle that kills in 2 shots to anywhere on the body (or in 1 shot if hit in the head). You figure it needs some balance, so you make it zoom in a lot, giving the player a narrow field of view, and you make it spread immensely when you aren’t zoomed in. You give it a 10 round magazine, because you want the player to have enough shots that spamming it is okay, but generally not encouraged. To top it off, you also give it very high recoil after each shot when zoomed in. Then you play test it with people and find that they are using them like a shotgun; running in close to their target and spamming the bullets off as fast as possible until the guy drops, because your unzoomed random spread isn’t enough or the damage is just too high. What do you do? You can’t give it some kind of fixed spread pattern because people would eventually figure it out, and increasing the spread further doesn’t do much, and may cause for extremely unrealistic shots (bullets don’t come out of the gun at 90-degrees…). Your options appear to come down to this: either reduce the overall damage, reduce the rate of fire, or give all players a means of instantly killing you if you get too close (which is what Call of Duty went with).

The best option is actually D. You create a revised damage model for that particular weapon (and/or any that end up like it), where it actually does less damage up close, but does full damage past a certain distance (a distance that would deemed suitable for a sniper rifle, whether that is medium or long range is up to you). The idea behind this example is to get creative with balancing your weapons so they actually fill a particular role. This will enhance the sense of variety for your weapons, and then players don’t feel as if all your weapons are too similar. It also helps prevent one weapon from feeling like it’s the best weapon above all (unless it is intended, in which case different balancing rules go into that).

–Playtest, Playtest, Playtest!
If my experience in making the WhoDunIt mod has taught me anything, it’s that even the slightest change to a weapon system can break balance completely. The two biggest examples from the mod are the Shovel and Pool Cue. The Shovel, prior to some changes I made (read: actually fixed) to the stun system (in the mod, if you were struck by a melee weapon it would reduce your move speed a bit for a time, the time could be stacked with multiple hits to a certain limit), was perfectly balanced and was the only weapon that hadn’t undergone any changes since it was introduced in an ancient, very old beta release. However, after fixing the system to work as intended, it proved to be WAY too powerful, able to not only stun lock the murderer or other innocents, but also dish out 40 damage a swing against the murderer! People quickly exploited this and the shovel became one of the strongest weapons in the game, when my intention was to balance them all as best as possible.

The other example is the Pool Cue. This weapon, from the start, was meant to be a supportive stun-based weapon, possessing the highest stun per hit in the mod, but with low damage output. Back before I fixed the stun system, it was the worst weapon in the game. After I fixed it and gave it some buffs (not realizing just how well I had ended up fixing the stun), such as slightly more damage, increased attack speed, and longer reach, it ended up being the best weapon in the entire mod, sometimes even outdoing the guns! Even sub-par players could solo the murderer in a 1v1 fight, despite the fact the murderer should win almost all 1v1 fights as long as A) He has decent aim with the knife, and B) the innocent has a melee weapon. The murderer’s knife does a maximum of 40 damage in a hit, attacks relatively fast, has decent reach, can backstab for instant kills, and it increases the murderer’s run speed while drawn. The only thing it doesn’t have is any form of stun capability, which is purely for balance reasons (along with making noise while drawn and being visually obvious, clearly indicating the guy wielding it is the murderer). However, the pool cue, doing a maximum of roughly 30 damage a hit, having the longest reach of any melee weapon in the game, and attacking about as fast as the lead pipe (the fastest melee weapon in the mod), on top of inflicting up to 5 seconds of stun time (which, in the code, was a 30% reduction in move speed; significant enough to prevent people from fleeing) made it entirely overpowered. And in reality, with the previously broken stun system that didn’t work correctly, all other changes would have been perfectly fine. But because I had fixed a feature that actually allowed it to work properly, it became a monster.

The point is: Playtest everything, because even the slightest change or fix to something could potentially cause a complete imbalance unintentionally. If I had managed to playtest the mod a lot more before releasing it, this situation may not have happened.


And there you have it, a few tips or ideas about balancing a game and potentially making it competitive. There is certainly a lot more that could be discussed here, but I’ll leave it at this for now since I don’t intend for this to be an end-all guide to designing a competitive game. :X

Parser Pandemonium

Sometimes it is taken for granted that we have high-level programming languages, and all our fancy, thousand-line catastrophes are happily fed through a compiler that reads and interprets the information, then spits out byte code that only a computer could understand as its final form. The thing is, by understanding how to do such a thing yourself (at least, in a sense of it), you become a better and more knowledgeable programmer. Understanding how to make your own compiler and/or interpreter in the programming language of your choice is also critical for a game developer. An interpreter allows the creation of external resources without having to outsource the tools or use existing stuff. While it’s always a good idea to use the things others have made (for example, libraries; why write your own when someone has already done it, and possibly better?), making your own interpreter gives you insight into how one works, and besides, without your own interpreter it may be difficult to adjust it to read the input that you are designing!

So, let’s get to the meat of it all: how to write it. Well, I’ll be using the STL library in my examples but feel free to use your own implementations (as long as they support the operations I’m going to demonstrate). Note that these are simply examples/samples to look at and learn and understand how a parser works and the fundamentals of it all. This is likely by no means a copy-paste tutorial that’ll work out of the box (especially since some of these examples will be coming from my own personal work)

So say you have something like this for input:

value = 22

Essentially, what you are trying to do is get the programming equivalent:

int myvar = value  // value would be 22

The first thing you have to do, of course, is actually obtain your input. You can use input streams or your own file reading methods if you so choose, but I prefer the good ol’ C library FILE typedef and it’s associated methods. In some basic code:

std::string mystoragestring;
FILE *mytextfile;
mytextfile = fopen("mytext.txt");
	mystoragestring += mytextfile.Read();

Ok, so now you have mystoragestring, which contains the contents of your input. What next? Simple, you read each character of the storage string, character by character, and assemble “tokens” from those. Each completed token should represent a word, a special character (such as =, +, etc.), or a self-contained string (“like this one”). Essentially, you do this:

class Parser // Design a class to encapsulate all your parsing actions
	char *cursor;			// Position of the 'cursor' in a string (essentially
					// the array index of a C-string)
	std::string mystoragestring;	// This is really where mystoragestring should go
	int storagelen;			// When parsing in your storage string, record the length
					// here and check against it to prevent any buffer
					// overruns or errors in general (and so you know you're
					// at the end of the stored contents)
	char *ctoken;			// A C-style token holder for compatibility with C
					// conversion methods
	std::string GetToken();		// This reads in a "token"
	std::string PeekToken();	// I won't define this one in the example here, but this
					// basically does a GetToken() but doesn't modify the
					// cursor position, essentially allowing you to preview
					// the upcoming token
	int GetInt();			// This returns the integer equivalent of a
					// token's contents
std::string Parser::GetToken()
	std::string ret_token = ""; // The token we'll return when finished
	// Check for a white space to stop reading at, OR stop reading if we are at
	// the end of file
	while(PeekToken() != IsWhiteSpace() && cursor < storagelen)
		ret_token += mystoragestring[current];
	return ret_token;
int Parser::GetInt()
	// Get token
	std::string token = GetToken();
	// Allocate the C-style token's size just large enough to fit the token
	ctoken = new char[token.size()];
	// Dump the token we received into a C-style token
	strcpy(ctoken, token.c_str());
	// Return integer value
	return atoi(ctoken);

So, with this in mind, what happens next? Well, you use the parser to read in the original example, and if you were to implement some debug logging or use something like the MSVC debugger and slowly step through the program, what you’d do is check until the token reads a specific keyword, and then make sure the next token is an “=” sign, and then set your variable to the next token read. You can obviously implement your own type-safe checking with this if you please.

Remember that this sample is extremely bare bones. It’s best to make your parser able to interpret many different kinds of data types, allow dynamic navigation of tokens and the storage space, and many other robust features that can be implemented. But this example should give those new to writing such a piece of a program a general idea of what they need to do for it to start working.

Hope you enjoyed this little article, feel free to comment on it if you have something to mention!

GUI Libraries Are Like Art

….Everyone has a differing opinion on them, and often only the most complicated become popular. (Take that opinion with a grain of salt if you will; I sure didn’t think of that comparison very long)

Anyway, so my Dad asked me to make for him a cross-platform GUI-based application that can generate password strings randomly with various customization options and capabilities. I was to use C/C++, and I knew exactly what I wanted to do and how to do it, the only thing I needed to take my time on was the actual GUI. It turns out, this will likely be a bigger task than making the actual program. I thought I had some reasonable experience with wxWidgets. Afterall, I had started working with it for a project of mine and it was going rather smoothly. But then, as I found, doing some of the more advanced stuff is…not on the easy side. The steps involved to getting what I want were proving to be quite long and tedious, and on top of that it would eventually turn your code into a massive, ugly, hard to read mess.

So, I set out to look for some other GUI libraries. Below, I’ll talk about the 3 most popular I’ve found; wxWidgets (as already mentioned), MFC, and Qt.

MFC (Microsoft® Foundation Class)

Every built-in Windows application uses MFC (who’d a thunk it?). Applications designed specifically for Windows will often use MFC (if not C# and the .NET platform, but that’s a different story altogether). This all being said, MFC is not cross platform, making it not suit my requirements right off the bat. However, looking into it, MFC is similar to wxWidgets, and suffers the same convoluted, painful programming design scheme imaginable. I’ll go into more detail on this when I talk of wxWidgets next. Also, another fun fact is that actually, wxWidgets is based off MFC since it came first. Just figure I’d clarify that. 😛


Ah, wxWidgets. Such a neat idea but so, so poorly executed. The one big upside to wxWidgets (or wx as I’ll call it from here on in this blog post) is that it is cross-platform, and has many additional tools to handle things like low-level file input/output, setting up rendering contexts, and even handling tasks like printing to a printer. Neat stuff, but it’s horrendous coding ethic is not so good. Take for instance this idea: To have any component in your application (a button or toolbar, as examples), you must instantiate an instance of the particular wx type for that component, then specify it’s properties through its members. Example:

class Button : public wxButton
	virtual void OnClick();
// Then, in your main program, you'd call something like Button MyButton(size, ID, etc.);

This is fine and all, but in practice is becomes quite a mess. The fact that almost NONE of the other functions refer to each other through pointers or other forms of memory access, and instead rely on an unsigned int “ID” system (which ultimately forces you to write GIANT enum blocks to provide any form of sanity to it), and you have yourself a lot of illegible code and extra typing for very little result. MFC pulls this same garbage, but fortunately MFC will automatically use the ANSI or Unicode versions of their functions if you use a single, simple define (unlike wx which requires you to prefix EVERY. SINGLE. STRING. with a special conversion Macro–which is “_T(<String>)”). Coupled with pretty poor documentation and confusing layouts, and you have wx: a big pain in the behind.


Qt was a relatively new discovery for me. I found this gem while googling around for some information on other GUI libraries. Qt is nice, but has some drawbacks that make me…not want to use it. It is fully Unicode compliant, it is pretty easy to work with, it has a form designer (think the MFC/Visual Basic form designer), it’s fast, and uses a unique idea for running a GUI via a “slot/responder” system (the exact details are a bit sketchy; I’ve only read some basic information about it but it seems pretty effective at preventing errors and remaining typesafe at the least). So what is the catch? Well, for one, the form designer is limited to only the most basic applications (which is somewhat expected, but I think MFC’s designer could at least do some relatively large-scale applications). Qt’s designer also has a different learning curve compared to other form designers (though not nearly as bad the wx form designer…don’t even bother with it). But the biggest thing that turned me away was that the Qt GUI code is spit out in it’s own language! Not straight C++ or anything, but in it’s own proprietary language. Ultimately, the compiler converts the input code into a C++ form, which if what I remember what I read correctly, can be spit into source files for someone to edit, but the thing is that you have to take an extra step just to do so! So essentially you have to design your application entirely in Qt first (either by hand typing the code or by using the form designer), compile it, and then and only then can you make any “tweaks” to it from the Cpp sources. This is unfortunate, because it sounds awesome, but that extra bit of steps just ruins it for me at least.

In Conclusion

So far it seems that there aren’t any feasible, simple GUI libraries that don’t require extra work or overhead to create an application. SO WHAT IS THE SOLUTION TO THAT? You either write your own (good luck with that), OR write a wrapper for an existing one so that it’s NOT as painful to work with. Hence, I’ll likely be writing my own wrapper for wx, since it’s cross-platform and works in native C++, two points it has over MFC and Qt, respectively. I’ll have to figure some way around that God-awful Unicode macro, but I’m sure a solution will be available.

Code Does Not Control Everything….Mostly.

There was a discussion on /r/battlefield3 some time ago when the latest tentative changelog was announced. The talk was related to 3rd person player animations and how they sync up with what is happening in first person.

In short, the focus was on the reload animations; anyone who has played Battlefield 3 can tell you that the reload animations in first person don’t match up well with the 3rd person animation, often leading to silly situations where a player is firing their gun while reloading it at the same time.

During this discussion several comments and suggestions had been made to remedy it, including using the short reload animation at all times, instead of the current long one. However, the DICE developer, user name “Demize99″, gave the ultimatum that it’s too late to go back. Even novice game developers would understand why. But, the flood of misinformed comments flooded in anyway…

“it can’t be done” = don’t have the time/allocated resources to re write the code.

The thing is, programming and code have very little to do with an actual animation done by a mesh of shapes, polygons, and skeletal bones. At best, programming can control the speed and timing of an animation. It can control how and which bones react, but they can only perform the actions they’ve been assigned.

So in the instance of the reload animation talk, the best the DICE developers could do is speed up the animation or cut it off midway through. Both solutions would look wrong, and the proper thing to do is redesign the whole animation.But that is a time-consuming process. Rewriting some stuff in code is not. If they had the option to do it, they probably would have, but it isn’t as simple as changing some values, it’s actual reworking of a model and animations. On top of that, each reload animation for every single weapon would have to be redone. Hopefully you can see how this would eat up a lot of time very quickly at this point….

BUT, on the contrary…

Valve software has put out some impressive technology in their Source engine. One of the most profound parts are the animation systems. There is a particular tool in the Source SDK, a set of programs available through Steam which allows for Source game/engine modding, which allows you to animate an NPC’s mouth, facial expressions, and eye movements all through recording a voice clip. Somehow, the software recognizes speech and replicates the mouth movements onto an NPC. Granted, it’s not always 100% accurate and often requires a bit of custom tweaking every few frames, but it does a great job of a baseline at the least.

How did they pull this one off? Doesn’t this contradict what I mentioned?

Well, indeed. It’s impressive stuff for sure. My best guess is that they have pre-computed facial positions for various sounds made by the human mouth when talking, and then chains them together in a smooth animation by interpreting the audio data. This is in simplest terms, of course, nor do I even know if this is how it really works but it’s the best guess I can make. Just looking through the source files supports this a bit, as ALL talking NPCs have to include some basic skeletons when the model is compiled.

Also, have more content to come in the following days. Stay tuned!

For Lack of Better Research

Alright, now that the site seems to be fully up and running, I’d like to quickly talk about something before I go to sleep, and that is: Users giving feedback with a suggested fix that is often complete nonsense if not entirely ignorant.

It’s very common to see in a video game community comments such as:

“It’s an easy fix.”


“Just do x and y and it’ll be fixed easy!”

These comments are fine and all. People are just trying to provide ideas or solutions. But the biggest thing that irks me about such suggestions is the sheer lack of actual knowledge behind most of them. If the solution were as simple as had been mentioned, it would have already been done. Often times, people bring up an idea but have zero background on the subject, and thus what they are stating becomes nothing more than nonsense.

For example, DICE’s latest Battlefield iteration, Battlefield 3, has many ways for its users to express their concerns over any bugs, gameplay issues, etc. via the forums (such as on battlelog, the DICE site, and the EA site), the feedback site, reddit, twitter, and more.

I have personally seen posts with statements such as this:

“They could pay five people to play this game and find all the glitches and it would be done in a day. “

This is not how it works, folks!

An old programming saying goes, “Fix one bug, create two more.” It’s just about impossible for large-scale programs to be entirely bug free, and when you fix existing bugs you potentially end up creating more with your fix. It seems like a vicious circle, but the point is to get the program to a stable enough point that additional bug fixes are not needed.

I also find this a bit upsetting when people make posts like that, because then it spreads like a virus; uniformed people believe what they read and then think that it’s truth, which in turn causes more people to get on the developer’s case, stating a proposed solution that actually has no background whatsoever.

Whenever I see something like this, I’ll often try to intervene and make a statement or response with a general idea of what may be happening. The goal of the posts isn’t to appear knowledgeable or prove anyone wrong, but to simply provide a correct perspective and shed some light on what they generally do not know much about.

This being my first blog post, I think you can expect to see more from me related to explaining some programming or game development-related stuff with a bit of depth. Perhaps a reader can learn something from it, and who knows, I might wind up linking an article for people to see in some posts some time in the near future.