2010-07-27

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.

2010-06-07

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?

2010-05-30

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.

2010-03-23

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.

2010-02-23

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.

2010-02-10

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 ;-)

2010-02-01

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?

2010-01-25

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?

2010-01-24

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.

2010-01-16

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.

2009-09-30

id software is at it again

Siggraph paper about their new texturing algorithm. Way cool. Now that engines are almost up to rendering every last blade of grass and every pore of my skin the question becomes: who's gonna model/paint all of that? Reconstruct reality? I predict an interesting future for a blend of procedurally generated content and real 3D data acquisition. Play games on google earth or the procedurally generated Fuel? Mix! Augmented reality! Fun ;-)

2009-06-14

Battle at Kruger

Action, Thrill, Supsense - and all without special effects.

2009-05-21

Dabbling with Flash/ActionScript

For a couple of years now I have the outlines of a webgame design lying around. Working title "Operation Survival - humanities last stand". It's supposed to be a persistent multiplayer online game involving tactical fighting to defend the earth from alien invasion. It's a bit more involved, but I won't go into that right now. Anyways, I have been playing with various implementation ideas and wanted to show you one that ultimately got discarded.

The idea was to have an animated battle in space with two motherships facing each other and launching fighters/rockets/lasers at each other. Controls are indirect, with the player specifying target types (mothership or enemy fighters) and the AI duelling it out. Fighters have flocking behaviour to fly in formation.

The game design calls for something more "down to earth" so to speak, so while this prototype might eventually have become fun it's not suited for this particular game vision.

If you wanna play with it go here [2025 update: SWF has long since died ;-/]. Launch some fighters by clicking on the round brown mothership targetting icons in the lower left (the energy bars were meant as an auto retreat threshold - once a fighter's energy drops below that value it tries to escape back to the mothership). The white fighter type will follow your mousecursor around to test the flocking algorithm.

2009-05-12

Zugspitze Hike

We went hiking on the Zugspitze 2 weeks ago. Richy put some fotos online here: http://picasaweb.google.com/Greadle/20090501Alpen?authkey=Gv1sRgCOm17tzJ-ITSYA# We went through the Höllentalschlucht which was still officially closed due to large amounts of snow and ice and bridges still being taken out for the winter.

2009-05-02

OGame

I have started playing OGame a couple of days ago. Apparently it's one of the biggest browser games with around 2.000.000 players. It's a bit dull so far but maybe we can make it interesting - join me in universe 57. I'm already thinking of ways to automate it, a habit which got me kicked out of the last browser game I've tried - my AI was getting too good too fast and the admins took note ;-) Anyways, either we'll have fun playing or we start an AI war...

2009-04-27

Average US home has more television sets than people...

The average American home now has more television sets than people. That threshold was crossed within the past two years, according to Nielsen Media Research. There are 2.73 TV sets in the typical home and 2.55 people, the researchers said.

In the average home, a television set is turned on for more than a third of the day — eight hours, 14 minutes, Nielsen said. That's an hour more than it was a decade ago. Most of that extra TV viewing is coming outside of prime time, where TVs are on only four minutes more than they were 10 years ago.

The average person watches four hours, 35 minutes of television each day, Nielsen said.

One new Nielsen finding — that young people aged 12 to 17 watched 3% more television during the season that ended in May than they had the previous year — is a particular relief to TV network executives.

For a few years, Nielsen had been finding that TV viewing among teenagers was flat or even declining, a trend blamed on the Internet or the popularity of electronic games and other devices.

Numbers from 2006 - I can only assume it has gotten worse in the meantime. Ouch!

2009-02-24

I hate Vista!

Argh. The law of leaky abstractions at work. In a misguided attempt at making user's life easier Microsoft introduced aliases for "c:/program files" and other critical windows folders in Vista. This way localized versions of windows (e.g. "c:/programme" ) should be able to deal with badly written programs that have the install destination hardcoded and don't account for regional naming differences. It's an ugly hack to fix an ugly problem. However, the frickin fix doesn't even work. And when it fails it fails badly. I currently have a program I can neither uninstall nor reinstall (it's installer silently fails and rolls back). Worse: it isn't even possible to delete it manually. I can delete it from c:/programme but if I then copy a fresh install to the previous location I get a "cannot overwrite c:/program files/bla" error. Ok, try to do it with administrator privilidges in Safe mode: no deal! The fucking thing is undeletable.

Now the best thing is that the program we are talking about is Mozy - my backup solution. It installs a service, a shell extension and a file system monitor. Things that are often characteristic for malware. I had tried Microsoft OneCare as an antivirus solution some weeks ago and that decided to interfere with mozy. Now although I have long since uninstalled OneCare mozy is still crippled - hence my rant above. Even better - OneCare cannot simply be installed like any normal piece of software, no, it forces you to uninstall any other AntiVir solution you may have already had and to top it of: you actually need to download a removal tool (!!!) in order to get rid of it again. This is fucking ridiculous. If it wasn't for Visual Studio, which is great and which I am using on a daily basis, this would have been the final straw for my emigration to linux.

So fuck you Microsoft for providing me the disservice of this hidden "convenience" folder aliasing Anti-Feature.

2009-01-13

"Verschrottungsprämie"

Armes Deutschland. Pro Kind 100 Euro, pro Auto 2500 Euro. Wenn das eine Investition in die Zukunft sein soll will ich in dieser Zukunft nicht leben. Sagt doch einiges aus über die gesellschaftliche Wertschätzung - des Deutschen liebstes Kind - sein Auto.

Herdentrieb hat schon recht:

Was soll zudem dieser Fokus auf die Autoindustrie? Warum überlässt man nicht den Verbrauchern, wie sie ihr Geld ausgeben? Der Markt für Autos ist im Grunde gesättigt – wir brauchen sicher andere Autos als bisher, aber ganz sicher nicht mehr so viele wie in den vergangenen Jahren. Nehmen wir einmal an, dass jeder, der einen Führerschein hat und fahren kann, auch ein Auto besitzt. Das kommt bei 41,2 Mio. zugelassenen PKWs etwa hin. Bei einem Durchschnittsalter des Bestands von acht Jahren ergibt sich eine durchschnittliche Lebensdauer der Autos von rund 16 Jahren, was wiederum bedeutet, dass der jährliche Ersatzbedarf ein sechzehntel von 41,2 Mio. beträgt: Das sind im Gleichgewicht 2,6 Mio. neue Autos pro Jahr. Da deren Haltbarkeit ständig zunimmt, dürfte die Zahl in Wirklichkeit sogar noch niedriger sein. Warum sollte es eine Katastrophe sein, wenn sich die Neuzulassungen auf diesem Niveau einpendeln. Im Jahr 2007 waren es noch 3,15 Mio.

Abgesehen davon, dass jede andere Branche berechtigterweise eine ähnliche Förderung ihrer Produktion verlangen könnte, macht es aus ökologischen Gründen keinen Sinn, die Leute zum Autofahren zu animieren. Sollte das Konjunkturpaket nicht auch eine Umweltkomponente haben? Ich plädiere erneut dafür, die Mehrwertsteuer für einen Zeitraum von drei Jahren um drei Punkte zu senken, damit die Kaufkraft der Haushalte wirksam gestärkt wird, und im Gegenzug die Steuern auf den Energieverbrauch dauerhaft zu erhöhen, mit einem Nettoeffekt von 15 Mrd. Euro für die ersten drei Jahre: Die Umwelt würde sich freuen und die Abhängigkeit von Energieimporten würde sinken, abgesehen von dem kräftigen allgemeinen Nachfrageschub, den die steuerliche Nettoentlastung auslösen dürfte.

2008-09-21

Ninja Peas

I have participated in one of the game prototyping challenges over at DanC's Lostgarden. The game (I'd rather call it a toy) is about peas thinking they are ninjas. They climb up blocks you place for them and jump from the highest points they can reach. If they survive they'll score points for every bounce - the higher the fall better. For detailed game rules and all the elite ninja moves the peas can do visit Dan's description of the game design.

Keys:

  • ESC quits the game
  • Space spawns peas
  • Left mouse places a block
  • Right mouse deletes a block
  • Mousewheel or arrow keys cycle through available block types

That's about it.

Full source is included. Depends on a couple of external libraries. Do whatever you want with it - would be cool to send an email my way telling me whether it was useful.

There are a couple of known bugs, mainly that some impacts don't register properly, peas can get stuck when "overbuilt" and that peas will sometimes float through blocks until they are back on course. It's fully playable though and all basic game mechanics work as intended.

2008-06-26

Wanna go for a swim?

An article about plastic pollution in our oceans.

Except for the small amount that’s been incinerated—and it’s a very small amount—every bit of plastic ever made still exists.

Seriously scary stuff. Why do we wrap candy in packaging that'll survive the product and it's consumer by hundreds of years?

2008-04-13

Stephen King on video game violence

Stephen King on video game violence:

Could Massachusetts legislators find better ways to watch out for the kiddies? Man, I sure hope so, because there's a lot more to America's culture of violence than Resident Evil 4.

What really makes me insane is how eager politicians are to use the pop culture — not just videogames but TV, movies, even Harry Potter — as a whipping boy. It's easy for them, even sort of fun, because the pop-cult always hollers nice and loud. Also, it allows legislators to ignore the elephants in the living room. Elephant One is the ever-deepening divide between the haves and have-nots in this country, a situation guys like Fiddy and Snoop have been indirectly rapping about for years. Elephant Two is America's almost pathological love of guns. It was too easy for critics to claim — falsely, it turned out — that Cho Seung-Hui (the Virginia Tech killer) was a fan of Counter-Strike; I just wish to God that legislators were as eager to point out that this nutball had no problem obtaining a 9mm semiautomatic handgun.

2007-07-14

Virtual Architecture

While reading the The Phaidon Atlas of Contemporary World Architecture. Comprehensive Edition (with a weight of 8kg the heaviest book I own ;-) ) I thought it would be a real shame if all our virtual architecture, i.e. computer game levels, especially 3D maps and buildings, will be lost forever once the corresponding games cease to work on new hardware. Alas, this being the internet, someone has thought of this before. I for one would like to see a museum of computer game architecture. Think of the floating in space jump pad levels of Quake3, the organic "in an alien body" maps of System Shock 2 or the rotating maps of Unreal Tournament. Or the more realistic maps of the various World War 2 games or Halflife. Not to mention the online worlds in World of Warcraft, Second Life or the Sims. There are tons of very creative examples like this. Would be a shame to lose all that creativity. Architecture is architecture after all. The virtual kind may have different constraints and trade-offs than the real world one, but just like the real thing it's a mix of art and craft.

Either that or I'm just nostalgic for countless lost hours sank into self made levels for DooM 2, Duke Nuke'em and Quake 3.

2007-04-07

Never buy anthing that says Sony on it ever again...

Argh! There is lots of bad stuff to say about Sony, like it distributing rootkits for the good of the customer, but this time it's personal. I was dumb enough to buy a portable minidisc player (before all the mp3 players came out). The hardware is kinda ok, but the software must be the most hideously rotten piece of fucked up shit ever let lose on humankind. Of course it's your only option to use with the hardware. Of course it's windows only. Of course it has to scan all your drives in order to "register" your music. Naturally it only writes Sony native formats. Of course it doesn't read ogg vorbis. Of course it crashes about once a minute. For updating it you can of course be expected to install Internet Explorer (Sony's page doesn't like FireFox) and restart your computer about 500 times. Also, a simple download cannot be done without ActiveX and Flash activated. etc etc... It's just unbelievable that they should get away with it. Die Sony! Die, die, die!

Go Apple go! Drive em into the ground.

2007-03-28

Not Not Start a Startup? Not?

"If you took a nap in your office in a big company, it would seem unprofessional. But if you're starting a startup and you fall asleep in the middle of the day, your cofounders will just assume you were tired."

Paul Graham in his latest essay "Why to Not Not Start a Startup"

2007-03-20

BinNavi in action

Although I've written large chunks of this software I'm not a typical user of it (i.e. I'm usually producing my own bugs instead of taking someone else's apart in binary code). All the more interesting to see what kind of (freaky I might add) stuff folks pull off with it. Ero published a nice article where he shows some debugging work, stringing together a PE executable with a hex editor of all things!

2007-03-11

Beauty in the Asphalt Age

A couple of "human flowers" - highway interchanges viewed from above. The last one is from the movie "Alpha Dog". More in the "Museum of Ridiculous Highway Design". Apparently abominations like these are but a small sacrifice for "personal freedom"...