Developer experiences from the trenches
Sun 28 August 2011 by Michael Labbe
tags design
The average video game has writing that is indistinguishable from filler. Writing makes its way into games through dialog and story. One approach to improving the quality of writing is to employ inspired writers. Unfortunately, this is as useful as a VHS repairman unless you design in reasons for the player to care about your writing in the first place.
It is not just the writing that needs to improve. We need to refine the techniques to bring narrative to the player, making the experience personal through integration into the core game. In the order of most to least effective, here are some examples of methods that have been used:
Giving the player a reason to care about the story is as important as the story itself. The humor in Portal 2 is a lot more personal because you are unfolding it by moving forward. Imagine the game popping away to cutscenes to crack the same jokes. It just wouldn’t be about you anymore.
Interactive story progression requires a set of techniques that, when employed, ensure the player is paying attention when the story unfolds. It also helps the story progress at a pace they can comprehend.
First person shooters have done a pretty good job of making people care about their stories. But what about platformers or turn based strategy games? There is a lot of work to be done before these genres have empowered their writers.
Fri 26 August 2011 by Michael Labbe
tags biz
The biggest challenge the game industry faces right now is not the invention of new games and IPs but the discovery of new models to supplement the existing, more traditional ones. Model experimentation is to the game industry in 2011 what cellular regeneration is to an injured human.
One example of a model innovation is the Free to Play model. In Free to Play, an effective game designer teaches players about a value system in their game. Once this is underway, they upsell the player on in-game features that have value within that system. In this model, the developer ultimately convinces people to buy the game. Usually this job belongs to the marketing team. (Yes, Free to Play should be called Pay to Play).
In traditional boxed retail, the marketing team teaches the customers the value of the product through screenshots and trailers. If the proposition resonates with the customer, they’ll probably buy the game.
In some situations, Free to Play teams have, effectively, put marketers game designer’s chair. These games are often thin veneers overtop of a spreadsheet that optimizes customer conversion.
A lot of dedicated gamers love escapist multiplayer experiences. If Free to Play is to truly succeed amongst dedicated gamers, it is the game designers and developers who must stretch to understand how to account for player behaviour and incorporate it into their tool belt.
Free to Play is definitely coming to your favourite types of games. Game development incorporates such a wide range of professions and skill sets. I am excited that it now incorporates one more.
If you find Free to Play ominous, you are always free to prove out a different model. :)
Signed, a guy who plays Free to Play Team Fortress a whole heck of a lot.
Sat 20 August 2011 by Michael Labbe
tags PR
There is no mother lode of eyeballs waiting just on the other side of your game’s launch.
Frogtoss released Zombie Minesweeper a few weeks ago. Let me tell you this: if you’re planning on making a living releasing games, make sure you can answer the question: Why will people check out your game?
That’s a very different question than Why should people check out your game. If you answered “because it’s really good and focus tests have gone SO well” then you are answering the second question, not the first one.
If you ask people who have been successful in launching games on the Internet in recent years, they will frequently tell you that there was no one action that they took in order to build up an audience and anticipation. Instead, a lot of smaller actions built up their presence over time.
Maybe you saw how it worked in the early days of game promotion where all you had to do was release a product and people would check it out and it could rise up. Picture the Monolith from 2001: A Space Odyssey landing and monkeys jump up and down around in a primal world. Try planting a black, shiny block in the middle of Times Square. People would just walk on by and probably just drop litter at its base. We’ve seen shiny and black. You don’t deserve the people’s attention just because you showed up.
One of the most exciting press stories is by the most hardcore indie developer in the western hemisphere, Brian Provinciano. He is the main man behind Retro City Rampage. Take a look at his Twitter and Facebook pages to see how he has been incrementally building buzz for years. Stop looking for the next big leap forward and take a cue from Brian. Brian is uniquely impressive in that he can write NES assembly but also capture an audience of thousands with his words. He is doing interesting work and he deserves your attention. People will check his game out because he’s out there.
Being a small developer means stretching in all directions. When there is no one place to go to get attention for your work, be prepared to go in a hundred small directions.
Mon 09 August 2010 by Michael Labbe
tags code
Hardware is the basis of understanding rendering. Not numerical problems, not geometric problems and certainly not memorizing OpenGL or Direct3D APIs.
One of the most first questions that needs to be asked when deciding to implement new graphical features is what needs to be implemented on the general purpose CPU and what can be computed on a GPU (or even a set of SPEs). This question is impossible to answer without a fundamental understanding of the hardware you are programming for. The abstraction of your favorite API does less to mask this as more programmatic options become available. Consider:
Once you can competently speak on these points, you can start to devise a hypothesis about how to best divide your hardware resources to render a typical scene for your game.
At this point, you have a shot at guessing what data needs to be where in your pipeline and when it needs to be there. This is the point when numerical and geometric issues move into focus.
OpenGL (with the exception of OpenGL ES) is a pool of functions, many of which superficially achieve the same results but with different approaches to dealing with bus latency. As memory latency becomes more of an acute problem in paring down hardware implemented pipeline stalls, literature promoting immediate mode and display lists continues to be the most prominent information on OpenGL in spite of the strong need for sizable data batches.
I’m always going to be a fan of getting stuff up on the screen quickly and programming some sample apps in OpenGL does give you something to mentally referenece when learning theory, but you aren’t programming anything really interesting until you’ve understood the graphics pipeline and at least the timeline of how hardware acceleration has crept backwards through the graphics pipeline over the past ten years.
Jim Blinn’s Corner: A Trip Down the Graphics Pipeline - An old one that covers software rendering, but gives you a basis of understanding of the graphical pipeline.
Real-Time Rendering - Currently in 3rd edition. The modern replacement for Foley and VanDam. The chapters on performance and hardware combine with the fundamental understanding of the graphics pipeline to help you really understand what’s going on.
Technical briefs for hardware prepared by NVidia and ATI for target hardware. This information is made available on their respective sites.