Suspense & Decision magazine
From the Article Archives of Issue # 13
[PlayByMail.Net PBM Series]
Down at KJC Games: In search of the Holy Grail
So, what have we been up to in the past year or so, since our last article? How have things changed, if at all, and what plans do we have for the future?
For Phoenix, our flagship product, I can say that things seem to be bobbing along on an even keel. We are getting regular sign-ups, thanks to our presence of the Browser Based Games voting forums, even if we are not rapidly expanding.
I suspect that Phoenix (being text and table heavy and shiny-bauble graphics light) is somewhat seemingly impenetrable for many modern gamers, but we are finding a few old boys rediscovering us and get the occasional player who is disillusioned with rinse and repeat king of the forum table style that seem to be common amongst browser based games.
We do track sign-up and have discovered some useful points in the sign-up to paying customer process. We have identified a few places where we lose customers and possible places to modify.
Knowing where to change and sacking off everything else in order to sort it is not always sensible, simply because it has to be weighed against improving and expanding the game for the current veteran players, as well as the inevitable emergencies (The latest? - A power-cut during off-line to online syncing, causing some not-immediately-apparent data corruption). As such, we are pushing things that will, in theory, give something for veteran and potential new customers, alike.
So, what are we actually doing?
Currently, development time is being split into two areas. The first is expansion of colonisation mechanics (custom code), and the second is game engine upgrade (missions & characters). This is possible, because Phoenix has its own compiler language, which allows the GM to develop custom code that is interpreted on the fly.
For example, ReadPosition[‘thisShip’] is a function that, when called, loads into the array variable ‘thisShip’ all the relevant data appertaining to a position, dependent on the type of position loaded and WriteBasicPosition[‘thisShip’] checks that data before saving it back to the various databases. This means that the person writing this code does not need to worry about all the checks on position data, and does not need to worry about messing up the entire data structure by writing back the wrong sort of data. Basically, it is a nice functionalised library that allows for development and testing in a relatively safe environment, without the need to compile the entire game each time there is a minor change to custom code. This enables the development of order code outside the framework of the engine. The custom code is essentially a standalone plug-in to the Phoenix engine. As such, it allows the engine to be worked on, independently.
I would love to say that this does not have its issues, but unfortunately, it does. Occasionally, I will find that I need either a new function or change in how a function is handled. Recently, it was the case of Addition. 1+2=3 whereas ‘A’+’B’=’BA’ due to how variables are added to the compiler stack and removed from it. To fix the issue, the Addition functionality had to first quantise the variable into a string or number, before determining how to add and remove from a stack. While the issue has workarounds, such as setting the variable to STRING before dealing with the function, our development projections meant it was better to deal with now, and save a lot of lines of code workarounds. The best thing about this is that each time a function is either added or improved, it is there to be drawn on and used ever after. If we ever develop a new game, we have years invested in this engine and function library that is, for the most part, completely independent of the Phoenix game.
As players of Phoenix know, over the years, we have developed its online presence. This has been to my mind the thing that has ensured the future of the game. There is always more that can be added, but we feel we have reached the stage of bells and whistles, except for a few GM tools to do with mission editing. Conversely, from what I can see, those games that eschewed away from having integrated online features have died, or at least have disappeared to some murky underground that I haven’t discovered. Similarly, news groups, once the breeding ground for discussion and latest in-game news, have also dried up. Yahoo chatlists are only visited by spambots selling unnameables, as far as I can see.
With respect to mission editing, we are effectively looking to kill two birds with one stone. By pushing the mission editor, making it significantly easier for the GM to moderate and play-test missions, we will be able to expand on the number in the game, thereby appealing to both new and veteran players. The holy-grail of the mission editor is to be able to go off-mission through special actions - something that is currently not possible, due to the sheer amount of variable testing in every step of the mission.
So, over the next few months we hope to tidy away the main aspects of planetary development, covering everything from initial colonisation and establishment of governments through to terraforming both the atmosphere and planetary sectors. This, though, will be an ongoing thing, as players seek to capitalise on the greater detail given to worlds. I have always been interested in clandestine activities, such as smuggling and terrorism. To get these into the game, we will be looking at missions and characters as the main instigators of the nefarious activities.
So, all in all, we have our work cut out for us, as we continue onwards and upwards.
PhoenixBSE website: http://www.phoenixbse.com/