Over-patterning software design.

Ah! Design Patterns! Yes those seemingly magical concoctions of code that appear to solve all of the problems plaguing software design. So profound is the initial impact of design patterns, that the engineer begins to believe that he/she has finally found mythical scrolls of wisdom, bestowed upon him/her by divine beings, so much so that after reading through them every design problem can be automatically deconstructed into a set of familiar design patterns. Using them seems to solve every challenge software engineering has to offer — and the engineer begins to believe that all that is ever needed on his/her desk is a copy of those very patterns. Yes, there was a time when I have been guilty of the very same thing.

There is also the misconception that patterns are drop-in replacements to traditional software design practices. It’s tempting to approach a design problem with a pre-packaged solution that patterns seem to offer. “Oh, we have a Composite, that means we need a Visitor for collaboration. So let’s use a Visitor then.” That was easy, but what was missed was the overhead of designing something as a Visitor. No one asked the question why a Visitor was needed, or if  it was indeed needed. Often the only reason given for such design decisions is, “… because a design pattern says so.” That’s not what design patterns advocate at all. Excess use of design patterns while designing software, inadvertently leads to Over-engineering.

This contradicts the popular perception which is of the view that patterns were created to address most commonly occurring design problems. Yes that is true, and no I am not trying to be a design pattern heretic and declare that patterns are useless. Patterns are in fact very useful when applied correctly. It is true that most software designs can broken down into sub-designs which can be collectively solved using a combination of different design patterns. But just because they can be, doesn’t mean they have to be. A designer well versed in design pattern use can quickly find adaptable patterns for most design problems — and can probably get them to work together if he or she understands the modalities of pattern behavior.  There is a dichotomy here; design patterns lead to over-engineering — and they are useful!! What is it then?

The truth lies somewhere in-between. Most problems with “Over-patterning” begin when there is an overbearing urge on the part of a designer to adapt his/her design, and sometimes downright bend it to fit to a design pattern. Just because a pattern fits or solves a problem, doesn’t mean it has to be used. Loading a software design with patterns is a mistake. One must remember, patterns add cost, and by cost I mean engineering cost. Strange — an engineering solution adding an engineering cost? But, thats how it is with any engineering problem in any engineering domain. Ironically if you refer each pattern you will often see these costs clearly pointed out by the authors. Call them disadvantages, limitations, issues or whatever other name you come up with, but the reality is that these issues aren’t trivial. An oversight or a failure to understand the implications of these in the overall design of a software system is what leads to overly complex  or over-engineered solutions.

An excellent article to read with regards to this is Joshua Kerievsky’s Stop Over-engineering.

Direct3D 10/11 coming to Linux … What about games?

No, April 1st is still more than 6 months away, and yes you heard me right — Direct3D versions 10 and 11 are indeed coming to Linux. How is this even possible?  Well it is possible, since nouveau moved on to Gallium 3D which allows Direct3D API (actually any API) to be exposed via a front end called a state tracker. Interestingly (, and there seems to be a lot of confusion going about on public forums) Direct3D will be a Native API under Gallium, much like OpenGL is currently. It won’t be a something that emulates Direct3D by using wrappers around OpenGL — meaning you will be able to write and compile Direct3D code directly on Linux or BSD based systems that support the nouveau driver. Initially I was a bit skeptical of such an approach since Direct3D API is integrated with Win32 API, but the author seems to have solved this by using Wine headers. I don’t know the pitfalls (if any) of such an approach, but it seems to have worked for him and would seem a logical path to take (instead of breaking API compatibility). He clearly outlines the motivation behind doing the Direct3D port, and kudos to him for doing something that was but inevitable given a no show of Longs Peak.

Naturally a native Direct3D implementation will allow game developers to write code that is cross-platform and even allow existing engines/games that use Direct3D versions 10 and higher to be ported across to platforms that have a Gallium driver. W00t! This is amazing, almost too good to be true isn’t it? But before we gamers jump in joy, there are still a few things that have to fall in place before things can get up and running with regards to Direct3D on Linux. First and foremost is support. Hardware vendors like Nvidia and AMD must support Gallium in their drivers, or OSS drivers must be written (and are being written) to take their place. This is paramount since without such an interface, no front end API (Direct3D or OpenGL) will be able to use hardware acceleration via Gallium. Second, and more importantly, the guys at Redmond must allow such an implementation of their Direct3D API. An API itself can’t be copyrighted. The author seems to have steered clear of any Microsoft code, so theoretically this shouldn’t be a problem. But then again I am no legal eagle, so I can’t really say anything w.r.t. this. There have been rumors that there are patents on sections of Direct3D. I am not sure what that means, or for that matter if it is even possible to patent sections of an API/Library. But, things could get potentially messy if Microsoft were to place a cease and desist on this new development. I doubt this would happen, but you never know.

I have to agree, having Direct3D as a native API via Gallium does open up a lot of possibilities for OSS platforms that have severely lacked games. Accelerated graphics on most systems apart from Windows have had little choice up until now with OpenGL being the only real option. But does this really mean that all of the games that are developed and are being developed will be ported to Linux and other OSS platforms? That’s an interesting question and the answer isn’t quite that simple. Lets look at the macro picture of the industry. For AAA games the PC platform isn’t a priority. Most (maybe all) AAA games are today made with consoles in mind. Yes there maybe a PC port, but it’s the consoles that are the main priority. Most (if not all) gamers that play AAA games on the PC do spend a bang on their systems and most of them already have Windows as their main OS. Some do have *NIX systems but even these few have a Windows partition that they keep around specifically for games. Porting any software to a new platform isn’t a trivial task. Even with the best coding practices and methods, it requires a lot of resources — which aren’t free. Everything from coding, testing, maintaining build setups, writing install scripts and many other things requires time and money. For  a AAA game, or for that matter for any game or software, a port to a new platform should show a robust ROI (return on investment). That’s where the crux of the problem lies. There aren’t that many *NIX gamers out there, and if there are, the big studios aren’t seeing them!

Then there are the casual games, which also is a big market for games. Casual games represent a very different kind of audience. A typical casual gamer is a non technical person who doesn’t even understand what a hardware driver is, let alone jargons like Gallium, Direct3D, OpenGL or for that matter Linux. Most casual gamers will have nothing but a moderately powerful laptop with on-board Intel graphics chips — which came with Windows pre-installed. This is the kind of player that expects the game to install and run with a single click. They don’t understand driver updates or DirectX versions. For them it matters little which API is better or worse or which platform supports which API and which doesn’t. Apart form these two broad segments, there are a whole lot of players who will play radical indie games and this is probably where Linux ports has found some success. This gamer is the tech savvy computer geek who runs Linux as his/her primary system and isn’t afraid to fire up the console now and then. I must say, some radical indie games have found success in this area. But, these games are far from cutting edge. They maybe very good games, but you don’t expect Crysis like graphics from them, and it matters little what API is used or if the underlying API runs 5% slower when your game is not going below the 30FPS barrier.

There have been lots of debates about OpenGL vs Direct3D. I refrain to go into that. However, having a choice of accelerated graphics API for platforms other than Windows is definitely good all around. Direct3D versions 10 and 11 are well designed APIs, closely tied to current generation hardware. But will all this translate into more ports of games to Linux and BSDs is still an open question. The community as always will play a vital role and only time will tell how things pan out.

Into the mind of a casual gamer.

I haven’t said or ranted about gaming in quite a while now. Quite unlike me. I often have to say and rant a lot, especially about gaming. If you read the last 10 posts you would never guess I was a game developer. So I guess it’s time to put the Blog back on track! The absence of any game related post have been for a couple of reasons. For one, I haven’t installed any new games as of now. Too busy with finishing off Doofus 3D. Neither have I upgraded my old aging NVIDIA 6200 and 6600 cards. So anything new like Bioshock or Crysis is out! I have promised myself a brand new 8800 GTS or something newer as soon as I complete and ship the game, and that’s been now like, forever! On the contrary, for the past 6-8 months I have had the opportunity of actually watching others playing games and it’s been a learning experience as a game designer. You wouldn’t believe it, one of them happens to be my mother. She has been doing all the playing while I have been working my ass off to finish my game, though I must say her taste is very (very) different from mine. No Half Life-s or Oblivion-s for her, she kinda enjoys the Zuma-s and the Insaniquarium-s; casual games in general.

Just watching and being a spectator can teach you volumes about how people enjoy computer games. Casual gamers in many ways can very different from hardcore counterparts and can be very similar in other respects. A casual gamer is generally not interested in complex gameplay. They are the ones who enjoy simple yet immersive games. Simple puzzles and not overly complex challenges are ones that are favored over long story lines and dark alleys. Also appreciated are short levels. For instance, I tried selling a game called Caesar III to my mother but nope, didn’t work. For those who don’t know, Caesar III was a city building game, kinda like Sim City and I loved that game when I played it. The game has no gore, so I was pretty sure she would love it. However, the comments I got from her were, “Too complex”, “Very difficult to manage”, “Can’t understand it”. It just goes to show casual gamers tend to favour easier set of “game-rules”. Anything that is more complex than a few set of keystrokes is a big NO.

Over the past few months I observed and chatted with a few other casual gamers too. Mostly friends and relatives who often play casual games. It’s always good to understand the market mentality, especially if you are developing a product catering to them. Most casual gamers I chatted with have played 2D games, but quite a few I must say, have played 3D games. Interesting, since I am developing a 3D casual game myself. When asked if they would be interested in such a game, the overwhelming response was, Yes, to obviously a simple 3D game. Most of them said they would be very interested, but were unsure if they would like it. Some even told me they wouldn’t mind learning a few extra keys to play something like Marble Blast. So it means Doofus 3D does have a market after all, but it remains to be seen if it would indeed translates into sales.

In general I have found casual gamers dislike having to learn a lot of rules, period! Games that involve significant learning effort quickly become unpopular. So I guess games like Oblivion are out. Also not so much appreciated is, gore. There is an interesting paradox here, unexpected I must say; many casual players admitted to playing arena games like Quake III. The reason; such games was easy and fast paced. Most enjoyed it, some said the games were violent but they generally didn’t mind. None of the casual gamers I talked to knew exactly what game genres were, none cared. Most said they looked at the game cover or screenshots to decide if they would indeed play a game. 90% said they played flash games. About half said they don’t understand things like DirectX or OpenGL or h/w acceleration. Nearly all said they had only on-board graphic cards. More than half said they didn’t even know you could install separate graphics cards. More than 75% said they had and do play games on laptops.

OK, my survey is far from being completely accurate. All I have done is maybe asked a few questions to people who I have met in the past year or so. I have in no way used a proper methodical approach for the survey. However, it does give you an insight into the mind of a casual gamer. As a game developer I generally tend to forget these important lessons and sometimes do go overboard. Then, I usually drag myself back to reality!