I was looking at the list of big-ticket/high priority items on my whiteboard, and it occurred to me that a lot of them are half done.
Not the good kind of half done, where it's a huge project and a lot of pieces are in and functional.
The bad kind of done where infrastructure is in place and working, but it's not doing anything valid in the game context.
A good example of this is the recent boat code. This largely works, and probably only needs a couple of hours to get it in god-level beta test. Instead, it's sitting there in the code base, largely complete but unconnected.
How about clan wars? I spent time adding a lot of infrastructure for this, then never hooked it up. It also probably doesn't need more than a few hours to get it in beta test.
Classes are a bigger picture. I have more structure reworks to do, but I have been avoiding them. This one is a bit more understandable, because the project is so large - but this isn't exactly a huge piece of the puzzle.
Part of the reason for this is because I'm constantly 'firefighting' instead of doing new development. I'm always fixing minor bugs, heading off social/political issues, trying to manage things and people. I'm starting to think it would perhaps be better for all involved if I simply stayed invisible most of the time. I used to do that a lot, for exactly this reason, but for some reason fell out of the habit.
Another part of the reason is that the detail work isn't any fun. It's painstaking and precise, and there's always negative feedback from players to look forward to. Nevertheless, leaving a heap of half-finished projects on the queue isn't helping anything either.
No pain no gain, perhaps.
Sunday, November 22, 2009
Friday, November 20, 2009
Halloween Havoc
I finally got the event report up for Halloween Havoc! You can see the report on the Alter Aeon System Events page.
This event was special for me in that nearly all of it was run by, well, not me. I was present for some of it, but I actually got to log in and play a mortal for a while. For the most dangerous (in terms of administration) part, the pk arena, Morpheus handled it, with some help from the gods Taran and Draak.
This is a very good thing, and it should teach me a lesson: delegate. We have gods that are capable of running, handling, and managing system events. Let them do it.
I like this plan.
There are also plans for thanksgiving and christmas-time events in the near future.
This event was special for me in that nearly all of it was run by, well, not me. I was present for some of it, but I actually got to log in and play a mortal for a while. For the most dangerous (in terms of administration) part, the pk arena, Morpheus handled it, with some help from the gods Taran and Draak.
This is a very good thing, and it should teach me a lesson: delegate. We have gods that are capable of running, handling, and managing system events. Let them do it.
I like this plan.
There are also plans for thanksgiving and christmas-time events in the near future.
Tuesday, November 17, 2009
Web Page Updates
Yesterday, I spent far too much time working on changes to the Alter Aeon web site. I spent some time hacking down the menu so that there were fewer items that are better organized; I also managed to switch over the layout to a more standard looking block based design. Along with this came a number of other minor updates and improvements.
It never ceases to amaze me that you can work on a web site, get to the point where you've done the best you can, then come back a month later and improve it even more. For me, it's like my creativity is tapped out - I have to take a break to let new ideas percolate in. I think part of it might also be that I have to get used to a new design or layout before I can compare it against something else.
Regardless, of the half dozen or so people I asked, their opinions were an almost universal 'much better' for the new version. Here's to hoping that this 'much better' translates into a higher conversion into newbies!
For a look at the new layout, here's a link to the Alter Aeon Web Site.
It never ceases to amaze me that you can work on a web site, get to the point where you've done the best you can, then come back a month later and improve it even more. For me, it's like my creativity is tapped out - I have to take a break to let new ideas percolate in. I think part of it might also be that I have to get used to a new design or layout before I can compare it against something else.
Regardless, of the half dozen or so people I asked, their opinions were an almost universal 'much better' for the new version. Here's to hoping that this 'much better' translates into a higher conversion into newbies!
For a look at the new layout, here's a link to the Alter Aeon Web Site.
Tuesday, November 10, 2009
Software Reuse
There is an old saying in the nootropic (mental-performance enhancing drug) community:
"The guys in the 60's had this truly brilliant idea of using drugs to expand conciousness and improve thinking. Unfortunately, all they had at the time was LSD." [Just to ensure proper context, this is said without sarcasm. It really was a good idea, however LSD turned out to be a complete flop in achieving this goal.]
I've recently been doing some work that involved C++ templates, so allow me to reword this for modern usage:
"The c++ guys in the 90's had this truly brilliant idea of direct language support for generic code and module reuse. Unfortunately, all they had at the time was c++ templates."
"The guys in the 60's had this truly brilliant idea of using drugs to expand conciousness and improve thinking. Unfortunately, all they had at the time was LSD." [Just to ensure proper context, this is said without sarcasm. It really was a good idea, however LSD turned out to be a complete flop in achieving this goal.]
I've recently been doing some work that involved C++ templates, so allow me to reword this for modern usage:
"The c++ guys in the 90's had this truly brilliant idea of direct language support for generic code and module reuse. Unfortunately, all they had at the time was c++ templates."
Saturday, November 7, 2009
Sailing the seven seas
As a side effect of the ongoing mapping and world linearization project, I had a strange idea: why can't I hop in a boat and sail from the mainland to the islands?
The short answer is that in most muds, rooms have no absolute position data. Since this is no longer true for Alter Aeon, having long-distance boats suddenly seemed possible. So, I set aside a short period of time to do it.
It was nowhere near enough.
As a first step, I created boats and allowed some lookup of position to figure out where I could place them. This worked reasonably well.
For the second step, built a quick lookup function to go from boat position back to nearest room. This allows people to disembark.
Next, I had planned to simply use that lookup function to build maps, so that sailing around would have a functional map display. We can also use the map generator to construct blind descriptions, so that blind players can still see when land is near. This is where the problems began.
While we do in fact have positional data for rooms, the reverse lookup is quite a bit less trivial. In order to build maps, the lookup has to be quick and efficient. To complicate matters, the world grid moves around dynamically the rebuild time has to be short as well. There are also difficulties with a single room appearing in multiple places, and with multiple rooms vying for the same space.
I initially tried a rather complex space partitioning scheme, but after sleeping on it I realized I should just use a hash table. I implemented the various hash table routines in about an hour, and with around 3 hours total I have most of the corner cases cleaned up in the map.
Next, I pull up the anchors and see about doing some exploring.
The short answer is that in most muds, rooms have no absolute position data. Since this is no longer true for Alter Aeon, having long-distance boats suddenly seemed possible. So, I set aside a short period of time to do it.
It was nowhere near enough.
As a first step, I created boats and allowed some lookup of position to figure out where I could place them. This worked reasonably well.
For the second step, built a quick lookup function to go from boat position back to nearest room. This allows people to disembark.
Next, I had planned to simply use that lookup function to build maps, so that sailing around would have a functional map display. We can also use the map generator to construct blind descriptions, so that blind players can still see when land is near. This is where the problems began.
While we do in fact have positional data for rooms, the reverse lookup is quite a bit less trivial. In order to build maps, the lookup has to be quick and efficient. To complicate matters, the world grid moves around dynamically the rebuild time has to be short as well. There are also difficulties with a single room appearing in multiple places, and with multiple rooms vying for the same space.
I initially tried a rather complex space partitioning scheme, but after sleeping on it I realized I should just use a hash table. I implemented the various hash table routines in about an hour, and with around 3 hours total I have most of the corner cases cleaned up in the map.
Next, I pull up the anchors and see about doing some exploring.
Tuesday, October 20, 2009
Software Complexity Crisis
[This rather large post is almost entirely a personal rant. I complain a lot about wxWidgets in here, because it's fresh in my mind and a very good example of a specific type of software engineering crisis. Note that I'm still using the WX libraries for the Alter Aeon client project; clearly it has value to me in spite of its faults, and I appreciate the effort the WX team has put it. That said, if I could easily move to any another library that met my constraints, I would do it in a heartbeat.]
Various recent attempts on my part to use large software libraries have made me re-examine the issue of the general software-engineering crisis. I've run up against typical software crisis problems many times in the past, so I tend to keep my eyes open when I see material related to the topic. This is one of the reasons that Vernor Vinge's book "A deepness in the sky" caught my attention.
One of the basic premises of this book is that complexity failure can be sufficient to bring down entire societies. This was put very succinctly in a blog posting by Jeremy Bowers on his iRi Blog, part of which I quote here:
"One of the less well known concepts which informs his sci-fi writings is one possible fate of societies that do not or can not end in a "singularity", which is the eventual unavoidable collapse of the society in a cascading failure state brought on by excessive, uncontrollable complexity in the ever-more-sophisticated systems that drive the society. In this case, take "system" in the broad sense, including not just software, but business practices, government, and societal mores. A failure occurs somewhere, which brings down something else, which brings down two other something elses, and perhaps quite literally in the blink of an eye, you are faced with a growing complex of problems beyond the ability of any one human to understand or contain."
This relates to software in that I'm beginning to see more and more examples of how this can occur. Two software platforms in particular come to mind - IBM's WebSphere, which I was peripherally involved with a decade ago, and wxWidgets, which I am involved with today.
Both of these platforms are very complex. Both form an abstraction layer which builds on top of other layers - in the case of wxWidgets, there is a huge amount of API reuse from the lower layers of Windows, or GTK, or X, depending on which configuration it's built for. Each of these layers is built upon other layers, and other layers, sometimes with very deep call trees.
The most egregrious example of this kind of layering that I can recall was in WebSphere. A friend had asked me to take a look at a stack trace from a WebSphere crash; somewhere deep in Java land, a 'null object exception' had been thrown. (Thank god it wasn't a NULL pointer, that would have been much worse!) The exception handler that caught it was basically the main loop, because apparently no other layer could be bothered to check for failure conditions along the way.
There were over 160 stack frames to walk through. Not one of them was due to a recursive algorithm or function. I don't know about you, but that level of stack depth is quite frankly beyond my ability to manage or debug. I don't care what it does.
WxWidgets is clearly beginning to show stress of its own, of a different character: it's becoming more and more impossible to guarantee consistency across platforms. The WX guys have made tremendous progress in this regard, so that most of the core features work right, but there are simply too many details to keep track of and too many paths that will never be tested.
Here's a couple of examples of this, one of which I'm STILL fighting:
-------------------------------------------
When I first started switching the Alter Aeon client project over to WX, I initially used the wxTextCtrl class, which is built out of Microsoft system libraries in the Win32 world, or built on the GTK libraries in my development environment. I had hoped to use the class for both the input window, and for the main display; with a small amount of effort, I got the client running and working, but there were minor, very persistent issues.
The first of these was the input window. Various events, such as backspacing when empty, cause a system beep/bell under windows. They don't cause a bell under Linux. And further, there's no way to disable this. I don't know about you, but I'll be damned if I'm going to ship a product that beeps every time someone hits backspace.
I managed to take care of some of this by trapping out various keystrokes in the CHAR handler. It seemed like a poor hack at the time, but at least it helped. However it didn't help enough; a number of keystrokes simply don't generate CHAR events, yet they still fucking beep. I finally ended up writing a raw keyboard event handler, which tracks nearly all of the keyboard state, to trap out events that would generate a beep when passed to the lower layer. In the time it took me to disable beeping, I could have written and debugged a keyboard handler from scratch, with exactly the desired behaviour.
While beeping has largely been taken care of, other issues with this so-called standard class have not. The biggest one is that the color of text displayed in the class returns to black occasionally, and depending on the versions of the system DLLs for the particular Windows installation. My first attempts at fixing this were effective on all my development environments, but failed on about half of the release environments - text typed in the window would occasionally simply vanish.
By adding forced color setting in various places where it shouldn't be needed, I eventually managed to fix this problem for about 90% of my users. Out of sheer disgust at this point, I did some extremely vicious forced color setting in various event handlers, and this appears to have fixed 'most' of the problem. I still am receiving sporadic reports of it happening on current client builds, but at least the problem goes away now and seems to be triggered at random.
When attempting to use this same class for the main window display, I ran into what seemed to be minor issues regarding the scroll bars and scrolling of text in the window. No matter what I tried, I never did find a way to get reliable scroll positioning for this class across all platforms.
After fighting this off and on for several months, I became desperate. I finally wrote my own text display class from the ground up, using nothing more than bitmaps and font drawing routines. The total from-scratch implementation time was less than the time I had previously wasted trying to get the scrollbars to work properly. It's also faster, especially for very large data sets.
-------------------------------------------
This, my friends, is the software engineering crisis in action. Each layer, while hiding some of the problems of the lower layers, introduces its own; the overall result is a system with fewer catastrophic issues, but exponentially more minor issues.
Those minor issues are surely tolerable, are they not? To an extent, yes - but at what point do you die the death of a thousand cuts?
Catastrophic issues might be catastrophic and obvious failures, but that's one of the best things about them: they're catastrophic and obvious. They HAVE to be fixed. They must be understood, they must be cleaned up and dealt with. The minor problems on the other hand, can just keep accumulating. They just keep getting worse, they just keep getting more obscure, more complicated, more difficult to find and rectify. And worse, they compound each other.
In a good scenario over the long term, they become so prevalent that the system no longer becomes usable. In a bad scenario, the system becomes critical and unmaintainable. It's a swiss cheese of buggy modules and misunderstood patches.
Is that really what you want to build critical infrastructure out of? Is this where we're headed? I certainly hope not.
Various recent attempts on my part to use large software libraries have made me re-examine the issue of the general software-engineering crisis. I've run up against typical software crisis problems many times in the past, so I tend to keep my eyes open when I see material related to the topic. This is one of the reasons that Vernor Vinge's book "A deepness in the sky" caught my attention.
One of the basic premises of this book is that complexity failure can be sufficient to bring down entire societies. This was put very succinctly in a blog posting by Jeremy Bowers on his iRi Blog, part of which I quote here:
"One of the less well known concepts which informs his sci-fi writings is one possible fate of societies that do not or can not end in a "singularity", which is the eventual unavoidable collapse of the society in a cascading failure state brought on by excessive, uncontrollable complexity in the ever-more-sophisticated systems that drive the society. In this case, take "system" in the broad sense, including not just software, but business practices, government, and societal mores. A failure occurs somewhere, which brings down something else, which brings down two other something elses, and perhaps quite literally in the blink of an eye, you are faced with a growing complex of problems beyond the ability of any one human to understand or contain."
This relates to software in that I'm beginning to see more and more examples of how this can occur. Two software platforms in particular come to mind - IBM's WebSphere, which I was peripherally involved with a decade ago, and wxWidgets, which I am involved with today.
Both of these platforms are very complex. Both form an abstraction layer which builds on top of other layers - in the case of wxWidgets, there is a huge amount of API reuse from the lower layers of Windows, or GTK, or X, depending on which configuration it's built for. Each of these layers is built upon other layers, and other layers, sometimes with very deep call trees.
The most egregrious example of this kind of layering that I can recall was in WebSphere. A friend had asked me to take a look at a stack trace from a WebSphere crash; somewhere deep in Java land, a 'null object exception' had been thrown. (Thank god it wasn't a NULL pointer, that would have been much worse!) The exception handler that caught it was basically the main loop, because apparently no other layer could be bothered to check for failure conditions along the way.
There were over 160 stack frames to walk through. Not one of them was due to a recursive algorithm or function. I don't know about you, but that level of stack depth is quite frankly beyond my ability to manage or debug. I don't care what it does.
WxWidgets is clearly beginning to show stress of its own, of a different character: it's becoming more and more impossible to guarantee consistency across platforms. The WX guys have made tremendous progress in this regard, so that most of the core features work right, but there are simply too many details to keep track of and too many paths that will never be tested.
Here's a couple of examples of this, one of which I'm STILL fighting:
-------------------------------------------
When I first started switching the Alter Aeon client project over to WX, I initially used the wxTextCtrl class, which is built out of Microsoft system libraries in the Win32 world, or built on the GTK libraries in my development environment. I had hoped to use the class for both the input window, and for the main display; with a small amount of effort, I got the client running and working, but there were minor, very persistent issues.
The first of these was the input window. Various events, such as backspacing when empty, cause a system beep/bell under windows. They don't cause a bell under Linux. And further, there's no way to disable this. I don't know about you, but I'll be damned if I'm going to ship a product that beeps every time someone hits backspace.
I managed to take care of some of this by trapping out various keystrokes in the CHAR handler. It seemed like a poor hack at the time, but at least it helped. However it didn't help enough; a number of keystrokes simply don't generate CHAR events, yet they still fucking beep. I finally ended up writing a raw keyboard event handler, which tracks nearly all of the keyboard state, to trap out events that would generate a beep when passed to the lower layer. In the time it took me to disable beeping, I could have written and debugged a keyboard handler from scratch, with exactly the desired behaviour.
While beeping has largely been taken care of, other issues with this so-called standard class have not. The biggest one is that the color of text displayed in the class returns to black occasionally, and depending on the versions of the system DLLs for the particular Windows installation. My first attempts at fixing this were effective on all my development environments, but failed on about half of the release environments - text typed in the window would occasionally simply vanish.
By adding forced color setting in various places where it shouldn't be needed, I eventually managed to fix this problem for about 90% of my users. Out of sheer disgust at this point, I did some extremely vicious forced color setting in various event handlers, and this appears to have fixed 'most' of the problem. I still am receiving sporadic reports of it happening on current client builds, but at least the problem goes away now and seems to be triggered at random.
When attempting to use this same class for the main window display, I ran into what seemed to be minor issues regarding the scroll bars and scrolling of text in the window. No matter what I tried, I never did find a way to get reliable scroll positioning for this class across all platforms.
After fighting this off and on for several months, I became desperate. I finally wrote my own text display class from the ground up, using nothing more than bitmaps and font drawing routines. The total from-scratch implementation time was less than the time I had previously wasted trying to get the scrollbars to work properly. It's also faster, especially for very large data sets.
-------------------------------------------
This, my friends, is the software engineering crisis in action. Each layer, while hiding some of the problems of the lower layers, introduces its own; the overall result is a system with fewer catastrophic issues, but exponentially more minor issues.
Those minor issues are surely tolerable, are they not? To an extent, yes - but at what point do you die the death of a thousand cuts?
Catastrophic issues might be catastrophic and obvious failures, but that's one of the best things about them: they're catastrophic and obvious. They HAVE to be fixed. They must be understood, they must be cleaned up and dealt with. The minor problems on the other hand, can just keep accumulating. They just keep getting worse, they just keep getting more obscure, more complicated, more difficult to find and rectify. And worse, they compound each other.
In a good scenario over the long term, they become so prevalent that the system no longer becomes usable. In a bad scenario, the system becomes critical and unmaintainable. It's a swiss cheese of buggy modules and misunderstood patches.
Is that really what you want to build critical infrastructure out of? Is this where we're headed? I certainly hope not.
Sunday, October 11, 2009
DClient 0.982 Released!
After a lot of hard work, intermediate releases, bug reports and beta testing, the latest version of the Alter Aeon game client is now available! It's only been about a month since the last release, but the number of updates and new features is pretty impressive. Here's some of the major things that have been updated:
In addition, there's been a pile of minor bug fixes, as well as a lot of work to clean up and improve the interface. You might also notice things like removal of scrollbars and word wrap on popup windows that don't need them, fewer buttons to be confusing for newbies, and improvements in the input text bar. Here are some examples of a couple of possible configurations:
The basic theme support and the overall interface cleanup should help us a lot with new players. The first 30 seconds of pretty buys you the next 30 seconds, etc. It seems to take forever, but incremental improvements do really add up over time.
Again, the download is at http://www.dentinmud.org/AlterAeon.exe. Snag a copy and check it out!
- Grouping status bars added.
- A new version of 'left hand layout' is now available.
- Added basic support for color themes and backgrounds.
- Side buttons now use the same color scheme and format as popup and function key buttons.
- (For builders) 'connect' command allows connecting to arbitrary ports.
- Redraw flicker reduced in popup windows.
- Add support for GMUD color scheme.
- Smoother scrolling for the automap.
In addition, there's been a pile of minor bug fixes, as well as a lot of work to clean up and improve the interface. You might also notice things like removal of scrollbars and word wrap on popup windows that don't need them, fewer buttons to be confusing for newbies, and improvements in the input text bar. Here are some examples of a couple of possible configurations:
The basic theme support and the overall interface cleanup should help us a lot with new players. The first 30 seconds of pretty buys you the next 30 seconds, etc. It seems to take forever, but incremental improvements do really add up over time.
Again, the download is at http://www.dentinmud.org/AlterAeon.exe. Snag a copy and check it out!
Subscribe to:
Posts (Atom)
