Often, in covering the specifics of examples, the general issues and strategies get overlooked.
In this post, we’ll focus instead on general issues and strategies.
A scattershot approach is taken to cover a lot of information here – by all means, skim and skip for what’s relevant to the sort of challenges that you’re running into or thinking about. Very few of these sections are order dependent or cumulative. Broadly, I have grouped the points under Design, Programming, and (a fairly cursory mention of) Math for videogame creation.
This is an Art – It’s Inexact
Videogame design is more like writing a song than solving a math problem. There’s not really a right and wrong to it. Personal preference also goes a long way here – just as the best techno song in the world still won’t please people that don’t like techno, a great strategy game may seem boring and obtuse to people that don’t like strategy games. That sort of differences in preferences is not only OK, it’s unavoidable.
That said, everyday experience makes it pretty clear that everything is not equally good. Out of the seemingly infinite combinations of noises that could be created as “music”, a comparatively narrow sliver of those possibilities can be reasonably defended or commonly recognized as a competent work of music – we expect patterns, we expect beat, we expect harmony, we expect emotion, and so on. In the same way, there are expectations that videogame players, inexperienced and experts alike, bring to their playing, and good design often involves being aware of those expectations, and only violating them if there is a rare and compelling reason to do so.
Design the Videogame
The end product is an experience for the player.
Not a design document to publish.
Not source code to hang on the wall.
Not a list of rules to be discussed.
Not a spreadsheet with elegant balance calculations (Side note: I’m skeptical that these have much value in any case! Animation times, psychological effects, holistic strategies, etc. make the raw numbers a poor reflection of what most people will actually do.)
If what you’re doing isn’t contributing to improving the user experience of the final result, second guess the value of it.
Don’t confuse the dance steps for the dance.
80/20 Rule – “Bang for Your Buck”
To reiterate the classic 80/20 rule of thumb about design: 80% of the user’s enjoyment comes from 20% of the work that you produce. How the player controls, especially for a real-time game, is often within that 20% – if it’s done poorly, nothing else about the game is going to save it (see: Lair for PS3).
Even though it’s impossible to tell exactly what falls within that figurative 20% the player is most concerned with, strive to get that fraction the best it can be; whatever falls in that figurative 80% should generally be just good enough to not distract from the 20%, otherwise it’s sucking time and energy away from focusing on that core. Every paragraph in a novel doesn’t need to be tied for being the greatest paragraph ever written for the book to come out well; at the same time, any book, however clever, filled with typos and distracting grammatical errors, won’t be given a fair chance.
“Bang for Your Buck” trade-offs are a useful way of thinking about videogame design. Even if you’re not on a financial budget (as opposed to the time budget that we all have to deal with), even if you’re working alone and not on someone else’s time, there are always opportunity costs when spending time on one part necessarily pulls that attention away from other parts.
Don’t let pixels in far away background details, or trying to get a random scene midway through the game perfect, get in the way of getting right the player movement, camera feel, consistent visual language, and first impressions.
If It Doesn’t Add Something, It’s Taking Away
Having more features is not better. It’s different. In particular, to the extent that adding more no longer works well together, it becomes less focused, and feels like a less well designed experience.
I don’t always edit my online writing as well as I’d perhaps like to – but at least in this case, headers make it easy to skim or skip any parts that someone finds uninteresting or irrelevant. In a videogame that luxury often isn’t there, since players are usually forced to take on a particular encounter, solve a particular puzzle, or otherwise grind through each planned experience before advancing.
One of the major differences between Google and Yahoo, since the beginning, has been that Google presents just a search page with a search bar, whereas Yahoo has always thrown 10 million irrelevant things (weather, news, entertainment, horoscopes, personal information, travel…) in front of the user. Yahoo is less of a disaster than it used to be – it used to look the way that (at the time of this writing) excite.com still does – but needless to say, the cleaner experience is widely preferred.
Show some restraint.
Also, don’t be afraid to edit out of a project something that is already there, just as you would with a written paper, if it improves the overall effect. Cut things that are confusing, that weren’t taking shape well, that feel unfair even after several rework attempts, or that perhaps made sense in the original design but no longer jibe with what the game has evolved into during development. Shorter and more coherent is better than a mess that’s a little longer.
The worst part of a game is frequently the memory that prevents someone from recommending to their friends what was an otherwise excellent experience.
Consistent Visual Language: Environments
If the player is able to climb a tree, the player ought to be able to climb every tree. Moreover, the first time that non-obvious (it’s not a common convention, such as dying when falling off the screen) control mechanism is relevant in gameplay, the user’s experience should guide the player toward discovering this insight, either through:
- Appeals to real-world visual parallels, for example by arranging branches in a way that resembles a semi-regular ladder rungs.
- Affordance hints, such as alternating nobs on the tree, spaced within arm’s length of one another.
- Curiosity lures, such as placing a desirable power-up at the top of the climbable portion, visible from the ground, which suggests to the player that there must be a way to reach it.
- Visual clues of being in the player’s plane of action, such as by being at natural saturation in an environment where most trees are darkened out in the background.
- Demonstration through non-player/enemy utilization, e.g. having enemies climb up or down the tree to reach the player, demonstrating their climbability.
Players become confused, stuck, or frustrated when they are expected to read the designer’s mind, to somehow know that this tree, or perhaps this door, can be interacted with, unlike all that were discovered before or after it.
Consistency of visual language extends into all corners of the imagery in a game – something that harms the player should suggest it will cause harm (via spikes, boiling lava, angry expression), a platform the player can stand on should have visual similarities to others that the player can stand on, and so on.
Consistent Visual Language: Entities
A similar consistency of expectation is formed by players in regard to enemies and items. If the player has encountered a number of witches before, one witch should not suddenly appear which takes or causes twice as much damage as those that came before. There are, alas, at least three exceptions that commonly come up where violating that sort of convention is acceptable:
- There is an obvious visual difference in the new, more powerful witch (tinted red, or substantially larger). This is not really an exception of the convention so much as a time-effective workaround.
- If the first time the character appears it is presented as a boss encounter (given its own health at the top of the screen, supported by minions, required to be defeated for the player to complete an area), then on future encounters as a recurring enemy its strength as a non-boss may be toned down considerably.
- Minor variations, such as sometimes requiring an extra hit or two to defeat, are accepted in less iconic, more literal representations of human (soldier, criminal…) or monster (esp. zombie) targets. Requiring an inconsistent number of hits to bring down adds unpredictability, luck, and realism to otherwise mechanically consistent encounters. Note that in this case, any given opponent should have a random opportunity to be the one slightly stronger; planted deliberately, this defeats the purpose.
Halving/Doubling To Tune Numbers
How fast should the player move in the air, in relation to how quickly enemy shots move? How rapidly does the next puzzle piece fall? There are at least dozens, and usually hundreds or even thousands of little numbers that can be tuned in a finished videogame. Where do those numbers come from?
Tuning generally comes down to whatever “feels right”. Isolate the most important number first – say, player jump height and move speed – then count on that as a pivot while tuning other values.
Values that “feel right” are often found by halving and doubling/splitting – programmers will recognize this idea as “binary search”, but the gist of it is that throughout the code, you’ll find many numbers for speeds, sizes, etc.
If something seems too fast, cut its speed in half. If something seemed too small, double its size. If one of those values was too far in the opposite direction, split down the middle on the next iteration, and so on, until it no longer seems to warrant finer changes.
By making dramatic changes in values, this also helps quickly ascertain whether the number in question is the right one to be futzing with. Changing the player’s lateral air control speed in tiny increments may take many iterations to reveal that no value seems right at the current jump height – a discover which is made much faster if the air control speed is tested in a broader search pattern.
For particularly messy tuning challenges, it can be helpful to set up a debug mode in the game, displaying the current value on screen, and supporting a few keyboard shortcuts that adjust the number either direction (higher, lower, reset to default). In this way, a better value can be found through experimentation with less compilation delay.
Tune in Order
Once a good jump height and speed has been determined, levels can be designed based on that jump ability. At that point, either the jump values should remain untouched thereafter, or it should be considered that messing with them may invalidate previously completed levels.
(This pattern of decision making in order relates to a wide variety of games, not just platformers. For more on this concept, see Resourcefulness vs Resources.)
Make Something You Want to Play
Unless you’d like to form focus groups and wait for their feedback between every major change in the game’s design, and unless you’re highly certain that you have a good way to both know that the project is meeting a certain player’s wants and will reach them, make something that you enjoy. That way you have at least one happy player, there’s no waiting for feedback before changing or trying on new ideas (part of what’s great about working alone or on small, hobbyist teams!), and it’s easier to work on something when the main drive is that you’re eager for it to be done so that you can have it.
Working on something that you’re genuinely excited to play also increases the incentive to finish it, and finish it well. If you were just a fan of the game you’re making, you’d wish there was something you could do to get it done sooner and better; if you’re a fan and the developer, that’s on you. It’s also a good way to play to your strengths, putting your best effort in, which ultimately results in better portfolio work (if relevant).
Give Areas Themes and Purpose
A map designed as a series of obstacles with a sky or brick background only goes so far. It may get all the gameplay right, but if it’s not giving the imagination something to chomp on, you may as well be making a film without audio. An important part is missing.
Is this level in a reactor? Is this area based on a kitchen? Or perhaps this is the place where the enemy has recreation between training? These can inspire the creation of an additional decoration or two, which can go a long way in setting the mood. They may also inspire substantial differences in layout and enemy/item placement, as opposed to thinking of it as “another level”.
Just like there are visual themes, the gameplay should also be broken into differentiated phases, when possible. Perhaps this part focuses on jump platforming, perhaps that part focuses on lock/key or torch/switch puzzles, perhaps this other area is pure combat. It’s entirely unnecessary (and often unwise) to cram every type of gameplay imaginable into every game, but what range is possible and worthwhile within the engine created should be explored in focused turns, rather than spread evenly into a murky gray from start to finish.
Don’t Put Everything In Level One
I used to do this, especially in my early modding work. I wanted to show off every enemy, every weapon, every feature, everything cool about the game at the same time immediately to make what I thought was a first impression. Quite the opposite happens – it reeks of amateur, it’s sloppy, it’s unfocused, and there’s too much going on for a newcomer to make sense of what’s there.
Pick a couple of enemies, a couple of items, a couple of neat features, and rearrange them differently for the first couple of levels. Incrementally build upon those in the phases of the game that follow. Whatever you did for the prototype or the playable proof of concept – if it existed as such – generally needs to be dialed back and split apart into earlier levels to warm people up to that level of mid/late-game intensity.
A story shouldn’t immediately introduce every character and plot point within the first few pages, there should be some space given to letting the reader get to know the characters and circumstances before more are brought in. Your features are your characters; write a well-paced story.
Your Game is Too Hard
I still have problems with this, and I’ve spent half of my life working on it. By the time the game is finished, you’ve played it more than nearly any other player (probably) ever will. You know each aspect for how it evolved over development, you’ve played it 20,000 times with a variety of different tuning and layouts trying to figure out what worked, you know how the AI and weapon collision systems and power-up timers operate, etc. If any level besides the last one or two still challenges you as a player by the time the game is done, it’s probably ridiculously hard for anyone else. Dial it back, then put it in front of someone else to see whether they get annoyed by it.
Systems centered design – the bottom-up thinking that leads to levels designed as grid tile arrangements, enemy/obstacle AI as simple patterns, and non-human/non-character for player control (tank, spaceship, yellow crescent, arrows) used to be common in the 70′s-90′s for the sake of working within technology’s computational limitations.
Even though a modern computer (or console, for that matter) is now powerful enough to deal with arbitrarily complex level structures, adaptive AI, and high polygon finely textured smoothly animated 3D models, making that stuff takes a ton of time and special training, and usually leads to what is only one particular type out of many possible aesthetics.
Making a single room for Doom 3 from scratch may take more hours than designing an entire level in Doom. If you’re not (and don’t have access to the time of) a talented modeler, expert in lighting and audio, etc. your Doom 3 room would look rough no matter how much time is put into it; by comparison, pretty much anyone could throw together a pretty decent (even if not great) Doom level, since it’s a matter of laying down some overhead lines, placing enemies/items/decorations, and picking/aligning simple single-layer textures.
All that, and Doom 3 is a worse videogame than Doom.
There are a lot more ways to shoot yourself in the foot designing or creating content to fill an area in Final Fantasy XIII than in Final Fantasy, Final Fantasy III, or even (relatively speaking) Final Fantasy VII.
All that hard work gets burnt on trying to force what’s ultimately as artificial as a cartoon to look as photorealistic as live film. Would photorealism improve The Simpsons, South Park, or Futurama? Of course not. This leads to the next point, an important design choice:
Literal vs Conceptual
In the semi-legendary Understanding Comics, Scott McCloud points out that the less literal an image looks, the more universal, idea-oriented, and conceptual it is. From that book (which I highly recommend reading, and not just because I’m copying a picture from it):
Graphics used to be simple because that’s all the hardware was capable of doing – a few colors at once, blocky pixels, etc. Even though more complicated things are now computationally possible, however, there are still perfectly legitimate reasons to go for a simple style – and it isn’t just about saving time.
|“Look ma, no arms.” (And the poor fellow on the right doesn’t even have legs.)|
As was covered in the Bottom-Up vs Top-Down Game Design article, the purpose of every picture is not to faithfully reproduce reality. That videogames have gradually been able to come closer to visually, verbally, and viscerally reproducing reality has made that a distinctive advantage in differentiating products within the marketplace. But then came along Wii Sports and its 5 piece, 4-color plastic characters that have one-color spheres for hands. In case you haven’t been watching the score, 3.5 years after its late 2006 release it’s still #5 out of worldwide weekly sales for all videogames.
|(The 4 games above it are less than 1 month old. The 3 games below it are also Wii games with simple graphics. The one immediately after it is its sequel.)|
Wii Sports isn’t trying to accurately depict bowling, baseball, boxing, tennis, or golf, either visually or in mechanics. It’s instead about the simplest ideas underlying bowling, baseball, boxing, tennis, and golf. It has more to do with how we think about those things than it does with how those things really are. That’s more than just fine. People love it.
Simple isn’t worse. Complex isn’t better. Simple is substantially faster to make more levels, characters, animations, and special effects for. Complex requires a large team with a great deal of very specific and specialized talent coordinating efforts. Simple is conceptual. Complex is literal.
Most interesting to me is that conceptual – and thus simple – affords such a vastly larger range of perspectives and ideas to explore and present, compared to the literal – and thus complicated – representation of how things really look, how things really function, and how things really tumble down steep hills. When it comes down to it, there is only one way that everything fundamentally and really is, but there are nearly infinite ways that things are not.
If Braid tried to be photorealistic in 3D, it would have required a substantially larger team to produce, and come out (almost inescapably) far less interesting. Instead, almost all of the enemies are the same, and the level elements are repeated functional and decorative pieces (as with the design of a classical Genesis or SNES platformer). It wasn’t laziness, and it wasn’t lack of ability/resources to realize a full 3D world; it was using systems-centered design to massively simplify/accelerate production while focusing in closely on concepts and ideas.
Have you played Canabalt? Huge breakaway success, using clunky pixel art, low-fidelity music, and a single procedurally generated level.
I’m almost at a loss for how else to put it, but it cannot be emphasized enough: resourceful, conceptual, unrealistic style and clever design, not unlike the sort that 15+ years ago were required for videogames to function at all, can today save a tremendous amount of time and energy… while often producing significantly more successful and meaningful work.
Is the Idea a Videogame Idea?
Frequently, someone comes into videogame development with an idea of a story they would like to tell. Is the particular story not, perhaps, better suited as a cartoon, as a short film, as a play, or even simply written in well-edited prose? Certainly, the audience coming into the story could be forced to unjam a virtual door with bobby pin before getting to the next scene, or required to fend off hordes of zombies (again), although videogame qualities are often adopted at the expense to the story concept as a prominent source of frustration or distraction, rather than as meaningful rhetorical elements.
There are videogames that do story well, in the way that videogames handle story. It’s worth considering, however, that a person wishing to do two things – tell a particular story, and make a videogame – may in some cases be most pleased with the results doing those as two separate things, rather than forcing both together.
If the best way to bring your idea to life is as a videogame – or at least it might be, though you’re not sure – by all means, go ahead. I merely wish to insert an extra step of consideration. If the idea would come through better as an animated short, a written short story, or maybe even a song, it’s 2010: you can learn to make pretty much whatever you set your mind to. If you have a hammer, every problem isn’t necessarily a nail; if you’re specifically interested in using a hammer for its own sake, no matter how many screws need screwing, that still doesn’t make it the right tool for those tasks.
Put the Game in Front of a Friend
Don’t tell them anything in advance about how they’re supposed to play it. Don’t answer questions, unless they really need it to advance, and then make note of it. When other people get to it, you won’t have the privilege of getting them unstuck when they don’t realize that up arrow opens doors.
Whatever you had to tell the stuck friend, add some sort of indicator or message to the game to tell future players on your behalf. It doesn’t interrupt or break the game’s reality to do this – at least, not nearly as badly as being unable to figure out how to open a door or perform some other trivial, required task.
Illusion of Simultaneity
To anyone that has done any real-time game programming, this probably seems like a no brainer. To someone that hasn’t, getting used to this concept is a surprisingly common barrier when getting started.
Everything happens one thing at a time. The code in every function goes from top to bottom, one instruction at a time. Even though it looks like dozens or hundreds of things are happening and moving at once, they’re each getting a turn. They appear to be moving at the same time since the updates are happening very quickly. The game moves and draws all objects by calling a main or draw function 20-60 times per second, top to bottom, instruction by instruction.
Often, the last step in a given lap through the game’s movement, input, sound, and other code is to update the screen (technically also happening pixels at a time as the memory buffer gets copied to screen buffer). In some environments like Processing or ActionScript this step is handled automatically; in C++ or most other environments it must be done explicitly, but it’s the reason why things seem to all be drawn and moved at the same time – the effects of their having all been drawn and moved one at a time aren’t displayed until all increments for this past fraction of a second have been accounted for.
Code Order Matters
This sounds like an insane thing to mention to programmers, but especially if someone is new in the transition from systems code into the object-centric real-time space, the seemingly self-contained nature of objects can be taken for granted as pure conceptual independence.
Sometimes bugs happen due to the right code being in the wrong order. No matter how well we try to group and organize our code to be self-contained, it’s always possible for otherwise working code to produce unintended behavior due to being out of order.
One very easy mistake of this sort is if the background images (sky or level tiles) get drawn after the player, items, or particles every frame, it will draw over them before each screen update, making them invisible. All the drawing code can be correct, with just one instruction in the wrong order. This isn’t anything to stress out about, as a lot of compartmentalized code will work more or less the same regardless of its order, but it’s something to be watchful of.
Asset Data Files
With rare exceptions, we don’t program the images or audio. We use programming to display images at certain coordinates, and to play sounds at certain times, but the images and sounds are usually created in outside programs. Images are often made in Photoshop / Gimp, and audio is often created or edited in Sound Forge / Audacity.
The assets (images, audio, 3D models, etc.) are just plain image and audio files, in whichever formats your programming library and asset tools both support.
Good Enough is Often Best
Collision between moving objects is rarely done per pixel or per polygon. Instead, distance is checked between two objects, or simple arithmetic is used to determine whether rectangular bounding boxes overlap.
For all practical purposes, it’s generally a perfectly fine approximation. It’s a faster and easier way to implement collisions.
Even if we had detailed collision functionality done for us though – perhaps as part of a library, or built into an existing engine we’re working with – for most applications we still wouldn’t want it. Simplified approximations like this one calculate faster, require minimal additional authoring (ex. polygonal collision detection requires an underlying collision shape to be defined for each graphic), and satisfy the conceptual goal in a way people are quite used to. If we went to the trouble of defining player character collision through detailed polygons defined for every animation frame, it may introduce weirdness like being able to run over the top of an item without collecting it – more development effort to produce worse results is a silly trade-off.
Program a Level Design Tool
Level design should be done by dragging and dropping, filling, by lasso selecting, copy pasting, saving/loading, etc. Not by programming. Time that the programmer spends implementing level layouts is time that the programmer can’t spend fixing bugs and adding features – plus it’s time that the designer has to wait between iterating on ideas. Even if you’re the both the programmer and the designer (as is inevitably the case for a solo project, and common for a small project where it’s mostly art/audio coming from others), it still massively accelerates production effort, ensures systematic consistency, etc.
The easiest way to make a level building “tool” is to hijack the game’s existing code, burying the tool functionality within it. Upon pressing F1 or some other out of the way key, toggle to a mouse-control, toss a panel of buttons/objects on the screen, and switch keyboard to controlling some handy key shortcuts. This can be stripped from the finished game, hidden in the finished game as an unlockable reward, or simply released with a tiny bit of “the level editor is rough… good luck!” documentation/help.
Cheats Accelerate Debugging
Add in invincibility, support a way to start or teleport in alternate locations (even if only by quickly/manually swapping around start position in a level editor), a way to max out items/ammo/powers, etc. If every time things are tested you have to play well enough to not die, collect a certain combination of items, and get to the right spot to test how, say, enemies climbing ladders respond to being hit by rockets – it’s going to take forever to confirm a suspected bug fix.
Build Quickly, Expand When/As Needed
Often in videogame development, we have to decide between a lot of ways that we could spend time adding or making cool stuff. It’s hard to know sometimes until something is implemented whether or not it will be as fun on screen as the imagination suspects – it’s hard to wrap the brain completely around the sheer number of things happening at once. For this reason it’s often practical to find a hacky or brute force way to implement a feature that takes less time, if only to see how it works before deciding whether or not to keep it.
This avoids sinking time into code that there’s a decent chance may get ripped out anyway.
If the hacked feature works well though, and it’s fast enough as-is, and the unpleasant details of implementation of swept into a function or class that you don’t need to look at much for other development, leave it as is until (if ever) there’s a sound reason for redoing it.
Minimize Time Between Code Compilation
Get a single enemy working before expanding it into an array of them and/or supporting multiple enemy types. Build a very plain sort of particle effect first – white spinning squares that burst out might be a fine starting place. Then adjust or add functionality as needed to support different needs of particles (fading for smoke, glowing for flame, directionality for thrust…). Get 1 power-up working first, perhaps the simple 1-up, then introduce others as a variation on that.
There’s necessarily time, while programming, between setting out to make something work and being able to see it work, during which time the code is in an incomplete, dysfunctional state. That time can be minimized by this method of building simpler first, then expanding out from that base. Minimizing the time between compiles and visual results is helpful since it prioritizes bug fixes while there’s the least variability. In turn, that reassurance from the machine that you’re on the right track minimizes cognitive load, freeing up mental resources to more easily juggle bite sized problems instead of trying to do several things at once.
Special Cases Should Be Special Cased
I’ve mentioned this point before in Knowing When to Hack, but it definitely bears repeating: “special case” is often treated as a bad word by engineers, but an actual “special case” deserves to be special cased instead of generalized. When a game has each boss behave distinctly, rather than as a recombination of shared components, it gives them more unique character; when a level has code written that only applies to that level, so long as it doesn’t break the player’s trained expectations of what to do, it can go a long way in making the experience less formulaic.
State Change Functions
Some functions, like the ones that set font color or position/rotate images, affect code that happens after them. Rather than specifying tons of parameters with each call, such as indicating that the text alignment should be centered, instead the code has a single line that centers any text calls that follow it, until code is added to change text to left/right alignment.
These sort of functions also appear in OpenGL, the graphics library commonly used for iPhone, downloadable, or 3D games. Unlike code which is called to perform some operation while accounting for certain parameters, the state change functions are called to toggle switches or set preferences which will affect any graphics calls that come after.
The Screen is a 2D Plane
The main thing needed from geometry is thinking about the 2D game’s visual space as a grid plane, with (0,0) in the top left, and (screen pixel width, screen pixel height) at the bottom right. Note that in most environments, down is positive Y – inverted from the standard used in classroom geometry.
Trigonometry and Vectors
For all things angles and movement, trig and vectors come in handy. Though not covered in depth here, there are plenty of resources on the web to learn about these areas of math. When you spot them in sample code, don’t gloss over how they’re being used – they’re often at the core of how the gameplay movements work.
Matrix Transformations (Push/Pop)
Matrix calculations can be used to capture a series of graphical calculations – scaling, rotating, positioning – into a single optimized transformation that can be applied to however many vertices/polygons need to be oriented as a set.
Because Matrix calculations are cumulative, this is a particular form of state change code (see above). Each line accumulates to have a final affect on the position, scale, and rotation of drawing calls that follow. We can make a call to the translate function giving it parameters for the camera’s horizontal and vertical offsets, and it will affect all the graphics code which follows, which is quite handy. But rather than having to undo every slide, rotation, and scale operation that we call (this would be a nightmare for all those slipping, spinning, growing particle effects images!), we can instead “Push” a Matrix onto the stack, perform the translations and rotation that we want to apply to all following image calls, then “Pop” that Matrix off the top of the stack, automatically undoing that transformation changes that we added after pushing it. Note that this only applies to graphical transformations – translation (sliding), rotation, and scaling – not to other state changes such as font color, image tint, etc.
More on Math for Videogames
See my previous article, Math for Videogame Making (Or: will I need to use Calculus?). To focus attention when visiting that page: tile arithmetic, vector geometry, and trigonometry are the most common.
Subscribe by e-mail to receive an update every month of all new HobbyGameDev articles, videos, and game development resources