Look Ma! I've made an earth!

Operation Survival needs a three dimensional view of the whole globe. I have managed to get a first prototype working: Try it here.

Lots of learning was involved before I got this far:
- evaluating and deciding on a flash 3D engine (Away3d)
- efficiently implementing and caching filters for large images
- perspective projections. Note for next time: you do _not_ see half the sphere after projecting it to 2D but significantly less
- The day/night line is calculated and updated in realtime (let the program run for a while to see it). Some funky math and astronomy was required to get this just right
- Quaternions. For smoothly rotating the camera around the globe without running into gimbal lock
- lots of Actionscript idiosyncracies, this is my first flash program after all

I'm quite satisfied with the results. Now I need to add stars to the background and figure out how to best draw flight paths and markers on the surface of the sphere.

ActionScript pie menu

Since the flash player hijacks the second mouse button for its own context menu and there are rumored to be some obscure, barely relevant platforms like, ahem, Apple, that don't offer one to begin with I needed to come up with another solution for context menus. I came up with pie menus that open when you click and hold the left mouse button. You can choose a button by moving over it and releasing the mouse.

It features smooth tweening transitions and fades, a subtle 3D effect, a text help when hovering over an option for a second and an arbitrary number of buttons and icons. The final version will likely also have sounds.

This is all plumbing work for Operation Survival for which I want an intuitive, non-intrusive user interface.

Please try it and tell me what you think!

Performance Rant (part 2)

Last time I argued performance is still as relevant as ever. This time I'm gonna point out some common coding mistakes to watch out for.

First and foremost: Know your datastructures. This should be trivial computer science 101 material but I'm amazed at how often people get this wrong. Understand BigO notation for worst case runtime and memory behaviour of your algorithms. Understand why worst case isn't all that matters and that the little omitted "constant factor" may just make an O(n log(n)) algorithm a better choice than an O(n) at times. Be aware of the tradeoffs in your particular situation and make a conscious descision. Be wary of programming languages and libraries that blur the distinction and consider it an unimportant implementation detail. There is no such thing as an "ArrayList" and suggesting otherwise should be a criminal offence (yes, I'm looking at you Java). In the same vein, there is a huge difference between an associative container and a plain array. Be very suspicious of languages that treat one like the other and allow indexing arrays with strings (PHP...). And if you do decide to use associative containers (i.e. maps or dictionaries) know whether you are dealing with hash based or tree based implementations. That's a non trivial difference with potentially huge consequences for your code!

Choose the proper tool for the job. Some programming languages are good for one-off scripts or quick prototypes. Be careful trying to morph a proof of concept prototype developed in a fast-to-develop-in but slow-to-execute language into the final product. There is a real and inherent speed difference between different programming languages. And it's not trivial either but can be up to 100x. Trying to optimize a slow program in a slow language is possible, but is like making a top athlete run a marathon in rubber boots. He'll probably still arrive, but why not start in proper running shoes to begin with?

Choose the proper default case when designing your interfaces and decomposing your problem into functions. The common mistake here is to do one matrix-vector multiplication, draw one sprite, measure one line of text, perform one ray-polygon intersection. But is that the most common usage scenario of your functions? Really? Isn't it rather that you usually have lots of similar items and n=1 is the exception rather than the rule? Transform all vertex positions by the view matrix, draw all enemy UFOs, measure the whole text box content and hit test against the full environment? If you design your interfaces to work in batches you'll increase locality, minimize graphics hardware state changes and reduce redundant/repeated set ups and tear downs. Too many libraries get this wrong.

I've mentioned this in the previous paragraph, but it merits repeating: Locality is really important. Keep related data close together in physical memory. Compared to the speed at which modern CPUs operate main memory accesses are glacially slow. You want to take maximum advantage of the CPU's cache hierarchy. The best way to really screw up the cache is to scatter memory accesses all over the place and intermix write and read accesses. This has some interesting consequences. First, simple (sorted) arrays often beat more complex datastructures although theory and BigO analysis would indicate otherwise. Second, classical object oriented object hierarchies are your enemy. Traversing down a nested tree of objects in a loop to call render() on the leaf nodes is really expensive. Keep your hierachies flat and put related objects together.

I've riled against garbage collection before, but this is another reason why you should avoid it. If all your objects have to reside on an automatically managed heap you are completely at the mercy of your runtime environment to make the right decisions which objects to put where.

I could go on for a while, but I think this is a big enough wall of text for one post. Fear the next installment!

PS: Do follow the links - they point to articles, talks and slides of people far more knowledgable and eloquent on the topic than I can ever hope to be.

Performance Rant

I recently got on my performance soapbox again. I don't like repeating myself endlessly and my therapist advised me to write it all down to get it off my chest. So here it goes:

First of all, with today's computers performing some billions (as in 9 zeros, 1.000.000.000) operations per second does performance even matter? The answer must be a resounding YES for a multitude of reasons.

The term "computer" today covers a huge magnitude of devices with very different performance characteristics and capabilities. Think IBM mainframes, high end server hardware, office desktops, laptops, cell phones, GPS devices, ... Even if your high end Alienware gaming (ahem, "development") rig doesn't break a sweat doesn't mean others won't.

The free lunch is over. Programs once written will likely not get faster automatically with the advent of new hardware. It used to be that each new generation of CPUs would boost performance of existing software. Not any longer. We seem to be approaching some physical limits of how much further we can push CPUs. So we are sidestepping the issue and investing in parallel architectures. But software must be explicitly designed to take advantage of this, which is not easy. Cars aren't getting any faster, we are building wider highways instead.

Problem sizes keep growing. We keep demanding more of our machines. Text chat isn't enough anymore, it must be a live video conference with 10 participants. Games are approaching Hollywood blockbuster movie special effects quality, complete with voice acting, motion capture and serious camera work. A simple word document (yeah, yeah, I mean tex of course ;-) ) for a home work assignment would have made a professional typesetter proud a mere generation ago. Megabytes are trivial, we are counting Gigabytes today. All the way up to "google-scale" problems with "FuckYeahBytes" and computing power measured in acres.

User expectations have evolved. A keyboard and console isn't enough any more. We need animated, immediate feedback, graphical user interfaces. Voice recognition. Gesture recognition. Touch devices. Since there is such an endless plethora of applications to choose from our tolerance for lag is shrinking. If an app annoys us we simply switch to another.

Mobile devices and battery power. Inefficient code uses more CPU cycles than necessary, draining batteries. Desktop computers are getting smarter, dynamically reducing CPU energy usage based on current load levels. Efficient code saves energy, saves the planet: "green" computing!

Concurrency. Users are increasingly accustomed to a multitasking environment. Type your homework, watch some youtube, chat with your buddies, listen to music, download some torrents and tab in and out of WoW all at the same time. Or have a dozen browser tabs open each containing flash and media heavy interactive content. What about running multiple operating systems in virtual machines? Even multiple GBs of RAM can quickly be exhausted in such a scenario. Applications need to be good citizens and not assume ownership of all of a machine's resources.

Servers. The modern web experience requires massive server infrastructure behind the scenes. Efficient server code has dramatic effect on the bottom line. If a performance improvement of 10% means you have just saved 20.000 additional servers that's a huge win in maintenance and acquisition costs. Take facebook as an example, where choosing C++ over PHP could have just provided such a boost. And indeed, they have built a custom PHP to C++ translation engine (Hiphop).

So yes, performance is as relevant today as it has ever been in computing. And it gets honored by the marketplace as well. Slick, smooth user interfaces are appreciated - witness the success of Apple or Win7 (and it is no accident either but a very conscious effort).

Next up: my performance pet peeves.

Summits

[TODO] fix

quote...

"Garbage collection solves the obviously very difficult problem of managing resources and object live times, by substituting in the much easier problems of non-deterministic thread-safe object destruction and dangling circular references. Not to mention unpredictable performance spikes.

GC makes an easy job easier, by making hard stuff harder. Worst. Compromise. Ever.

But don't mind me, do go on."

-- SWENG mailing list

Santorini

Anita and I just came back from a two week vacation on Santorini. Great fun. Very hot. Tourists watch and applaud the sunset - weird.

Motivation

What motivates one to give up a safe and comfortable life, quit your job, waste your life savings, leave friends and family for a long time, and try for the great unknown? Some quotations...

"Twenty years from now, you will be more disappointed by the things you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover."
- Mark Twain

Live today so you don't have to do it tomorrow.

Live as if there will be no tomorrow, Learn as if there will be no end to time.

Your trip sounds awesome. that should be a lot of fun. Life is too short to sit around dying in front of a computer in an office somewhere...
- Anton Rabien

The dream of yesterday, is the hope of today, and the reality of tomorrow.

Between two evils, always chose the one you haven't tried before.
- Iris

Every oak tree started out as a couple of nuts who stood their ground. Go nuts!!!!!! Stand proud!!!

"The first question which you will ask and which I must try to answer is this, 'What is the use of climbing Mount Everest ?' and my answer must at once be, 'It is no use'. There is not the slightest prospect of any gain whatsoever. Oh, we may learn a little about the behavior of the human body at high altitudes, and possibly medical men may turn our observation to some account for the purposes of aviation. But otherwise nothing will come of it. We shall not bring back a single bit of gold or silver, not a gem, nor any coal or iron. We shall not find a single foot of earth that can be planted with crops to raise food. It's no use. So, if you cannot understand that there is something in man which responds to the challenge of this mountain and goes out to meet it, that the struggle is the struggle of life itself upward and forever upward, then you won't see why we go. What we get from this adventure is just sheer joy. And joy is, after all, the end of life. We do not live to eat and make money. We eat and make money to be able to enjoy life. That is what life means and what life is for."
- George Leigh Mallory

All men dream, but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dream with open eyes, to make it possible.
- T. E. Lawrence, "The Seven Pillars of Wisdom"

"It's not everyone telling me it can't be done that bothers me. It's them interrupting me while I'm doing it!"

If something breaks:
You can be in trouble even in Upstate New York.
You can be in serious trouble in Northern Minnesota.
You can be seriously dead in Central Alaska.

It seldom happens to Icebikers, because they are too smart, but every year several snowmobilers and skiers are lost in Alaska, the Yukon and other frosty places. The North does not suffer fools gladly.

With the possible exception of written language, the bicycle just may be the neatest idea we humans have ever come up with.
- Michael Zezima, "Road Kill: Fifty Reasons why Cars Suck"

The bicycle is the most civilized conveyance known to man. Other forms of transport grow daily more nightmarish. Only the bicycle remains pure in heart.
- Iris Murdoch, "The Red and the Green"

Some things have to be seen to be believed
Most things have to be believed to be seen

It's better to climb a mountain and think about god, than going to a church and think about a mountain...
- unknown climber

I don't mind going nowhere as long as it's an interesting path.

The disadvantages involved in pulling lots of black sticky slime out of the ground where it had been safely hidden out of harm's way, turning it into tar to cover the land with, smoke to fill the air with and pouring the rest into the sea, all seemed to outweigh the advantages of being able to get more quickly from one place to another -- particularly when the place you arrived at has probably become, as a result of this, very similar to the place you had left, i.e., covered with tar, full of smoke, and very short of fish.
- Douglas Adams, The Restaurant at the End of the Universe

...and the road becomes my bride
I have stripped of all but pride
so in her I do confide
and she keeps me satisfied
gives me all I need
...and with dust in throat I crave
only knowledge will I save
to the game you stay a slave
rover wanderer
nomad vagabond
call me what you will
but I'll take my time anywhere
free to speak my mind anywhere
and I'll redefine anywhere
anywhere I may roam
where I lay my head is home
- Metallica, "Wherever I may roam"

What if we fail to stop the erosion of cities by automobiles?... In that case, we Americans will hardly need to ponder a mystery that has troubled men for millennia: What is the purpose of life? For us, the answer will be clear, established and for all practical purposes indisputable: The purpose of life is to produce and consume automobiles.
- Jane Jacobs, author, The Death and Life of Great American Cities

"violent bout of escapism turned productive" (Wow, that is perhaps the best description of a bike tour we've ever seen.)

"It's not that bicycling is so important, it is that everything else is equally unimportant."
- Bruce Ole Ohlson

If I can cycle to Africa, others can cycle to do their shopping.
[...]
I'm an environmentalist, I suppose, and cycling is peaceful, non-threatening, open. It leaves me kind of vulnerable. What's around me can touch me, affect me.
- Richard Gregg, ICBM (InterContinental Bicycle Man)

this is your life, and it's ending one minute at a time.
this isn't a seminar and this isn't a weekend retreat.
where you are now you can't even imagine what the bottom will be like.
only after disaster can we be resurrected.
it's only after you have lost everything that you are free to do anything.
nothing is static, everything is appalling, everything is falling apart.
[...]

you are not your bank account,
you are not the clothes you wear.
you are not the contents of your wallet.
you are not your bowel cancer.
you are not your Grande Latte.
you are not the car you drive.
you are not your fucking khakis!
[...]
- Tyler Durden, Fightclub

I am now on my 3rd serving of beer and am clearly beginning to feel the effects as the liquor saturates my dehydrated body. As I have said from the beginning, climbing Mount Everest happens to be “my Everest” however, there are as many Everests to climb as there are dreams to be had. Life is far too short; live it with vigor, vitality and enthusiasm and tackle all your dreams head-on and do not be daunted with the words “I can’t” for these words truly have no meaning. Good luck to all of you with your journey in conquering, “your own Everests”.
- Glenn Edwards

friends and liars
don't wait for me
cause I'll get on
all by myself
put millions of miles
under my heels
and still too close to you
I feel
- Audioslave, "I am the highway"

(note: I don't know the original source of many of the quotes and pictures, please feel free to contact me if you do)

Soulbiking

The following pages contain all information relating to my bicycle journey. I called it Soulbiking because it was meant to be a sabbatical in search of personal freedom and soul resting. Actually I'm not as much of an esoterical nutcase as that sentence makes me sound like and the practical reason for choosing that name is because it just sounds cool. Also there are about a quadrillion pages about bicycle journeys on the net but no one uses that word, so it's a good unique keyword for search engines. Anyways, dive right in, have fun, and get your own bicycle out of the garage some time...

What?

A journey. By bicycle. I don't know for how long and have only vague ideas where. I always say it'll take as long as it'll take or as long as motivation, health and money last me. I figure I've saved enough cash to keep me afloat for a couple of years. Health will hopefully last for much longer than that. And motivation? ...who knows. There are so many reasons why one may quit. Homesick. Missing friends and family. Tired of fighting the wind, the rain, the mountains. Tired of being homeless. Tired of being lonely. Tired of being tired. Or the positive alternatives. I might find home. The girl of my dreams might find me. I am not determined to "finish" this at all costs. First and foremost the trip is to be a positive, fun learning experience. An adventure I can undertake, because I'm young, healthy and unbound. An adventure I want to undertake because I want to see more of the world. Experience it first hand. Because I am frustrated with lots of things in our modern society and how things work here. I'm not saying it's better anywhere else in the world, maybe it's not. But I want to see the alternatives with my own eyes, so I truly have a choice.

Bicycle?

In my eyes it's the perfect means of transportation. You are fast if you want/have to be, while being able to carry all the equipment you need with relative ease and comfort. You are free to go wherever you want to. You travel by your own muscle power and win back the feeling that the earth is a huge and marvellous place to be in. It's good for your health and you enjoy the effects on your body and the satisfying exhaustion after a day of pedalling. It's environmentally friendly. It is a social vehicle, you are open, slow, interesting - easy to communicate with. It doesn't cripple your senses, shield you from your surroundings, so you experience the effects of weather and landscape directly and pure. You don't rush by sights and experiences. It's a relatively simple mechanical device - you can repair and tune it yourself and even in the unlikeliest of circumstances.

Money?

I find it a little bit sad that this is almost always the first question asked. Money sucks. Big time. But since you've asked... I've worked and saved for this tour for more than 3 years now. I have a very frugal lifestyle. I do not own a car. I do not smoke. I seldom drink. My clothes are no names and I wear them out (I bought my last pair of shoes in 1998 - and yes, they are still fine). I don't spend any money on cosmetics or the haircutter. I do not go out to bars or discos and drink away $50 in an evening. I go on self organized camping trips instead of five star tourist traps. I eat in the university cafeteria.
And besides all that I'm privileged to come from a relatively wealthy family and live in a wealthy country and have a hobby that at the same time makes for a well paid job. Thank you fortune.

Girlfriend?

Trying to find one that'd share my "Fernweh" itch and come explore the world with me. And yes. The tour has been in my way a couple of times already, and yes, it is damn hard, and no, I won't stay. No topic for a stupid website FAQ. But come on over, have a couple of drinks with me and I might answer your questions... ;-)

Where?

If I only knew. The idea is to start with the "Europe tour" as I call it. Along the Danube to the Black Sea. North from there, west through Scandinavia, south again. Meet a friend in Spain and continue on through Africa. Climb Kilimanjaro and set sail to east coast America. Cross Canada east-west. Be done with it. I do not plan that far ahead. Actually I almost don't plan at all. I do not want to create and raise expectations which I'll have to fulfill later on. Even if they are only my own. Above all this tour is supposed to be fun. No stress allowed. One reason I go on this trip is to experience the freedom of living without time and direction. No deadlines to achieve, no places to reach.

How Long?

As I already said in the introduction: as long as motivation, health and money last me. However long that may be.

When?

Birthday party on March 16, 2004. Leaving in the days after as soon as my hangover will have left me ;-)

Job?

I've quit my job for March. No idea what I'll do, want to do, can do, when I'll be back. Maybe apply for the same job in the same company again. Or become a diving instructor on Sri Lanka. An astronaut. A firefighter. A lottery millionaire. Same goes for university. I won't have my diploma when I leave and I seriously doubt I want to go back to university routine when I'll be back.

Why?

Check out my motivation pages. In short: I'm a dreamer, an explorer, an environmentalist, a Hippy, an outdoors lover. Or try the spiritual reasons: finding oneself, experiencing your own limits and moving them outward, proving oneself. Or the practical ones: it has been a dream of mine for so long, now is the time to go for it, I'll probably never be as young, as healthy, as free and unbound again. Or the heritage ones: I'm a child of two worlds, always torn between them, trying to find my place. Or the negative ones: I'm frustrated with our society, our way of living, want to learn about alternatives. Want to flee a whole lot of stuff and some folks and memories. Or just curiosity? Fernweh?

Book review: The Design and Evolution of C++

This book is very interesting in that it doesn't tell you how to program in C++ but rather highlights why C++ is the way it is today. It starts with the very roots, an extension to the C language ('C with classes'') Bjarne devised back in 1979, because he faced a software engineering problem at the time where all currently available tools seemed inappropriate. This highly real world oriented design attitude was kept throughout the evolution of C++ - Bjarne specifically didn't want to produce an 'academic' language. This view and the absolute necessity for C compatibility and efficiency explain lots, if not all, of C++s more ugly syntactic and semantic constructs. While the book has chapters dealing with very specific parts of the language, I found the philosophical chapters the most interesting. These explain the author's personal views on programming and design in general and consequently why certain things were accepted or rejected into C++. Bjarne stresses the point that C++ was designed from the beginning to be a 'multiple paradigm' language. Object oriented programming was never meant to be, and is not, the only valid - holy grail - style of programming, that many make it out to be. It's quite frustrating to see features devised ten years ago still not properly supported by the current crop of compilers, templates for example (export anyone?).

The book is not for the novice programmer, but for the experienced C++ user who wants to know the whys behind the language. While a novice might be interested in that information too, it is not an advisable lecture for those readers, since they might easily get confused with the source code examples showing directions in which C++ did not evolve.

To quote one of the design goals: 'C++ is a general-purpose language designed to make programming more enjoyable for the serious programmer' - I think it succeeded.

Book review: The C++ Programming Language

You are a C++ programmer - you own this book. If you don't, buy it, buy it right now. This is the reference work on C++, written by the original creator of the language himself: Bjarne Stroustrup. Although this isn't a book for beginners the text is very readable and concise. I particularly liked the code examples he gives, because they are not of your usual 'hello world' text book quality, but rather examples taken from the real world. He also doesn't commit the crime of many authors of presenting code with remarks like this: "this is not the way you should do it, you'll learn the correct way later". Bjarne isn't the die-hard, everything must be object oriented type of guy (that is a good thing!), thus presenting the more traditional style of procedural programming first. While still taking advantage of the OO facilities of C++, like stream IO for example, he doesn't overwhelm you with the responsibility of designing proper classes from page one. In the more philosophical chapters about design and 'the importance of the individual' the author demonstrates a very rational, non-preaching point of view backed up with lots of real world experience.

No compromises, this book is a must have.

Book review: Extreme Programming Explained

Now this is a controversial book that has caused a lot of heated debate among developers. It starts out innocently enough, by stating the goals of XP which most everyone will agree on: correct, flexible software that adapts well to change in requirements and user-feedback, short development times and happy programmers and customers. It then goes on to explain how the techniques of XP try to help archive these goals. The practices include widely accepted ones, like a rigorous testing process, coding standards and continuous integration. But it also breaks quite radically with common programming wisdom by requiring things like an on-site customer, refactoring as a major component instead of a complete up-front design, pair programming (two developers sharing one keyboard and one screen) and collective code ownership (every one on the team is responsible for the whole codebase and allowed to modify every line of it). It is this mix of proven techniques taken to the extreme and new approaches presented in the book that Beck claims creates a special synergy which leads to a more successful and less strenuous software development process. The author puts forward very convincing arguments for why and how these synergetic effects occur and presents his personal experience using XP on one team as supporting anecdotal evidence. The book is written in an easily readable style and contains lots of sometimes funny anecdotes and quotes. And although it obviously is about the author's pet idea I didn't find it preaching, but rather refreshingly enthusiastic and energetic.

Unfortunately I have to admit that I haven't yet personally experienced all XP techniques in practice, main reasons being that it's very hard to convince management of it's merits ("What?! Two programmers on one keyboard?! No way!") and to get all team members willing to try something new. Maybe if they'd all read this book it would be easier...

In the unlikely event that the ideas don't intrigue you, you still have to buy this book to know what all the hype and controversy is about.

Book review: Effective C++

The subtitle of the book '50 specific ways to improve your programs and designs' is a pretty good summary of what this book is all about. It's is very well structured, the table of contents summarizes each point in one sentence, together with the extensive and complete index it's very easy to use as a quick reference. But thanks to Meyers clear and oftentimes amusing style of writing it's also a joy to read from cover to cover. You'd be a fool if you didn't anyways, since you'd miss out on lots of excellent source code examples and very well stated arguments for each of the tips. Some of the tips may seem obvious, like item 5 which reads: "use the same form in corresponding uses of new and delete". Others like item 1: "prefer const and inline to #define" might seem pretty alien to seasoned C programmers/preprocessor magicians or performance freaks. After reading the author's arguments for his points you'll have a hard time defending your position, though (in the unlikely case that you are still not convinced, that is). Meyers does explicitly encourage critical thinking over blind following of the rules though, and in the tradition of Donald Knuth has promised a reward for every error discovered in his work.

How universally accepted these tips have become you can guess form reading the C++ newsgroups or noticing that they have been fully integrated into automatic source checking tools such as gimpel's PC-Lint. Professional programmers should know these 50 gems by heart - buy the book!

Book review: Design Patterns

This book is a catalog of 23 more or less useful object oriented design patterns in more or less wide spread use. Don't get me wrong, I do like the book's intention of introducing a common vocabulary of solutions to particular engineering problems and it is certainly valuable having these solutions collected and organized in one place. However, I think it is unnecessarily dry and hard to read. The source code examples on the other hand are written in easily understandable C++ with brief mentions of existing implementations or implementation possibilities in different languages. I would have wished for more and more elaborate examples though. The authors often mention the possibility for mixing several patterns to archive their combined strengths, but seldom give code examples demonstrating this - thus leaving the harder problems to the reader. I would have liked less emphasis on the sometimes obscure and outdated 'known uses' section for each pattern - which cites where the pattern has successfully been applied - in exchange for more actual code examples. Sometimes the 'known uses' section reads like an excuse for including that particular pattern, which should be unnecessary, the use should be self evident or the pattern omitted. That said, I still haven't found a use for some of the more esoteric patterns in my everyday designs and application of C++. The book is still a valuable reference, since many patterns (factory, singleton, observer, command) really are in widespread use and you don't want to miss out on their usefulness and seem ignorant in discussions about them ;)

Book review: Code Complete

This is an outstandingly good book about software construction techniques that lead to a sound, robust product. It starts with simple things like naming conventions, function layout and commenting methods, but covers the whole software development cycle of design, programming and quality assurance. Although it gives plenty of source code examples in several different programming languages, these are always short and easy to follow even for 'language foreigners'. Source code examples are only used to illustrate more general, important points, rather than specific implementation details. The author is careful not to force his personal style on you - which would be rather foolish considering the many 'religious' issues covered (naming conventions anyone? ;) ) - but presents his opinions supported by sound arguments that'll make even skeptics reconsider. The text is an easy read compared to more technical books and is covered with lots of very amusing short stories that highlight key points.

This book will be a great aid in keeping your and your coworkers' mental health while programming in a team under a merciless deadline.

If you are at all serious about programming - buy this book!

Book review: Accelerated C++

After having read this book I very much regret coming to C++ from a self-taught Pascal and C background - it could have been so much easier. Many introductory texts on C++ assume a background in one of the procedural languages and consequently start teaching the C subset of C++ first. This is, according to the authors' experience, counterproductive to understanding 'proper' C++ and programming true to it's paradigms and design. Thus they follow the radically new approach of discussing whatever (sometimes advanced) facilities C++ offers to solve a particular problem instead of going from one isolated language feature to the next. This leads to the somewhat unorthodox chapter sequence, which teaches the design of user types (classes) after introducing template functions (a feature many seasoned C++ programmers still don't know how to use effectively) or even stranger: the explanation of pointers and arrays (chapter 10) in terms of the standard library iterators and containers, which have been introduced as early as chapter 3. What I particularly liked are the useful and real world examples, although the book does cover the omni-present 'hello world' program, it otherwise fully delivers on it's promise of teaching 'practical programming by example' (subtitle). Due to this approach and the well constructed exercises at the end of each chapter the book gets the student writing non-trivial, useful programs taking full advantage of advanced C++ library features almost from day one. The authors also lead by example and show proper commenting and programming for flexibility techniques even in the smallest code fragments. This is in refreshing contrast to many an author's crime of showing the 'quick and easy' way first and the 'proper' way later.

If you read The Design and Evolution of C++ you'll soon notice the repeated mentioning of Koenig and Moo as two of the key players in the development of the language. Their in-depth knowledge and experience really shows in this work. Although the book is mainly aimed at beginners, veteran C++ programmers can still profit from it, even if only by loosing some more bad old C habits.

Book review: The Mythical Man Month

A classic book about the development and management of large scale software projects. One of the industries veterans shares his experience and his views gathered mainly during the development process of the IBM OS/360 operating system. Yes, this book is more than 20 years old - which makes it even more interesting (or shall I even say: sad?) to see that many of the observed shortcomings and pitfalls are still the industries greatest problems today. Maybe all management and developers alike should be required to read this book prior to getting a job in the field. Although the book does feature some code examples these are few and far in between, it's main focus lies on the coordination and management aspects of software projects. The somewhat poetical title hints at one of the most stressed points, namely that men are not interchangeable and that twice as many engineers don't cut development times in half. Brooks also offers his opinions on the psychological aspects of systems design, backed up by his experience and occasional statistical evidence. This anniversary edition features a review by the author, where he sums up what points he thinks remain valid in hindsight more than twenty years later. I particularly enjoyed a beautiful chapter titled: 'The joys of the craft' where Brooks tries to explain what fascinates and captures him about programming. If you happen to be stuck on a frustrating stretch of your project - read this chapter and you'll feel better - I did.

Book review: More effective C++

This is the sequel to the excellent 'Effective C++' by the same author. It covers more advanced and less general topics than it's predecessor. While the first book gives you good programming style and techniques and points out how to use the language correctly, this one shows specific patterns and solutions to more narrowly defined problems. Examples of these include: smart pointers, proxy classes, lazy evaluation, double dispatching. The book also covers the new standard C++ features more in-depth and thus has a good treatment on exceptions and the new style of casting. Because the topics are less general than those from the previous book they are at the same time more controversial. Rules like 'make non-leaf classes abstract' are seldom followed in practice, even though Scott gives good reasons why one should. Another currently hot topic might be 'program in the future tense', which is perfectly sound at first glance, but eXtreme programming proponents might disagree and would want to word it a little less strong. The author sometimes drifts off on really esoteric tangents which seem unlikely to be relevant in the real world. Item 27 'requiring or prohibiting heap based objects' is such a chapter: while I can see that it might sometimes be useful to place such restrictions on classes the effort necessary to do so is just not worth it in my opinion. This is a case where a simple comment might be better than an overly complex class construct. Another point on the negative side is that the author has the unfortunate habit of introducing you to the wrong way of doing things first and almost convincing you of it and only then goes on to show the correct way. I dislike this from a learning psychological point of view, i.e. you should remember the correct way, not both or even worse just the wrong way.

Scott's writing is as usual clear, concise and oftentimes spiced with funny remarks. All in all a worthy sequel - buy it.

Book review: Game Architecture and Design

This book is a little unusual in that it claims to cover very technical topics while reading more like a light novel. While it was still interesting, it's of the 'read once and forget' type, i.e. I do not regularly get this book out for reference like most of my other technical books. It's biggest problem is that it tries to cover too much ground in too little space (~700 pages) - there is no way to deal with the whole process of developing a commercial quality game in a single book. As a result the author only briefly touches on many topics which would have been better left out for more in-depth coverage from other books. For example, management, architecture design, design patterns and testing each require a book for themselves, rather than a short and superficial one chapter treatment. What's left is a lot of stating the obvious (breaking news: testing is good!) and a lot of personal opinions. While the chapters on design are quite readable, by their very nature they deal with lots of 'religious' issues, and although the author tries to be careful I sometimes felt offended by his preachy tone. I sometimes got the feeling the author had a somewhat ivory-tower, disconnected from reality view on many of the topics, especially the treatment of 'software factories' sounded utopian. The book also features lots of useless diagrams and code snippets of varying quality, which are, presented in isolation, again useless. The highlights are probably the 'case-studies', small anecdotes, scattered throughout the book. In summary, the book is like the internet: an ocean of information but mostly only knee deep.

Book review: Coder to Developer

The book tries to cover the whole of the software development process from planning, team management, coding best practices and finally creating an installer and releasing the product. With such a broad range of topics each one is only treated very superfluosly and shallow. The author has a very tool centric view on things and as such many chapters are just a market overview of available software for the task at hand. I don't think this is of much use for the reader since that is exactly the kind of information you can gather in half an hour of internet research with google - and even after reading the book you'd still have to do this research anyways in order to gather current prices for the latest gadgets. All software solutions presented in the book are for windows only and Microsoft's tools seem to get extra focus and attention. The intended target audience for the book are independant developers and small software shops. As such the author assumes that you are wearing multiple hats and are filling all kinds of different roles from designer to coder to management. I very much liked this perspective on the software world because for one thing I am one such lone wolf developer and second because there are already tons of software books for the large corporate software developer. Those books typically assume loads of process and management and different departments etc which all don't apply for the single developer. Two important things missing in the book's coverage are two chapters: One for the time before concrete planning actually begins on the question of "what to develop" and determining markets. Another one for the other end of the road on how to market your software, how to price it and how to present and distribute it. If those were included I think the book would truly cover the complete process a lone developer goes through from idea to product.

All in all, the book gave me little new information but a good checklist to work through on a project.

This blog has moved

This blog is now located at http://blog.buschnick.net/. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to http://blog.buschnick.net/feeds/posts/default.

Garbage collection considered harmful

I think garbage collection is one of the biggest disservices modern programming languages brought upon us. It is touted as a silver bullet and apparently no new language can live without it. Java, Python, PHP, ActionScript, VisualBasic, C#, Ruby, ...

Why do I think garbage collection is evil?

• the problem it promises to solve isn't actually solved. You can still easily get memory leaks by building circular references or forgetting to unregister event handlers. However now these leaks are much harder to track down and fix.
• the problem of memory management, i.e. efficiently using the available memory is made tremendously harder. You give up all control over when or even if your objects get collected. There is no easy way to make use of the problem domain knowledge the programmer has and the garbage collector hasn't. If I know in advance I'll need a lot of memory the next frame it makes sense to clean up ahead of time. The garbage collector can't know this and will be caught off guard, causing performance drops. Also, how much memory is wasted for "zombie objects", that just linger around, waiting to be collected? Trying to fine tune an application's memory profile and reducing it's footprint feels like having to work blindfolded, in a straight jacket with your feet stuck in the mud.
• as far as I know no one has figured out yet how to combine garbage collection with deterministic destruction. Destructors in garbage collected languages are either non-existent or worthless because you don't get any guarantees when or if they'll execute. This kills one of the most useful programming idioms ever invented: RAII, or Resource Acquisition Is Initialization. You acquire a resource in a class' constructor and release it in the destructor. There is a well defined sequence of events and the destructor is guaranteed to be called, you cannot forget to release the resource. And before you say garbage collection makes alloc/release patterns obsolete think again. There are other resources besides memory that follow the exact same pattern with potentially catastrophic consequences if you forget to release them: file handles, network connections, vertex buffers, audio loops, database connections, database transactions, locking textures, mutexes... I'm sure you can think of more. And this is not even accounting for application specific logic like undo/redo patterns.
• this is related to the previous point about RAII. Without deterministic destructors writing exception safe code becomes very hard indeed. Instead of having all your classes clean up automatically after themselves you have to manually remember to bracket everything with try/catch/finally clauses. As a direct consequence you'll need absolute information about what code may throw exceptions and when. Knowledge that often has nothing to do with the problem at hand, is easily forgotten and is often buried under layers and layers of code. Hence Java-like crutches of requiring exception specifications for every method.
• you lose value semantics for everything but the simplest native types. There is a distinct divide between native types like int and objects. While the former are passed around by value the latter can only be passed by reference. This causes lots of confusion and ugly hacks (Java's int vs Integer) and often forces you to write less efficient code.

Contrary to popular belief memory management is not a problem in C++. In fact, in modern C++ you hardly ever allocate memory directly. I can't remember the last time I had to search for a memory leak but I do have to minimize memory usage of my programs constantly. Yes, even in times of multi gigabyte RAM machines you easily exhaust that memory when dealing with lots of concurrency or just large complex problems. Now garbage collection solves a problem I don't have (leaking memory) while making a problem I do have (using too much memory) infinitely harder to solve. And before anyone says I just haven't discovered my leaks yet - some of my stuff has to run 24/7 under heavy load, even small leaks will quickly become apparent in such a situation.

Trusting the garbage collector to solve memory issues for you is like sitting in a burning house, closing your eyes to the problem and repeating to yourself: "Everything's gonna be fine. Everything's gonna be fine." until you go up in flames. Memory leaks aren't the problem, using too much of it is.

Summary: I hate garbage collection and the sooner the world rids itself of that addiction the better.

Operation Survival Server

Being a persistent multiplayer game Operation Survival needs a server running the show in the background. My first gut reaction was to use Apache and build the game logic on top of that. There is a host of programming languages to choose from and if that wasn't enough I thought I'd just implement my own cgi or plug-in module. Use an XMLRPC API to service game client requests and we should be all set - right?

Pondering this for a while I came to the conclusion that it would be a terrible choice. To start with I don't really need an HTML server for the game, so Apache won't help all that much. Of course the game will need a website, forum and all that stuff as well, but handling the actual game logic, database persistence and interactivity has nothing whatsoever to do with HTML. Second, a regular connection to your web server is stateless and one-way. Stateless means the client needs to re-authenticate (supplying its session id or user credentials) with every request. One-way means there is no way for the server to initiate communication with the client. This is essential though! Imagine how real time updates as you'd need them for a chat would work: The client has to poll in regular (short!) intervals and ask the server for new data. Most of the time the server will just answer: "Sorry dude, no news.", creating unnecessary traffic. Now imagine a thousand clients asking the server every half second. This quickly gets out of hand.

So what I really need is a persistent two way connection where clients only authenticate once for a session and the server can send data on its own initiative. That's a socket connection or socket server.

There are several free, open source and commercial offerings in this field. Unfortunately most of them are written in Java. I really don't like Java (a rant for another day) and since the most important ingredient for success of a hobby project is motivation, working in an environment you don't enjoy constitutes a really bad start. My language of choice is C++, so I'll want to have a server written in C++.

The server will have to implement pretty much all of the game logic (never trust the client), will have to do all authentication, database connection management and socket connection management. It'll have to run 24/7, be parallelized (in order to handle multiple simultaneous connections well and take full advantage of today's hardware) and be reasonably efficient so it won't break down too quickly under load. It should be stable and resilient against the most common types of attacks (SQL injections, floods, spoofed packets, ...). It should be able to compose individual messages into larger packets in order to bundle traffic into few packets per second/per client. It should be able to gracefully deal with error states like unexpectedly disconnected clients, slow connections or garbled packets.

Since browser games must be considered a service as opposed to shrink wrapped product, programming and content creation tasks once the game is successful will be at least as important as during initial development. This means hot-patching and updating the server with new content and bug fixes should be painless and without interruptions of service. C++, being a statically compiled and linked language, isn't very good for this type of problem. However, all things considered, I still believe it to be the best choice. I hope to work around it's limitations with a very data centric design and maybe one of these entity systems that seem to be all the rage amongst game developers lately.

Tall order? Probably. Fun? Sounds like it to me ;-)

Flash, Silverlight, JavaScript, Java, Unity - oh my!

I have decided to make Operation Survival a browser game. Given my design ambitions. I think that is pretty much the only viable choice. The next thing to decide is what exact technologies to use client side. The game requires some interactive 3D graphics (the globe and the isometric tactical view) and should look and feel like a dynamic game not like a static website. My options pretty much boil down to the following:

• JavaScript: There are huge differences in performance and feature sets as implemented by the various browsers. People are still trying to figure out the best way to achieve even the most basic of tasks. It does not offer a good development environment I'd feel comfortable with. It doesn't offer the breadth of libraries other languages do and it doesn't support socket connections which will be required for client server communication.
• Java: A fully featured "real" programming language with a huge selection of libraries and development tools. However, the browser experience leaves a lot to be desired and lives a niche existence. Java applets feel slow to load, slow to display and don't integrate well in the browser. Still, there are good examples as well and Java would certainly be a viable choice.
• Unity3D: Very cool technology. The only one of the bunch supporting 3D acceleration. The development environment and content creation tools are top notch. It runs on the iPhone. Unfortunately it requires a custom plug-in thus presenting an extra hurdle. It's also not as mature as the others and the plug-in crashed my browser the first time I have tried it. It is not yet widely adopted and probably needs a big killer application to spread (what videos did for Flash).
• Silverlight: Microsoft's offering trying to go against the dominance of Flash. Best of breed development environment in the form of Visual Studio. A choice of solid programming languages like C#. Hasn't spread nearly as far as Microsoft would have hoped for. I never could get the plug-in to work with FireFox. I also doubt Microsoft's ability and willingness to really offer wide platform and browser support. They are in a conflict of interests there - support Apple (Safari, iPhone)? Google (Chrome, Android)? Linux?
• Flash: The dominant platform for rich Internet applications. Runs pretty much anywhere. Offers a decent standardized programming language with ActionScript 3.0. Unfortunately it is controlled by single company, Adobe, as well. However, I don't think Adobe is in a conflict of interests as bad as Microsoft is. There is a free command line compiler and usable free open source development IDE in the form of FlashDevelop. There are tons of libraries for graphics, user interface and even 3D. Market penetration is close to 100%. Everyone who has ever used online video from Youtube and the likes will have flash installed.
• HTML(5), WebGL, ...: Although these sound very promising and some amazing demos of their capabilities exist they are not nearly ready for prime time yet. It remains to be seen whether they'll ever reach wide spread adoption and whether they actually offer what I need. My experience from working with HTML, CSS, JavaScript (i.e. Ajax) is that you spend the majority of your time fighting the tools and limitations of the environment rather than progressing with your actual content.

Given these observations I think Flash is the right choice. Write once, deploy everywhere is a huge advantage over write once, test everywhere like you had to do with HTML and JavaScript. It does require a plug-in, but the most ubiquitous and unobtrusive of the bunch. It is closed source and controlled by a single company, but again, I think the lesser evil of the given options.

So Flash/ActionScript it is.

Next up: What's it gonna be for the server?

Operation Survival - design guidelines

One of my goals for Operation Survival is to make the barriers to entry as low as possible. This means a couple of things:

• The user shouldn't be required to install anything, the game should just run.
• There should be no platform or operating system requirements. In an ideal world it'll run on any device including PCs, smart-phones, consoles, eBooks, TVs and microwave ovens.
• There shouldn't be any user interface surprises. My grandma's poodle should be able to pick it up and play.
• The setting and genre should be somewhat familiar from other fiction. Originality is great and all, but I don't want to require the player to learn the inner logic of a wholly unfamiliar universe. I'd much rather take the real world and twist that in subtle ways. I think the cliche alien UFO conspiracy theories offer plenty of fertile ground for that.
• Sign up and payment options should be as transparent as possible. There should be an easy transition from interested visitors, just wanting to grasp what the game is all about to fully invested hardcore players spending their life in the game world.
• The game should be fully localized, no need to communicate in broken school English.
• There should be an easy and obvious way to get support and provide feedback at every point during the game.
• It should be easy for players to bond and build communities. Every effort should be made to create a newbie friendly, non-hostile environment.
• ... I have probably forgotten quite a few more.

With such an ambitious set of goals it is obviously impossible to fulfill them all equally well. There will always be trade-offs and compromises and lots of the issues are a matter of personal opinion to begin with. Nevertheless, I think it's a good idea to state some guiding principles when fleshing out the design further, so that's what I'm trying to do here.

Considering all of the above and the fact that the underlying game design is fundamentally multiplayer I believe a browser based solution is the only way to go. Browsers are ubiquitous, the back button and links the universal user interface primitives everyone on the planet understands by now. Browsers run everywhere. Everyone that uses one is already connected to the Internet and thus able to play multiplayer. Browsers shoulder the burden of guaranteeing security. Everything that runs in a browser window is assumed to be safe while downloads are seen with skepticism by even the most naive of users.

So a browser game it is.

I'll post my thoughts on the other points soon. In the meantime: What do you think about those axioms? Anything missing? How would you weight the priorities?

Operation Survival - humanity's last stand

I have a pet game idea and design lingering at the back of my head for close to 15 years now (I'm getting old I suppose). That idea was the reason for developing BlackFish, an isometric 3D engine. Back in the days we used C++ and DirectX7. Anyways, I still like the concept very much and nobody has produced the game in the meantime. So I have decided to give it another go.

If you know the old UFO XCOM series by the Gollup brothers you have a pretty good idea of what I'm aiming for. The game is a perfect blend of a base building, resource management and turn based tactical combat simulator. The premise is that the earth is under attack by aliens invading with small fleets of UFOs, performing various reconnaissance, raid or research missions - conducting nasty experiments with cows and such alien stuff ;-) The back story is not entirely original but very well done and plays expertly with real world conspiracy theories and ufology.

The game is roughly divided into three major parts:

The geoscape, a view of the whole world, floating in space like the vulnerable blue marble that she is. You choose where to build your bases in this view which affects which countries will pay you for protecting them. You also coordinate UFO intercept missions by launching your fighters after them. This part plays in real-time.

The battlescape, a 3D isometric view of tactical combat missions. After a UFO has been shot down or landed you send in your ground troops to clean up the place. The action is turn based and you coordinate up to around a dozen soldiers to find the surviving aliens and either stun and take them hostage or simply kill them. The missions are usually set in some idyllic small town with the UFO crashed in a corn field nearby. There is a strong role playing component as all your soldiers have names and individual abilities and stats.

The last part are the various resource management screens available from the geoscape view. You build out your bases with better radars, more research laboratories, better alien containment facilities, ground-to-air rocket defenses, living quarters for your soldiers and similar buildings. You also coordinate researching the found alien artifacts and interrogating kidnapped aliens. Once you understood parts of the technology you can start using and building it yourself.

In my eyes even to this day this is the greatest game ever made. The atmosphere it managed to create was just phenomenal. The genre blend worked perfectly and didn't feel tacked on or misplaced as is often the case with similar experiments. The scale was nailed wonderfully by contrasting the whole globe view with the handful of soldiers combat missions. You really felt responsible for the earth as a whole and bled with individual soldiers at the same time.

I'd like to update the original concept a bit because I believe it would make a perfect online multiplayer game. I imagine a continuously running, real time geoscape with hundreds of players. Every one manages a single base and flies intercept missions from that base. This would be a "massively" multiplayer part and allow for global events like coordinated alien attack waves which have to be fended off. The game would run in a browser and allow for very casual play sessions (during work ;-) ). You log in, play through some short aerial UFO dog fights, give some research and construction orders and log out again. Base building and research works as in most text based browser games which use real time as a resource (i.e. constructing a new laboratory takes 3 days). When you have the leisure for a longer play session you sit down to play a tactical mission. These would be turn based as in the original with some crucial changes. Most importantly they'd be multiplayer. The player who shot down the UFO "owns" it. He sends out his ground troops and may invite additional players to join him in combat. Once all players have joined the mission starts and lasts between half an hour to several hours. There is no load/save, death is permanent. This calls for careful balancing and ways to rescue dying soldiers as long as you still have some men standing but I hope to make the player really sweat for his men. There is a global ranking system with military ranks from private to general and you'll have to balance risking your top men in missions vs being overtaken by other players.

I think this design will fix lots of current multiplayer game offering shortcomings and make them work to its advantage. One is the investment of time. Current games are either very casual without any persistent state except for the high score (think connect-three flash mini games), require massive investments of time (world of warcraft) or don't allow you to invest more time when you actually want to because you have to wait around for the next event (text based browser game with real time resources like OGame). Operation survival tries to work on all of these time scales, adapting to and respecting the players busy life. Another point that really bugs me is the competitive nature of most multiplayer games. Often the player who invested the most time (grinded the most) automatically wins. Skill is a secondary issue, if at all. This leads to strong players totally dominating and exploiting new comers (farming n00bs). This again leads to lots of bad blood and grieving players and creates a high barrier to entry. Existing player protect their investment and actively discourage newbies. Operation survival has no means of direct player vs player offensive actions. All players pursue the common goal of protecting the earth. The only competitive aspect is in the various rankings and ladders. You want to be the one having the general, produce the most research, own the most resources, shoot down the most UFOs etc.

While lots of this may sound very derivative of the original UFO (and it should!) I do have lots of detailed ideas to make this work as a multiplayer game. More in the coming months...

This is a very ambitious project and will probably never see the light of day. However, it's fun aiming for the stars and working on it. My hope is that it'll eventually pick up momentum and I'll find supporters. After all, the original game was a labor of love of two guys as well. Maybe technology and productivity advances made since then allow the updated design to be realized by a small team as well? Today's expectations for browser game visuals and production values are around the level of the original UFO I'd say.

Dream big.

Book review: ActionScript for Multiplayer Games and Virtual Worlds

This book is a huge disappointment. Despite the trendy topic and the promising title it completely fails to deliver. The crucial hint is the fact that the author is a founder of Electrotank. Because of that the book has become a thinly disguised advertisement for Electrotank's server product. Nowhere in the title or on the cover flap does it hint that all examples, text and code are basically useless without the commercial Electroserver. It would have been fair to distribute the book's content as free sample programs and tutorials with the server instead of selling it as a fully priced stand alone product. The way it stands it feels like a shameless rip-off.

There are lots of major shortcomings with the content. Despite dealing with network games there is basically no treatment whatsoever of networking protocols, encryption or compression schemes, redundancy or other such "minor details" that make networking code a hard problem. Instead it is assumed that all of these things are magically dealt with by the server product. In the same vain there isn't a single example of actual server code! There is a passing mention that you'll need to write plugins to handle the server side of things but you are only presented with half the game. Now to be fair the book is about ActionScript and you don't usually write the server parts in that language, but since the server is a non trivial part of any multiplayer game it would have been fair to spend a few words on that.

The chapter on security does mention many of the important topics that plague online developers. However, it stops well short of actually offering solutions to these issues. The advice can basically be summed up as "don't trust the client!". Cross site scripting, packet injection, SQL injection, hacking the client's memory and data encryption are all mentioned in small half paragraph passages. While the problems are well stated they can at best serve as entry points for google searches and in themselves offer very little actionable advice.

Many of the code examples in the book are worthless because they show long lists of member variable assignments. I knew how to do that, thank you. The interesting part is not how to assign _x = 12; The interesting part is how that object actually synchronizes itself with the server and other clients. An apparently unimportant detail that gets skimped over because Electroserver will magically solve that for you. Similarly, some code examples which are actually useful miss the topic of the book. A* pathfinding or rendering an isometric view, while well presented, have little to do with multiplayer.

Last but not least there are the factual errors. Things like a set of equations, which, when you actually solve them, present results such as "server time = server time + offset". Huh? Or errors in diagrams where a bar chart is shown and a line supposedly marking the median (not mean, mind you) which doesn't fit any of the values.

While it is clear that the author is knowledgeable on the topic and brings a lot of experience the resulting book is unfortunately quite shallow and superficial. It also seems as if the author deals with games in quantity, not quality. This is understandable, considering he's in the business of selling a back end product and that lots of low quality games is where the flash game industry as a whole is currently at, but it's nevertheless lamentable. I personally would have hoped for someone who lives, breathes and loves games and doesn't treat them as a commodity.

Washing spoons