Today, I ran what I call a 'system event', which is basically a special event put together by a god to entertain players. I've been trying to do one of these a month, but I almost forgot this one completely - I was only reminded of it a few days ago, and had to throw something together quickly. Fortunately, I have an excellent girlfriend who doesn't mud. As a non-mudder, she is unpolluted by ideas of what can and cannot be done.
This clearly needed to be a thanksgiving themed event; but what to do for it? A turkey hunt is a staple part of thanksgiving events in general, but I wanted to add other things too. She started proposing oddball stuff from real life. And I started thinking about how to implement it.
So, for this event, we had a pie throwing contest (using the throw skill), as well as a turkey carving contest (using the butcher skill.) I had to make some minor code changes to get butcher to work properly on non-corpses and to allow me to construct butcherable food, but beyond that pretty much everything worked right out of the gate.
Running the event itself was as usual, hectic. It always takes at least fifteen minutes to get into the groove and get the aliases set up that you'll need to manage things properly. In this case, with three different things going on, it ended up being more work than I expected, but it still went off with only minor hitches.
Anyway, the real reason for this post is to talk about code support for such things. Special events by their very nature are hard to anticipate code for; it's also important not to sacrifice the normal operation of the game by changing the code just for the event. But I do have to say that compared to previous events, this one was pretty easy to run. Simply by running them periodically, I'll both get better at it and I'll feel the need to add commands that make it easier to run them in the future.
Creating a web page for the final event prizes and information is definitely becoming easier, though honestly the content in those pages doesn't exactly require a lot of mental effort to put together. For the list of events I've built web pages for, check out the events page at http://dentinmud.org/events.
Hopefully I can come up with something interesting for Christmas/New Years Eve in the next month.
Saturday, November 29, 2008
Monday, November 24, 2008
Melee fighting
While talking to various people over the last few months, a couple of fundamental combat related ideas have come up. Today I'm going to talk about thieves.
In a lot of fantasy/D&D style games, thieves are really just another fighter class, with different fighter skills and less armor. Alter Aeon has traditionally not been much different, and I find that less than ideal. Consider:
Mages - damage casters, inflicting damage from afar using spells.
Clerics - healers and miscellaneous support for fighters.
Warriors - tanks and heavy hitters.
Thieves - light hitters and occasional backstabbing.
It seems to me that thieves really get the short end of the stick here. Not that they can't fight, but pretty much the only thing that sets them apart in combat is the use of backstab as an opening attack.
This seems contrary to the whole premise of thieves - that they use cunning, agility, and other weirdness to accomplish tasks in unusual ways. Yet Alter Aeon is in large part constructed to have only a single track for accomplishing tasks: kill the mob. The option to just steal or 'liberate' a particular goal isn't even available in most scenarios.
This isn't to say that AA is alone in this area. Most games fall into this trap, because it is the easiest way to do things, and because coming up with general ways to handle specific scenarios is difficult or very time consuming.
I don't intend to address all of this inequality in this post, but I believe that I can address one aspect of it: how thieves handle combat. Mages blast, fighters fight, clerics heal. All these tasks are pretty straight forward. But what should a thief do to be different from 'just another fighter'? One answer I've come up with is this: thieves spoil the fight.
A good example of this would be the 'trip' skill. Tripping something small is no big deal, but suppose you and your group are fighting a twenty foot giant. Casters are doing their thing, fighters are doing their thing, but all of this is really setup for the thieves to get in place: suddenly the giant goes down face first, making things much easier for the fighters and casters.
Trip is the most obvious 'spoiler' skill, but plenty of others could be found. There may also be special defensive skills for thieves to allow them to temporarily be in danger - perhaps an enhanced dodge that can give a thief a very good chance of getting alive out of a sticky situation - but only effective for a handful of hits or a very short period of time.
With this in mind, I may be adjusting the various thief and warrior skills to push things slightly in this direction in the future. Ideas?
In a lot of fantasy/D&D style games, thieves are really just another fighter class, with different fighter skills and less armor. Alter Aeon has traditionally not been much different, and I find that less than ideal. Consider:
Mages - damage casters, inflicting damage from afar using spells.
Clerics - healers and miscellaneous support for fighters.
Warriors - tanks and heavy hitters.
Thieves - light hitters and occasional backstabbing.
It seems to me that thieves really get the short end of the stick here. Not that they can't fight, but pretty much the only thing that sets them apart in combat is the use of backstab as an opening attack.
This seems contrary to the whole premise of thieves - that they use cunning, agility, and other weirdness to accomplish tasks in unusual ways. Yet Alter Aeon is in large part constructed to have only a single track for accomplishing tasks: kill the mob. The option to just steal or 'liberate' a particular goal isn't even available in most scenarios.
This isn't to say that AA is alone in this area. Most games fall into this trap, because it is the easiest way to do things, and because coming up with general ways to handle specific scenarios is difficult or very time consuming.
I don't intend to address all of this inequality in this post, but I believe that I can address one aspect of it: how thieves handle combat. Mages blast, fighters fight, clerics heal. All these tasks are pretty straight forward. But what should a thief do to be different from 'just another fighter'? One answer I've come up with is this: thieves spoil the fight.
A good example of this would be the 'trip' skill. Tripping something small is no big deal, but suppose you and your group are fighting a twenty foot giant. Casters are doing their thing, fighters are doing their thing, but all of this is really setup for the thieves to get in place: suddenly the giant goes down face first, making things much easier for the fighters and casters.
Trip is the most obvious 'spoiler' skill, but plenty of others could be found. There may also be special defensive skills for thieves to allow them to temporarily be in danger - perhaps an enhanced dodge that can give a thief a very good chance of getting alive out of a sticky situation - but only effective for a handful of hits or a very short period of time.
With this in mind, I may be adjusting the various thief and warrior skills to push things slightly in this direction in the future. Ideas?
Labels:
game balance,
new features,
thieves
Friday, November 21, 2008
Miscellaneous Update
I have been a bad developer, and have not posted recently. Part of this is due to things going on in my life, but more of it is due to lack of incentive on my part. I seem to have cyclical swings, and if I follow the historical pattern I should come out of it here in a week or so. But enough about my problems, let's talk about the game!
Of the major events recently, I'd say the biggest two are quicker movement regen, and the str/dex changes. The movement regen change is really only a net improvement of about 25%, but the important part is that it regens on every prompt instead of every tick. For new players, this is absolutely critical; nothing sucks more than being one step away from a safe room and unable to walk there for the 30 seconds it takes for another tick to hit. It changes the newbie game from a 'move a few squares then rest for 30 seconds' kind of game to a 'move more slowly through a few squares and look at stuff' kind of game. It's definitely more pleasant for me when I'm playing, and I've gotten similar remarks from pretty much everyone else.
Strength and dex are another matter. Several very vocal people have already complained, though since I was expecting it, it bothers me less than it initially did. It also helps that nearly everyone who is complaining has already figured out how to change equipment with the least amount of damage. There are also a handful of people who dislike the change because they feel it hurts their characters, but at the same time see the logic behind it and support it. In their view, it affects everyone equally, so it's fair if nothing else.
I only put in the first stage of str/dex in this last update. This limits the spells to +6 and widens the range of boosting to +8, flat across the board. (It used to be +5 or higher depending on how low your natural stat was.) In February, I plan to lower the limit to +5, and in may to +4. I don't think I'll raise the boost range, as it seems to me that +8 is probably sufficient. I'll have to collect more information on this going forward.
One minor change which is actually pretty major is a sort of 'freak' multiplier for randoms. It's just a single line in the changelog, but it's actually a pretty big deal from an equipment standpoint - it's like getting a really kick-ass unique in games like Diablo II. There's four different levels with about a 1 in 8 chance for each successive level. Each level adds 30 composite points to the total, so if you get all four (about one in 4000 odds), you can add nearly 4 hit/dam to the total of the object. Of course, odds are good you'll end up with most of the points going elsewhere, but it basically allows for 'super' random objects to appear from time to time. I don't think this will break the game, as it will be much harder to accumulate sets, and it's much more likely to happen on bound equipment.
Of the major events recently, I'd say the biggest two are quicker movement regen, and the str/dex changes. The movement regen change is really only a net improvement of about 25%, but the important part is that it regens on every prompt instead of every tick. For new players, this is absolutely critical; nothing sucks more than being one step away from a safe room and unable to walk there for the 30 seconds it takes for another tick to hit. It changes the newbie game from a 'move a few squares then rest for 30 seconds' kind of game to a 'move more slowly through a few squares and look at stuff' kind of game. It's definitely more pleasant for me when I'm playing, and I've gotten similar remarks from pretty much everyone else.
Strength and dex are another matter. Several very vocal people have already complained, though since I was expecting it, it bothers me less than it initially did. It also helps that nearly everyone who is complaining has already figured out how to change equipment with the least amount of damage. There are also a handful of people who dislike the change because they feel it hurts their characters, but at the same time see the logic behind it and support it. In their view, it affects everyone equally, so it's fair if nothing else.
I only put in the first stage of str/dex in this last update. This limits the spells to +6 and widens the range of boosting to +8, flat across the board. (It used to be +5 or higher depending on how low your natural stat was.) In February, I plan to lower the limit to +5, and in may to +4. I don't think I'll raise the boost range, as it seems to me that +8 is probably sufficient. I'll have to collect more information on this going forward.
One minor change which is actually pretty major is a sort of 'freak' multiplier for randoms. It's just a single line in the changelog, but it's actually a pretty big deal from an equipment standpoint - it's like getting a really kick-ass unique in games like Diablo II. There's four different levels with about a 1 in 8 chance for each successive level. Each level adds 30 composite points to the total, so if you get all four (about one in 4000 odds), you can add nearly 4 hit/dam to the total of the object. Of course, odds are good you'll end up with most of the points going elsewhere, but it basically allows for 'super' random objects to appear from time to time. I don't think this will break the game, as it will be much harder to accumulate sets, and it's much more likely to happen on bound equipment.
Labels:
dexterity,
eq,
game balance,
randoms,
strength
Friday, November 14, 2008
Newbie newbie newbie
Today, I spent a couple of hours play a newbie up to level 10. I went through nearly all of the Sloe quest area, including taking out the vampire and going through uffspigot. I did end up modifying a handful of things along the way, and there's still some stuff that's not the way it should be, but in general it was a pretty fun experience.
I also, for the first time in quite a while, got that weird 'this is actually fun' feeling when I was going through the first part of a new quest Morpheus has been adding. I never really thought that side quests would add a lot to it, but they really improve the feel of the game, and give it a real feeling of depth. I'm going to have to add some more stuff in here along these lines, it's just a matter of coming up with ideas.
(Regarding ideas, this is a reminder to myself to put Varjojen Vir, the Winter Wolf, up in the 16400 rack of northern Ash Mountains.)
The game play was really pretty balanced up to level 10 once I lowered the level of a couple of mobs. The waypoints even seem placed at reasonable locations. One thing I really did notice though is that having to go back to camp to level and learn skills was really quite problematic, because at these levels you might be able to gain five levels in the time it takes to complete a quest (the vampire quest, for example.)
One possible solution to this that I'm kicking around right now is to allow people to level up to ten or so without a trainer. This would make gameplay less interrupted by the need to return to camp and fight your way back to wherever you were. The skills are less important than the levels in my mind.
Either way, this is coming along nicely, and seems more playable every time I go through it. It really needs a few solid 8 hour days dedicated to it to get it ready for prime time; perhaps I'll start doing some of that on Sunday.
In other news, the new client has been on hold for a few days while I take care of other things. This morning, I used the 'upx' executable file compressor on the existing AA client, and managed to shrink it down from 8 meg to just over 2; this should make the downloads much more reasonable for people. I'll watch the client download stats from this point forward. It should be interesting to see if changing the download size actually results in more downloads.
Also on Sunday, I hope to boot in the new intro screen code, warts and all. It should be easy enough to revert if there's a problem, and the best way to find bugs is to open something to the public.
I also, for the first time in quite a while, got that weird 'this is actually fun' feeling when I was going through the first part of a new quest Morpheus has been adding. I never really thought that side quests would add a lot to it, but they really improve the feel of the game, and give it a real feeling of depth. I'm going to have to add some more stuff in here along these lines, it's just a matter of coming up with ideas.
(Regarding ideas, this is a reminder to myself to put Varjojen Vir, the Winter Wolf, up in the 16400 rack of northern Ash Mountains.)
The game play was really pretty balanced up to level 10 once I lowered the level of a couple of mobs. The waypoints even seem placed at reasonable locations. One thing I really did notice though is that having to go back to camp to level and learn skills was really quite problematic, because at these levels you might be able to gain five levels in the time it takes to complete a quest (the vampire quest, for example.)
One possible solution to this that I'm kicking around right now is to allow people to level up to ten or so without a trainer. This would make gameplay less interrupted by the need to return to camp and fight your way back to wherever you were. The skills are less important than the levels in my mind.
Either way, this is coming along nicely, and seems more playable every time I go through it. It really needs a few solid 8 hour days dedicated to it to get it ready for prime time; perhaps I'll start doing some of that on Sunday.
In other news, the new client has been on hold for a few days while I take care of other things. This morning, I used the 'upx' executable file compressor on the existing AA client, and managed to shrink it down from 8 meg to just over 2; this should make the downloads much more reasonable for people. I'll watch the client download stats from this point forward. It should be interesting to see if changing the download size actually results in more downloads.
Also on Sunday, I hope to boot in the new intro screen code, warts and all. It should be easy enough to revert if there's a problem, and the best way to find bugs is to open something to the public.
Labels:
islands,
new players
Thursday, November 13, 2008
The scourge of organization
I spent most of today doing web page cleanup and reorganization. For starters, I got Smith's Glossary of Mudding Terms edited and put onto the article pages. After that, I started thinking about the internal organization of the article pages, and how it basically sucks. All the links have to be added manually, and the metadata about the documents is pretty much only present in the document and copied as necessary into the manually added external links.
So in response to this, I built up a primitive document management system for the various articles. The new version can be found at http://dentinmud.org/articles. I wrote it all using shell scripts, and the various versions of the pages are built from a text file database.
This was partially driven by the idea that without a quick and easy way for people to see updates, there would likely not be any recurring traffic to the article pages. Also, it would be nice to have a categorized list, and possibly author sections. So the first things I built with the management system were a categorized listing, a date-sorted listing, and an author sorted-listing.
While looking at these pages, you might notice that the formatting and section headers are inconsistent. I've been having real problems coming up with a consistent way of breaking up and displaying subsections in the various pages; if any of you readers have any bright ideas on things to try, I'm up for it. There are a lot of pages where there are several major sections, each of which should be marked with its own sub-header.
In code news, it only took about two hours to reorganize the intro screens so that the name and password come later in the character creation process. That said, I totally do not trust this code. I've never had intro screen code boot in without at least one bug slipping through, and this was a pretty substantial reorganization; on top of that, I was tired when I did it, so I probably missed something super important. I'll try to debug it later, though I'm pretty booked up for this weekend and probably won't have time until Sunday.
The title of this post is not so much regarding some scourge that is preventing organization from happening so much as the scourge that is organization itself. I have this urge to organize a lot of things that perhaps don't need it; these web page articles may fall into that category. On the other hand, when I think about how I need to have about ten times as many articles as we currently do, it reminds me that the work I put in now will save me vast amounts of time later.
So in response to this, I built up a primitive document management system for the various articles. The new version can be found at http://dentinmud.org/articles. I wrote it all using shell scripts, and the various versions of the pages are built from a text file database.
This was partially driven by the idea that without a quick and easy way for people to see updates, there would likely not be any recurring traffic to the article pages. Also, it would be nice to have a categorized list, and possibly author sections. So the first things I built with the management system were a categorized listing, a date-sorted listing, and an author sorted-listing.
While looking at these pages, you might notice that the formatting and section headers are inconsistent. I've been having real problems coming up with a consistent way of breaking up and displaying subsections in the various pages; if any of you readers have any bright ideas on things to try, I'm up for it. There are a lot of pages where there are several major sections, each of which should be marked with its own sub-header.
In code news, it only took about two hours to reorganize the intro screens so that the name and password come later in the character creation process. That said, I totally do not trust this code. I've never had intro screen code boot in without at least one bug slipping through, and this was a pretty substantial reorganization; on top of that, I was tired when I did it, so I probably missed something super important. I'll try to debug it later, though I'm pretty booked up for this weekend and probably won't have time until Sunday.
The title of this post is not so much regarding some scourge that is preventing organization from happening so much as the scourge that is organization itself. I have this urge to organize a lot of things that perhaps don't need it; these web page articles may fall into that category. On the other hand, when I think about how I need to have about ten times as many articles as we currently do, it reminds me that the work I put in now will save me vast amounts of time later.
Labels:
articles
Wednesday, November 12, 2008
Article - how to pick a god
After some pestering by Lexie, I finally managed to get to her 'How to Pick a God' article, which is now posted on the main AA articles page. She might yet disown it, because my sense of style demanded that I modify it quite a bit; but I think it's a decent article on the topic.
The regen changes from last night went in this morning, and appear to be almost universally liked. Playing as a newbie, it certainly is more palatable than the previous. I should consider switching over mana regen and hp regen as well, but probably not for a while.
If I get time tonight, I may make the previously mentioned dexterity and strength changes, as well as begin breaking up the intro screens.
The regen changes from last night went in this morning, and appear to be almost universally liked. Playing as a newbie, it certainly is more palatable than the previous. I should consider switching over mana regen and hp regen as well, but probably not for a while.
If I get time tonight, I may make the previously mentioned dexterity and strength changes, as well as begin breaking up the intro screens.
Labels:
articles
Tuesday, November 11, 2008
Newbies and login screens
Today, I was overcome by the urge to do newbie cleanup. Perhaps I've been spending too much time looking at the dropout statistics from the character creation process. Maybe it was my gods bugging me to get to things that I should have done last week. Maybe it was the coffee I got in the afternoon; that always seems to give me incentive, though it's bad for sleeping.
I ran up a newbie thief character, and got no farther than the cave system before I had my first major thing to fix: movement regen. Movement regen sucks, in that you run out and you have to wait an arbitrary amount of time to be able to go anywhere, even if you only want to walk one room to a safe area so you can sleep. Some brainstorming with myself and an hour later, we now have continuous movement regen. I'm going to boot the code in tomorrow morning.
I originally planned to halt movement regen completely if the character was lagged or melee fighting, but after fighting a bit and running out of movement, it occurred to me that I would -never- get back any movement and might not even be able to flee. Now movement regen is just cut in half while fighting. Regen from equipment or spells isn't affected by this though, in that you always get full regen from effects-based regen.
The other set of changes I made was some relatively minor reorganization of the intro screens. I created an 'Obsolete Options' menu under the 'Advanced' menu, and moved the old login points as well as different ltype selection there.
I plan to make some real changes tomorrow, in that I'm going to move the name selection process to much later on, put email address and some other things in the main menu, and start character creation immediately on connect. The final process will probably be along the lines of:
Create a new character?
Are you blind?
Pick your class
Pick your sex
Existing player/how did you find us
Name selection
Password
Login menu
This should remove at least one screen from the process (the email screen), and hopefully will get people involved in creating the character before they get to the high-dropout phase: name selection. I suspect this will raise the retention rate for new players by probably around a factor of two. Hopefully the stats will bear me out on this.
One other thing I may do is put more character creation options on the main menu, or even prior to name selection. I should probably have Locane come up with an automatic description system as well, so people can pick eye color and the like to get an autogenerated long description.
I ran up a newbie thief character, and got no farther than the cave system before I had my first major thing to fix: movement regen. Movement regen sucks, in that you run out and you have to wait an arbitrary amount of time to be able to go anywhere, even if you only want to walk one room to a safe area so you can sleep. Some brainstorming with myself and an hour later, we now have continuous movement regen. I'm going to boot the code in tomorrow morning.
I originally planned to halt movement regen completely if the character was lagged or melee fighting, but after fighting a bit and running out of movement, it occurred to me that I would -never- get back any movement and might not even be able to flee. Now movement regen is just cut in half while fighting. Regen from equipment or spells isn't affected by this though, in that you always get full regen from effects-based regen.
The other set of changes I made was some relatively minor reorganization of the intro screens. I created an 'Obsolete Options' menu under the 'Advanced' menu, and moved the old login points as well as different ltype selection there.
I plan to make some real changes tomorrow, in that I'm going to move the name selection process to much later on, put email address and some other things in the main menu, and start character creation immediately on connect. The final process will probably be along the lines of:
Create a new character?
Are you blind?
Pick your class
Pick your sex
Existing player/how did you find us
Name selection
Password
Login menu
This should remove at least one screen from the process (the email screen), and hopefully will get people involved in creating the character before they get to the high-dropout phase: name selection. I suspect this will raise the retention rate for new players by probably around a factor of two. Hopefully the stats will bear me out on this.
One other thing I may do is put more character creation options on the main menu, or even prior to name selection. I should probably have Locane come up with an automatic description system as well, so people can pick eye color and the like to get an autogenerated long description.
Labels:
logins,
new players
Monday, November 10, 2008
Status update
I have been lax in my updates recently, but some small amount of work has been going on anyway. I spent a lot of time working on the client code, which has been a complete pain in the ass. wxWidgets is a portable gui toolkit, but it's also grossly inconsistent, poorly documented, and fundamentally broken in certain ways. That said, it has enough advantages over the QT toolkit to justify switching. It's just painful.
One of the nastier sets of issues I've run into is getting scrolling and font size changes to work properly in a wxTextEdit. In the case of the scrollbar, I manually determine the character position of each line and apply direction hysteresis to scroll up or down using the function keys. For font size changes, I basically clear the buffer and rerender the whole thing. Both of these are trivial operations under QT. Further, the QT documentation is much, much better.
That said, QT is bloated beyond belief, and the licensing is going to be problematic for what I want to do in the future. But primarily, it's the bloat factor that is the biggest problem. With the new toolkit, I can get executables that are around 20% as big as the QT client.
Right now, I'm trying to get dialog boxes working, and it's -really- unclear how these stupid sizer objects are supposed to function. I have it displaying a disconnect dialog right now, but I can't figure out how to place text in it, put the buttons in the right place, or hook anything in it up. I may have to go digging through sample code to get it to work right.
One of the nastier sets of issues I've run into is getting scrolling and font size changes to work properly in a wxTextEdit. In the case of the scrollbar, I manually determine the character position of each line and apply direction hysteresis to scroll up or down using the function keys. For font size changes, I basically clear the buffer and rerender the whole thing. Both of these are trivial operations under QT. Further, the QT documentation is much, much better.
That said, QT is bloated beyond belief, and the licensing is going to be problematic for what I want to do in the future. But primarily, it's the bloat factor that is the biggest problem. With the new toolkit, I can get executables that are around 20% as big as the QT client.
Right now, I'm trying to get dialog boxes working, and it's -really- unclear how these stupid sizer objects are supposed to function. I have it displaying a disconnect dialog right now, but I can't figure out how to place text in it, put the buttons in the right place, or hook anything in it up. I may have to go digging through sample code to get it to work right.
Thursday, November 6, 2008
Software Complexity and Human Limits
As you might have read from other posts here, I've been working on a gui client for Alter Aeon. Gui code is fundamentally different from what I'm used to working on, in that it has loads of function pointer handlers and 'virtual internal state' that is mostly held by which objects are instantiated and what they're presently doing. At its lowest level, this can of course be represented by a perfectly ordinary state machine, however these state machines are fairly large and the state it's currently in isn't always obvious.
[As a side note, I do work in FAX software in my off time, and this also has some pretty huge state machines. However, those state machines are really well defined in one central location, and it's much more obvious what's going on. Even saying that, I still have a hard time with those.]
While working on this client, I quickly lose track of what needs to be done and how the states work. The client itself is big enough that I can't remember everything that is in it; and after not working on it seriously for almost two years, I had a lot of trouble getting back up to speed.
A good part of this is that the code itself was basically built from the ground up, and then never cleaned up by a maintainer. Maintenance is more than just adding a button here or there and fixing minor bugs; maintenance of software means getting in there and saying "why the hell are these drawing functions intermingled with scroll locking?", then moving things around so it makes more sense. A good example of this is the button system, the entirety of which is contained in the main window implementation file. This serves only to clutter up the main window implementation, and further make the button code hard as hell to understand.
So I've been doing the proper thing and moving functions around, grouping them by functionality, and trying to make useful classes on the side where I can hide details. But even so, I can tell that my standard way of thinking about and writing code is showing signs of strain. Much like I'm having to retool my picking technique on guitar, I need to retool my brain to handle this kind of abstraction better.
I don't really need any advice or recommendations for books here; I know where to find that sort of thing if I need it, and I've done this enough to know when I'll need it. I even know conceptually how to approach this kind of problem; I think I'm just currently bad at it. Fortunately (or perhaps unfortunately), there's a lot of work left to do on this client, so I'll get lots of practice.
[As a side note, I do work in FAX software in my off time, and this also has some pretty huge state machines. However, those state machines are really well defined in one central location, and it's much more obvious what's going on. Even saying that, I still have a hard time with those.]
While working on this client, I quickly lose track of what needs to be done and how the states work. The client itself is big enough that I can't remember everything that is in it; and after not working on it seriously for almost two years, I had a lot of trouble getting back up to speed.
A good part of this is that the code itself was basically built from the ground up, and then never cleaned up by a maintainer. Maintenance is more than just adding a button here or there and fixing minor bugs; maintenance of software means getting in there and saying "why the hell are these drawing functions intermingled with scroll locking?", then moving things around so it makes more sense. A good example of this is the button system, the entirety of which is contained in the main window implementation file. This serves only to clutter up the main window implementation, and further make the button code hard as hell to understand.
So I've been doing the proper thing and moving functions around, grouping them by functionality, and trying to make useful classes on the side where I can hide details. But even so, I can tell that my standard way of thinking about and writing code is showing signs of strain. Much like I'm having to retool my picking technique on guitar, I need to retool my brain to handle this kind of abstraction better.
I don't really need any advice or recommendations for books here; I know where to find that sort of thing if I need it, and I've done this enough to know when I'll need it. I even know conceptually how to approach this kind of problem; I think I'm just currently bad at it. Fortunately (or perhaps unfortunately), there's a lot of work left to do on this client, so I'll get lots of practice.
Labels:
client,
complexity limits,
software engineering,
toolkits
Gui client update
I've been working on the client, and as part of my foray into using a new gui toolkit I've learned the joys of incompatible toolkits. My latest problem arose with regard to the main display text window. There's two options for this:
1) use the standard system provided window type that has screen reader support and fewer features, or
2) use the custom window type that has way more features but doesn't read properly.
So, I've been trying to make the standard window type work, and it's been problematic. One thing in particular is that I can't easily go back and just change the one aspect of the style in the window; for example, I can't just change the font size without recoloring the whole damned thing. As a result of this, I spent most of the morning cleaning up and building a renderer that saves everything ever sent to the window and redraws it if necessary.
Another side effect of this is that I can't change the text background easily when window scrolling is locked. For now, I just have the window background changing, which is actually starting to grow on me - you can obviously tell that the window is locked, and the text keeps its high contrast. It does look a little blocky in certain areas though.
I don't have any of the intercession windows built (like the 'do you really want to disconnect without logging off the game' window), and I've been avoiding button handling like crazy. I'm getting down to where I'm going to have to start doing that in the next couple of days though.
On the schedule for this afternoon (if I don't get interrupted) is logfile saving, and the parts of the 'view' menu that make sense.
1) use the standard system provided window type that has screen reader support and fewer features, or
2) use the custom window type that has way more features but doesn't read properly.
So, I've been trying to make the standard window type work, and it's been problematic. One thing in particular is that I can't easily go back and just change the one aspect of the style in the window; for example, I can't just change the font size without recoloring the whole damned thing. As a result of this, I spent most of the morning cleaning up and building a renderer that saves everything ever sent to the window and redraws it if necessary.
Another side effect of this is that I can't change the text background easily when window scrolling is locked. For now, I just have the window background changing, which is actually starting to grow on me - you can obviously tell that the window is locked, and the text keeps its high contrast. It does look a little blocky in certain areas though.
I don't have any of the intercession windows built (like the 'do you really want to disconnect without logging off the game' window), and I've been avoiding button handling like crazy. I'm getting down to where I'm going to have to start doing that in the next couple of days though.
On the schedule for this afternoon (if I don't get interrupted) is logfile saving, and the parts of the 'view' menu that make sense.
Wednesday, November 5, 2008
Articles and other stuff
Recently, I managed to get two more articles up. One is from Lexie/Ilex, and is targeted at helping low level players make the most of their regen time.
The other I'm more proud of, because it's something I actually wrote (instead of just editing.) Mine is on high level attack strategies, and lists some of the weirder things I've seen and used over the years.
Doubtless the players have seen many more than this; if you think something deserves to be added, let me know and I'll consider it for inclusion.
In other news, the client continues on its merry way. I got the help menus working properly last night, and today I had intended to work on something easy yet important, but I can't remember it right now. I'm somewhat afraid of the buttons, because those are going to be drastically different on probably all architectures. I need to find a way to handle those so they're pretty everywhere.
The other I'm more proud of, because it's something I actually wrote (instead of just editing.) Mine is on high level attack strategies, and lists some of the weirder things I've seen and used over the years.
Doubtless the players have seen many more than this; if you think something deserves to be added, let me know and I'll consider it for inclusion.
In other news, the client continues on its merry way. I got the help menus working properly last night, and today I had intended to work on something easy yet important, but I can't remember it right now. I'm somewhat afraid of the buttons, because those are going to be drastically different on probably all architectures. I need to find a way to handle those so they're pretty everywhere.
Monday, November 3, 2008
Google Click Fraud Update
I just got an email back from Google saying that they have re-evaluated my case based on newer information. Apparently the site that got me started getting a lot of other people too, and eventually Google was able to put together enough evidence to prove it and take care of it.
I suspect they have a multiple-tier system for handling this sort of thing, so that even though you might be ignored at first, eventually things get straightened out. Anyway, looks like things are back to normal.
But I'm still not comfortable using the content network.
I suspect they have a multiple-tier system for handling this sort of thing, so that even though you might be ignored at first, eventually things get straightened out. Anyway, looks like things are back to normal.
But I'm still not comfortable using the content network.
Labels:
google adwords click fraud
Miscellaneous Update
I've been lax over the last few days with regard to getting much of anything done. On the plus side, Morpheus ran a system event for Halloween which the players seemed to enjoy. It was hard on him though, as there were some hitches (including a minor problem with teleport not working on the magic pumpkins), but everything worked out in the end. I should have the event log and notices up in the next few days.
In other news, I'm going to start making changes to the strength and dexterity spells. I haven't decided some of the more important implementation details, but hopefully I can come up with something that doesn't generate a lot of fallout. There was a lot of resistance from a handful of the higher level players.
Personally, this kind of resistance makes the game a lot less fun for me. I feel the urge to walk on eggshells all the time, and I further feel like the only changes I can make are those that make players more powerful - anything that involves a minor nerfing of player power, spells, or equipment immediately generates craploads of hatemail. Such is the life of an implementor - balance the needs of the game against the fun of the players, and hopefully manage both.
It's all the worse in that sometimes I find (or more often finally get around to) fixing something that is broken, only to find out that two thirds of the players use it religiously and are willing to raise hell if it's removed (or fixed.) It can really cramp your ability to get anything done if you actually care about the player base.
In other news, I'm going to start making changes to the strength and dexterity spells. I haven't decided some of the more important implementation details, but hopefully I can come up with something that doesn't generate a lot of fallout. There was a lot of resistance from a handful of the higher level players.
Personally, this kind of resistance makes the game a lot less fun for me. I feel the urge to walk on eggshells all the time, and I further feel like the only changes I can make are those that make players more powerful - anything that involves a minor nerfing of player power, spells, or equipment immediately generates craploads of hatemail. Such is the life of an implementor - balance the needs of the game against the fun of the players, and hopefully manage both.
It's all the worse in that sometimes I find (or more often finally get around to) fixing something that is broken, only to find out that two thirds of the players use it religiously and are willing to raise hell if it's removed (or fixed.) It can really cramp your ability to get anything done if you actually care about the player base.
Labels:
game balance,
new features,
system event
Subscribe to:
Posts (Atom)