Lately (the past two weeks) as I built up the rapidly evolving creature called Quantum Star SE, I’ve begun to realise something very odd. You see my typical day while working on Quantum Star SE 2 was plan, develop, crush bugs. Crush more bugs. Guess what? Yep, crush even more bugs. It seemed even the slightest change upset some delicate balance leading to a myriad of small irritating bugs that were impossible to predict beforehand.

These days on QS3, the average coding period has switched to an extent from bug hunting to planning/design. In fact, I’m having problems even locating bugs – apparently none exist… Now I know this is a fallacy. Every application will eventually have its fair share of bugs – but QS3′s 100% redesign from its procedural legacy source has resulted in the elimination of all but the most minor backend bugs (bugs specific to differences in shared hosting vs my home PHP/Apache environment). QS3 makes extensive use of trigger_error() where it counts to generate errors where the expected behaviour starts to break down – that move alone is incredibly valuable, I seriously think it adds a layer of protection against unintended bugs than the default PHP fatal and warning errors would be incapable of detecting.

These days my most pressing problems in QS3 are getting the design straight. After deciding to go full hog and implement an MVC design, I now need to bring this design together into a cohesive unit. Those following such progress will already have heard this phase give rise to the Partholan Project – my long required basic web application framework (something similar to what BNT developers might call JOMPT).

Its interesting to note my development time is now largely split evenly between pure planning/design and actual coding. This is a major shift from the 10% planning, 40% coding, and 50% bug hunting that wasted huge stretches of my free development time in QS. It’s similar to getting twice the actual work done in place of unecessary bug hunting and worrying about what weird and wonderful bug will result from the next stupidly simple change…;-)

I must also confess to a certain smug feeling when I come across statements from people like Panama Jack (an AATraders developer) who after developing a major addition make statements similar to this quote from PJ:

There are a myriad of bugs and oddities that we will be crushing as we go. I am going to try and get the NEW traderoute code up and running instead of that nasty assed HACK I thought would be easy. Everyone is just going to have to suffer with manual trades for the next couple of days. I know it sucks.

We will be fixing critical bugs ASAP like a whole host of them that cropped up with the multi game option. Others will be fixed as time permits.

From my own experience in QS2, statements like these are a sure sign that the problem is less bugs in what the developer actually wrote – and likely points to the legacy code requiring a whole raft of minor changes across multiple files to support new changes. Unfortunately procedural code is difficult to track easily, especially in a situation like SE where bugs can often be layered across older bugs (i.e. even the bug fixes are buggy!) where such issues actually get accepted as “normal gameplay features”. This is one reason why I am fantastically happy to have taken an entire year off from QS development to dedicate to planning and design, and the development with Matt of something approaching a predictable and eminently adaptable framework…

Who knows – maybe one day I’ll pitch in and help create a Blacknova Traders MVC version on Partholan…

Related posts:

  1. Procedural hodge-podge vs Engine based source code