Retro 2.0
Video games, when created by individuals, often fall into the category retro games: A genre that imitates the style and design of games authored in the early decades of video gaming.
It’s a smart pick. If the hobbyist would try to compete with todays teams of specialists that transform millions of cash into AAA titles he were doomed to fail. But two decades ago team size or money weren’t the limiting factors – the constraints were of technical nature. Back then a talented individual with a good idea could create a state-of-the art game. And thanks to better tools, better learning resources and faster computers all these games are perfectly doable now for anyone willing to learn how. Pick this niche and suddenly you’re on a level with the competition.
Despite all the limitations the old games were fun and often still are. Fun has nothing to do with photorealism. Reading a Book can be a compelling experience – because the story is unfolding in the mind of the reader. When a couple dozen abstract black symbols used in alternation can achieve that how could eye-candy and sourround sound be a critical factor in games?
At the core of any good game is the gameplay and/or narration. And to get that right you don’t need a lot of resources. Quite the opposite: The games industrie is often critizised for its lack of innovation. And when a multi-million dollar budget is at stakes you really can’t make experiements. When you have “asset pipelines” and the likes it’s hard to establish a shared vision of what exactly you want.
I think it’s still possible for individuals or a small groups to create games that matter. Thinking “retro” might help. But instead of recreating what has been done before rather copy the concept:
- Focus on gameplay and narration
- Build your game around a key idea
- Think about efficient reuse of resources
- Use the players imagination to fill the gaps
There are vantages to being independent. And there are possibilities far beyond those available decades ago. Contrasting this the indie movement in it’s current state is – with exceptions – still rather insignificant.ago
Filed under: Uncategorized | Leave a Comment
Tags: gamedev, Games, indie, retro
What I like about Flixel
I’m amazed how many flash games not only have the visual style but also the gameplay of the games of past decades. While there are good reason for pixelated graphics I’d really love to see a more variety in gameplay and presentation.
The technical limitations of the past are gone. Is there a reason not to have physics, particles, dynamic lighting, line of sight or shadows, AI driven enemys, complex simulations and cooler stuff that I can’t even think of in the games? No, not even when we’re talking about Flash games. Why we’re not seeing more of this stuff is because this technology is not made easily available to developers by the toolkit they’re working with.
A great example for the sleeping potential is the flash port of the Box2D physics engine that got released in September 2007. Even though it’s a pretty straight forward port that’s not optimized for flash at all a flood of games got released since, featuring completely new gameplay or enriching established genres with physics. The basis of a good game is a good choice of engine, tools and middleware.
A flash game engine on the rise (just my subjecitve impression) is Flixel. A game Fathom that the author of Flixel developed with it caught my attention: It’s not not only extremely polished but also had a surprising story-twist and unique elements like a fish swarm guiding your way, dynamic gameplay-relevant lighting and beautiful particle effects…
This speaks for the author’s talent but also for the engine. And based on how well Flixel is embraced by the community it’s apperently also easy to use unlike PBE a flash game engine I’ve been working with. I think “ease of use” is really a key factor for any tool or software targeting the hobbyist. Game development should be about asking what while most people seem to struggle with the how. I’d wish for game development to be as accessible as painting a picture or writing a story. In it’s current sate it’s a form of media that most can only consume not express themselves with. The crucial step of evolution would be to overcome this barrier. Everything that helps that goal has my sympathy and that it seems like a step in the right direction is what I like about Flixel.
Filed under: Uncategorized | Leave a Comment
Tags: AS3, Flash, Flixel, Games, PushButton
Unpredictable Flash
In the last couple of months I’ve programmed a lot of AS3 code. And when there was performance critical code to write it often got frustrating. The problem is not that AS3 compiles into bytecode which is running on a virtual machine. It’s not the lack of hardware acceleration or threading. The problem is a lack of transparency – it’s often impossible to implement the fastest option without trying and comparing different possible options!
When given a task I need to know how long it’s going to take me and how big ther performance hit is before I spend days on the problem. But in Flash you never really know how fast a possible solution is going to turn out to be. And if you implement it and it turns out slow you often can’t be sure if there’s a faster way or if you reached the limits of Flash.
Now, you might think I just suck at coding. So let me give you an example.
I have a source Bitmap object and want to draw it with a PixelBender shader in my target buffer.
var target:BitmapData; var source:Bitmap; ... source.blendShader = myShader; target.draw(target, matrix, colorTransform, BlendMode.SHADER, clipRect);
Welcome to the first pitfall: The clipRect does work but it doesn’t affect the performance. You can set it to a one pixel square and it still evaluates every pixel in the target buffer.
Good to know? Yeah, but it’s not in the docs. Not sure that the people at Adobe even know about it. Anyway, if my dirty rectangle is small enough it’s worth it to copy the relevant pixels into an intermediate buffer apply the shader on it and copy it back. copyPixels comes to mind, right? Yes, that will work. And we all know how fast that is. But besides copyPixels there’s also a getPixels and a getVector method that allows me to extract a rectangular portion of the source. How fast are these? Turns out that copyPixels is the winner, getVector is about 50% slower and getPixels which basically does the same thing is 500% slower then copyPixels. Dooh!
But why do I even mention alternatives to the copyPixels way when it’s fast and everyone that reads blogs knows that it’s fast? Because getVector is a valid alternative. Turns out there’s quite some overhead to setting up and executing a pixelbender Shader. And after some more testing it turn’s out that for my specific simple shader the fastest option to update small rectangles in the target buffer is to just extract that portion using getVector, then iterate over the contents of a target and a source vector, do the calculations in plain Actionscript and copy the result back using setVector.
It’s a matter of luck and stubbornness that the tech demo I’ve been working on was successfully pitched and not canned as “not doable in flash”. Writing bytecode directly can’t be any harder then that. 
Filed under: Uncategorized | Leave a Comment
Tags: AS3, Code, Flash 10, PixelBender
Let’s blog!
It bugged me for quite some while that the nice domain I’ve been holding for years was linking to an increasingly outdated website showing off some student projects of mine. Considering how easy it is to setup a blog (you read the prove) I decided I’d give it a try.
First there’s a topic to chose, though. Something I know about. And something other’s might care to read about. The only topic that stands a chance to fulfill both requirements is Game Development.
I wanted to create games for the better part of my life: It started when I wrote a Harry Potter broom-riding game in 2000 and noticed with surprise that this simple game I programmed with my self-tought Delphi knowledge was spread and enjoyed by thousands of Harry Potter fans. I received mails of fans every day telling me about their highscore or making redicoulous feature requests. And I realized that making games could be more fun then playing them! 
Now, 10 years later, I’m earning my living as a game programmer. And I will use this place to share my thoughts and other creative output. Let’s see where that leads to!
Filed under: Uncategorized | Leave a Comment
Search
-
Blogroll
