Whether you’re a first time reader, or a long time peruser, the following are pieces from past editions of GameDevLessons.com Text Lessons that I would like all readers to know are available. [A couple of months after this article was posted, GameDevLessons changed to HobbyGameDev, and the Text Lessons were rebranded as Articles.]
Please Note: This section is an annotated/thumbnail index, not a summary! If its subject seems of interest to you, you can find the whole article via the link above the excerpt.
“Code is like a film script. However, whereas a film script can be followed without interruption, interruption is precisely what a player does. Because of this, code is a situational script…”
“Want to focus your attention at being the among the best in the world at graphics optimizations, writing scalable networking code, 3D modeling futuristic settings within a memory budget, or creating complex 3D levels? Those kind of opportunities are virtually non-existent in the independent game space, due to smaller teams, smaller budgets, and smaller time frames…”
“This is not intended to take the place of a good book on programming, or practice – it’s here for warm up, review, or to complement other resources that are out there by providing a connection to how the most common code structures are used in videogame development…”
“Odds are, you’ve never played more than one published title that used the same underlying level design philosophy. What works in one game, given its AI, weapons set and player interface generally does not translate well to another title in the same genre. Goldeneye N64 levels make poor Doom levels; Doom levels make poor Unreal Tournament levels; Mario levels wouldn’t work for Sonic and Sonic levels wouldn’t work for Mario…”
“Being good with computers isn’t about knowing everything. It’s about knowing how to look up or figure out what you don’t know. Similarly, teaching yourself to make videogames is largely a matter of knowing which resources are available to you, and how they can best be used to accelerate your progress…”
“AI in real-time videogames is not about trying to program intelligence. It isn’t about making the best decisions, thinking through complex problems, or adaptive learning.
AI in real-time videogames is about creating the impression of intelligence…”
“Puffs of dirt kicked up from tires, smoke after explosions, empty shell casings ejecting from automatic rifles, and splashes of water are all particle effects. Shattered pieces of scored gems in a puzzle game, splatters of blood from gunfire, broken glass, chunks of wood, snowflakes, sparks, and shards of plants are all particle effects. Particle effects are categorically different from most other objects in a videogame…”
“A lot of programmers want to learn enough game design to make their own games, and a lot of game designers want to learn enough programming to make their own games. But let’s not kid ourselves when it comes to art: thousands of years of human progress have shaped art, and drawing or 3D modeling (especially animating) can be a very time consuming practice that requires a healthy dose of talent. What can a programmer/designer do to cope with lack of art time or ability?”
“Sine and cosine are helpful for angle-to-component translation, for example when determining what percentage of a bullet’s total velocity the x-speed and y-speed are given the angle of a firing cannon – this also applies to an overhead race car. Atan2 is handy for getting an angle between two things, given their relative offset in grid locations – good for getting an enemy to face the player, pointing a simple homing missile, and so on…”
“Technical ability is best thought of as a gate to entry – while it’s great to have it behind you, it’d be counter-productive (and inaccurate) to presume that the most important things to learn and get practice with are already learned…”
“There’s a pervading notion in videogame design courses, lectures, books, conference workshops, and online discussion forums that the best way to understand and plan videogame design is through a deep analysis of dice, spinners, playing cards, board games, and the like.
If our daytime work was with Milton Bradley or Parker Brothers, this would be a worthwhile use of time. For the more than 40,000 of us in the USA working on real-time electronic videogames, I think that most of the analysis in analog space is an inefficient way of highlighting some vague commonalities at best, and more often than not, a dangerously sneaky way to get sidetracked…”
“Whatever we choose to put on the surface to capture imaginations, I’m hopeful that we can all start paying equal attention to the things we’ve been doing right accidentally for decades: teaching players new thinking tools, conditioning them to connect good deeds to desirable results, and keeping their hunger for new skill development strong and nurtured at all ages…”
“It didn’t matter that my pictures were crude, it mattered that they were sufficient to excite synapses and fill in between my thoughts. It likewise didn’t matter that the graphics, sound, and interactions of Mega Man were crude. For the same reason.
What happens inside the player’s head, while and after they are playing the game, or even before (Gravity Man, Gyro Man, Magnet Man, Air Man… such cool ideas!), is the most important part. What happens on screen, how long it happens, and how it looks while it happens, is an instrument to implant, adjust, and shape ideas…”
“Smart engineers feel guilty about writing ‘special case’ code. Special case code is a bad idea a lot of the time, because it’s time and energy that cannot be effectively re-used elsewhere. But in the case of videogames, we must ask: is this a special case? Should only 1 boss in the game do this? Does this effect only happen in 1 level? Do all other power-ups disable when this bonus level is entered? Special cases in the game warrant special cases in the code, and those special cases are what can make boss fights in Mega Man so distinct, as opposed to the not-so-special-cased (but rather cost-effectively generalized) 4 types of bosses used 50 times in Superman Returns…”
“I agree, that ‘games on a fundamental level consist of their rules’.
I disagree with the common argument that videogames on a fundamental level consist of their rules.
From the perspective of someone that seeks to breed, play with, judge, or theorize about dogs, we are most likely concerned almost exclusively with how they are while alive, and generally disinterested in the composition of their physical parts. Rex’s body is not Rex after death (though we may use the name to refer to the body), and Tetris is not Tetris when it isn’t running (though we may use the name to refer to the cartidge/machine/file)…”
“The transition in gameplay maturity from Doom 1 and 2 to Doom 3 is like the difference between Hitchcock/Kubrick/Lovecraft horror vs a teenage slasher film, like the difference in storytelling between Bram Stoker’s Dracula vs Bram Stoker’s Dracula; the classics respect that real panic is induced by psychological strain, while the latter assumes that it has to do with the amount of blood, screaming, and offensive imagery…”
“Whereas a narrative may carry a moral message, and whereas artistic representations may embrace expressions of love or struggle or madness, gameplay trains and tests particular ways of thinking. I built the gameplay of Alice in Bomberland specifically to require some of the basic considerations and thought processes that I perceive to be parts of sound thinking…”
“If I’m voluntarily staying late as a designer working on a wish list feature or extra level content, before doing the stuff that is on the must-do list (because I know we’ll have to make adjustments for the must-do list, but not vice-versa, so this way I can be sure to pack more in), then it should be no surprise when soon after I’d be staying late even when it isn’t my choosing to do the must-do items that I wasn’t focusing on. But this wouldn’t just throw me off. No, it could affect bottlenecks in the schedule, it could introduce a need for new bug fixing, sounds, or modeling work that otherwise could have been avoided, and so on. Now imagine every person doing this to every other person as the project gains momentum and people get excited. Combine that with a financial imperative to release on a certain ship date, and exactly why this turns into a train wreck nearly every time should be fairly obvious…”
Transcribed from audio: “Seven months; 219 games were done. Near the end of it, some of them were definitely not games which, again, was part of my goal… Some of these things I would crank out in two hours. Some of these things, like on Christmas, I made a maze type game that I probably spent a good 16-18 hours hacking away on and tuning. It was a form of illustrated concept…”
“Every year, many videogame development clubs start. Many of them initiate a handful of large projects, struggle with teams falling apart as member retention suffers, and after a couple years of sliding schedules, either close down or transform into a game playing/culture club instead of game development club.
Of course, what worked for us certainly isn’t the only way to do things… All I can say for sure is that these rules of thumb worked well for us during the first few years. I’m hopeful that others with drastically different experiences will help share learnings from their organizations, as well…”
CD: Speaking of family, do your sons play videogames?
WR: Oh yeah, they play videogames constantly. I have more of the dad point of view than the designer point of view these days though – I can’t get them off the videogames, they’re up until 4am playing them.
CD: Are your sons old enough to appreciate your role in game history?
WR: Sort of, but they’re not that impressed. It’s kind of hard to tell. They think it’s cool.
CD: Have they played your games?
WR: Yea, they’ve played my games. As you probably know, kids below a certain age are not worried about being bluntly honest, so they’ll give you direct feedback. They told me quite clearly how stupid and old fashioned my game Adventure was. That just doesn’t cut the mustard by modern standards…
“Japanese videogame artists work almost exclusively in the resolution, format, and fidelity required by the game, concerned almost exclusively with how their art looks during play. Concept art, and the sort of high detail imaginative sketching that appears on packaging and manuals, is often produced after the videogame’s art needs are filled, while waiting for the game to ship. Rather than being a process step – except in the case of very rough sketches for personal planning – this sort of art gets done late in the process separately, explicitly for use in marketing materials…”
“This e-book highlights what I have learned about videogame development along that journey. This is not a programming book, nor is it an art book. It is not a how-to book. This is a page-by-page, succinct presentation of nearly every game that I have worked on, followed by what I consider the most valuable takeaways from each particular development experience…”
Originally posted as part of GameDevLessons.com Vol. 12
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!