Sean Middleditch » Computer Games
Work has been murder. Not even because there’s so much of it, but just the particular projects and the jumping around it entails. I’m very much a 90/10 sort of guy when it comes to projects. (I love the first 90% of the project, and despise the last 10% of polishing and tweaking.)
SCA practice has been going well. Finally bought a piece of armor (a gorget). Still need all the other bits. Every time I can find a good deal, I either am just too late or piece doesn’t fit me or the time period I’m aiming for. Being 6′3″, 240lbs., and picky is a real problem with armor, it seems.
Quit Kanar last weekend. Showed up to hand off my character’s responsibilities so somebody else could run the guard. Hopefully it works out for everyone. I even banned myself from the Kanar boards (yay DNS tricks) so I wouldn’t keep wasting hours every day posting there. Why bother if I don’t play anymore? I don’t want to be like most the BOCs who spend a grotesque amount of their life posting on the boards for a game they won’t play.
Japan trip is still in the air. Planning on going at the end of April still, but haven’t gotten my passport back yet. Will be cutting it close. Don’t want to buy tickets until I’m sure I’ll actually be able to go.
Ashes of Eradur (K3) is coming along. Lots of people have been working on rules stuff, which is nice. I haven’t had much time for it, unfortunately. We’re having a setting discussion on Saturday, so that will be good.
Also trying to get a couple other projects started for Ogre Lord. Want to get a “old fashioned” type card deck out their for LARPers and maybe SCA players. People like to play modern card games in those settings, and it’s a lot nicer to have a “fitting” deck than a regular Aviator deck or whatever. I’m sure some people will bitch that the entire project is misguided since modern cards didn’t exist in old times, but I’ll get over it.
I’ve been playing a good bit of Final Fantasy: Crystal Chronicles with friends and family over the weekend. I think that party games are one of the best genres to evolve over the last few years on consoles, and I myself particularly love the idea of a party-oriented RPG. (Not to confuse RPG players, but by “party” I mean having a bunch of friends over wanting to play a game, not a group of characters in that game.)
Crystal Chronicles has got a lot of things “right,” but many more things wrong, from a party perspective. Even as a more classical RPG, there are things that Crystal Chronicles does which makes the over-all game experience less fun.
The first annoyance people will likely notice while playing CC is that chalice. Stray out of its protective aura and you take damage. Sadly, as small an area as one has to begin with while keeping four characters on the screen at once, the even smaller radius that the chalice provides forces the players to stick into a very small, very hectic space. The worst part of the chalice, however, is that it effectively removes one player from playing the game. While carrying the chalice, the player can do nothing but walk. The player may drop the chalice at any time, but in quite a few battles doing so is quite problematic, especially when you have three other players trying to utilize mobility and strategy to defeat the bad guys.
A second big problem with CC is the towns. The towns serve to add shops and a few very simplistic story entries. Quite simply, the towns are useless. Worse, though, is that they eat a huge amount of play time. While one player needs to go to the merchant, another needs to go to the blacksmith, but they cannot both take care of their business at the same time, as the characters have to stick together in a small area on the screen, and the merchants and blacksmiths and so on are never standing around next to each other. The game would not lose anything of value by reducing towns to a simple per-player menu, and the game could remove a huge source of down time by removing the towns.
In a similar vein to the towns, the over-world map is likewise a huge sink of time. It doesn’t really serve any purpose other than to make the players press a lot of buttons and spend a lot of time selecting which dungeon they want to enter. The story nodes are even worse, adding little to the meat of the game experience, and they don’t even really add all that much to the story. The story in CC is present but weak and poorly executed, and the cut-scenes just eat up a lot of time with no real benefit to the players.
The final problem with CC is the repetition. There are only a small handful of levels, and while each has three cycles, players generally need to repeat the same cycle of a level over and over again in order to get decent artifacts for every character. While the players don’t exactly have to do this, few will choose not to. Possible solutions might be to allow players to collect more than one artifact per playthrough of the level (possibly allowing the players with higher scores to pick second or third artifacts after the other players have picked theirs), or to disallow replay of a level until another year has passed and thereby curbing the powergaming mentality that pretty much all computer RPG players have been trained to have.
All in all, while Crystal Chronicles is a fun game, I believe that the above three mistakes severely damage the enjoyment level of the game. Having played for many hours over several days, I’ve noted that we’ve spend an equal or greater amount of time dinking about on the world-map or in towns than we have actually playing the game, and that we end up repeating each area three or four times per year just in order to let every character keep up with the rest in terms of major artifacts.
I’m hoping that Crystal Chronicles: DS manages to alleviate these problems. Each player having their own screen entirely might remove the restriction forcing players to stick together in small areas, which would make not only the dungeons but also the towns more bearable.
As stated previously, I’ve been having a lot of fun lately playing the two GBA Fire Emblem games.
One thing I particularly like about the series is how it limits save/load cheating. Every single move you make is saved. You can only load games either at the beginning of a chapter or where ever you last left off. That makes it impossible to reload an earlier version of a mission if you make a mistake. You can restart the entire mission, but on many missions that’s a lot of pain, and in all honesty pretty boring. I’d like to see it where you can’t restart the mission at all. Or perhaps you can restart the mission only if you completely lose - if you just lose a unit or miss an item or something, you can’t restart.
I’ve been thinking about what I would have done differently had I made the games. This isn’t much of a surprise, given that’s how I got into programming to begin with. I’ve also been thinking about the new Game Cube Fire Emblem game out in two months, and the features it will bring to the table.
First, I really like the class/level system in Fire Emblem. Very simple, provides lots of improvement opportunities (38 level-ups for most units, 47 for a few others), and a variety through class branching (two for most units, 4 for a few others). The game mechanics are very simple and easy to grasp.
However, being the achiever/explorer type in gaming, I’d prefer more opportunities for character growth. I’d honestly add another level of class upgrades to all units, sort of like the three “trainees” in Sacred Stones. That would be 47 (or maybe 57) levels for all units, and two class branches to choose from.
I would remove the upgrade tokens from the game. I don’t think they really serve much purpose. Most players will always wait until level 20 to upgrade their unit, and I don’t really see *that* much of a shortage of upgrade tokens; I’d argue that the only reason you have a shortage is because you often have too many extra units.
I’ve also thought about adding yet one more class choice - upon reaching 20th level in the final class progression of a unit, the unit gets to branch to a “perfect class.” This class does not gain any further levels, but grants a new ability and some stat boosts. The mage knight might have perfect class options of either a class that can use swords or a class that can use bows, for example.
The rest of the changes I’d make would all be story/game-play based. There would be far, far more branches in the quest. In the two GBA entries, you had the occassional optional side-quest and two main story branches. I’d have a larger number of branches (4-8) and a good number (15-20) of optional side-branches. Example story branches might be something like, “should we attack the enemy nation head-on and quell their evil while our ally restores peace here, or should we campaign against the bandits and mercenary gangs ravaging our country’s villages and let our ally attack the enemy nation?”
The side-quests available should depend a lot more on the units you have and their actions during missions. Perhaps only if Jerad the archer attacks the bandit leader will a side-quest open - Jerad knew the leader and in their taunting, the leader refers to some item of interest from Jerad’s past that opens up the side-quest.
I’d also have the enemy and friendly units be a bit more pro-active in dialog. In the current games, it is always up to the player to talk to a friendly unit, for example. Friendly units should, if they have cause, seek out the player. Or the player’s units. The same goes for enemy units. Perhaps the bandit leader recognizes Jerad in the fray, and if he closes in with Jerad and talks to him, Jerad joins his side. Killing the bandit leader before this happens will prevent that from occuring. On that same mission, however, there would still need to be a good cause to have Jerad on the map (say, only he can convert one of the other enemy units over to your side).
I’d also limit the number of units you can have in your army at a time, and a allow the dismissal of units. In both my save games on the GBA entries, i have a large number of units, with about half of them being unused and low-level. There’s no point to levelling them up because they won’t be any better than the good unit I already have. Instead of having 30 units to choose from, the player should be forced to keep a smaller number of units in the 10-14 range. Just to make the story more interesting, I’d go so far as to say that the player can’t just dismiss any unit, but instead is forced to pick between certain pairs. Say, Jerad and the mage Hanred don’t get along as they served in opposing armies a decade ago, so if attempt to recuit Hanred, Jerad offers opposition and you have to choose which one stays. The consequence might even impact later missions as the one you dismiss might end up being an enemy. Plus, the side quests available will depend on which units you have, so if you dismiss Jared then you can never get any of the Jared-initiated side quests.
The AI would also need some work. The GBA games understandably don’t have a lot of AI capability. The Game Cube entry will hopefully have far better AI. I’d hope to see an AI with a real understanding of tactics and goals. i.e., using choke-points for an advantage, putting high-defense units in front of ranged units, sending the swordsman toward the axe users and cavalry towards the infantry, and so on.
I’d also add more randomization. If you play through the game twice, it should seem at least a little different each time around. Maybe the same basic types of units (this mission has 8 swordsman and 4 cavalry) but with their positions mixed up a bit, or with some units being randomly chosen from different types (40% change of being an axe user and 60% of being cavalry) and so on.
The final thing, adding on to the previous entry, would be a random campaign mode. No real plot, no main characters, no side-quests or interaction or anything like that. Just 20 random linear missions with a basic underlying theme (invade enemy territory and defeat leader, wipe out roamind bands of enemies, defend homeland, whatever). You’d pick 4-6 basic level 1 units to start your army with, and have the opportunity to recruit more randomly generated units over the coarse of the missions (say, one map may have a village which, if entered, present a new unit that joins, which could be anything from a mage to a cavalier, with theri level based on the average level being, say, half the average level of the current army).
I think it would be dead simple to write an Open Source Fire Emblem style of game. The games are just *so* simple at their core.
It’s ballooned to about 1.5k lines, and there’s still a number of things I need to implement. So much for my dream of keeping it under 1k. I really doubt that it’ll ever top 3k, though.
There are three main features yet to be implemented. The first is MCCP support. The second is ZMP support. The final is the rest of the telnet necessities; the protocol is parsed and generated correctly, but everything besides raw text input is ignored.
I got bored at work today and decided to, instead of working on AweMUD, start playing with JavaScript and SQLite.
I’ve had this idea in my head for a week or three now on building a MUD kernel for developing JavaScript-based MUDs. JavaScript is a very capable language. It really just needs bindings to I/O to be able to build a complete MUD on its own. I decided to go a *little* further and provide the following features:
* Telnet protocol handling
* Timers
* Main loop driver
* SQL-based storage
And that’s pretty much it. The entire codebase is under 600 lines at the moment, although it’s only about 60% complete. I still need to write the telnet handling code (which on its own could be several hundred lines), the timer code (this is *very* simple, not a big deal) and provide bindings to SQLite for JavaScript (also not a big deal, I just never did it before so it’ll time a little time learning how).
Had I already been experienced in using the SpiderMonkey API, I probably would have had the project 90% done by the end of today. Ah well. I’m still fairly happy with the features it has so far. One of the better ones, that even AweMUD lacks, is how it handles listening sockets.
A JavaScript API allows the scripts to register a name, interface, and port for listening. The interface can be any IP address (even IPv6) or node-name, and that becomes the interface that the listening socket is bound to. AweMUD always binds to the 0.0.0.0 and :: interfaces. Second, you can make *many* listening sockets, so you could listen to 192.168.1.1 and 192.168.1.3 but not 192.168.1.2 (assuming all were valid IPs for the host). Even more control than AweMUD has. Finally, the name of the listening socket (which doesn’t have to be unique) is based in to the connection callback. This allows scripts to alter their behaviour based on how the client connected. For example, all administrator features might require that the user has admin privileges *and* that the client connected over the loopback interface.
The only other feature I *might* want to add eventually is an HTTP server and client w/ very simple XML DOM support. The HTTP server would allow building an admin interface or just a simple RPC interface. The HTTP client support would be used for RPC stuff. For example, you might have a website for your MUD on have a form for updating player account information; this could use AJAX to invoke a method on the MUD server using HTTP/XML (either XML-RPC or a custom format). Alternatively, the player account information might be stored outside of the MUD (such as a MySQL database) and the MUD could use the HTTP client support to connect to an Apache/P* interface to the database to verify passwords and retrieve/update account details. There are plenty of other possible uses for this stuff as well.
I’d like that feature in AweMUD, too. For AweMUD I’d probably limit it stricly to XML-RPC, though, because I don’t want to have to do a bunch of DOM manipulation in C++. *::shudder::*
I have finally written the Web-based MUD Client I’ve been wanting to do for a long while now. Or, at least, I’ve started on it. And got it fairly well working, even.
The trick was getting the network connection. JavaScript can’t do that, not without Gecko extensions, and in the Real World(tm) the majority of users don’t use Firefox. Since the whole point of a web-based MUD client is to make it possible for just about anyone to use it (and also a little that making flashy UI-type stuff in HTML/JavaScript is a lot easier than in GTK/C), making it widely usable was a priority. Thus a Java(tm) applet.
The applet still needs work. It doesn’t really do much with the telnet options, although it does understand them enough to not spit them out to the display. It does actually connect to the MUD server and talk to it (using threads - who over at Sun thought that bright one up? “let’s make it so that you need a bazillion threads to simulate a simple select() loop!”) and does interface with JavaScript using the Java/JavaScript bridge called LiveConnect! by Netscape, and hopefully called something by Microsoft because I’m going to be pretty sad if I find out it doesn’t work in IE.
Although at this point I wouldn’t be surprised if it didn’t work in IE, merely because I haven’t tested it there and there’s plenty of room for bugs at this point. There are a few I know of already, but won’t fix just yet.
One thing I’m very pleased with is the speed and display quality of the client as a whole. There are several Java(tm) applet MUD/telnet clients around, and they all suffer from very poor text rendering both in terms of speed and quality. Probably something to do with being limited to the (supposedly?) slow AWT toolkit. My client spits all the display out as HTML into a div tag using JavaScript, so it looks as pretty as any other text on any other website. The speed is actually rather surprising. The bridge between the JVM and browser isn’t exactly speedy, but it seems to display output faster than the AWT-based applets I’ve seen.
Speaking of speed, I already did some “early” optimization. That bridge was indeed causing some speed problems originally whenever an ANSI color code came in. Upon seeing the ANSI code, the parser would dump all the text it had so far, parse the ANSI code, dump the result, then resume with the text. Any portions of output that had a lot of color codes (like the big banner/logo in the AweMUD login and menu screens, were just dog slow to display. I optimized by simply buffering up all the output and flushing it one go after an update. That means there’s generally only one bridged call per output update (for non-overly-large updates), which is more than fast enough.
Now that I’ve got the basics working on the JavaScript side, I’m thinking about finding a decent JavaScript widget library (I think the Novell/Ximian guys were recommending one not long ago, will have to look into it) so I can make the UI real nice-like. It’s just a text input field right now, and that just won’t cut it. Oh no, definitely not. ;-)
Also need to recruit some artistically talented types to make the pretties for the interface. Give it a decent fantasy game atmospheric look. Something like Simutronics’ StormFront client, only not bloated beyond usefulness and Windows-only.
Anyone who’s played a MUD or text-based adventure game is familiar with the concept of a “room.” Each location in the game that you can visit is classically represented by a room. A room includes things like a title, a description, the list of objects in the room, a list of exits leading to other rooms, and so on. Travelling about one of these games is accomplised by using the exits (often using directional commands like “north” or “se”) and moving from room to room.
Of course, as many people also know, this is very limiting and unrealistic. You cannot easily see what is happening in an adjacent room. You can’t move around in a large room. You’re pretty much in the room, or not in the room, and that’s it. Some games allow you to look in/at/through exits to see what is the adjoining room. Some actions, such as yelling, might cause your voice to propogate through to the adjoining rooms. All in all, however, the situation isn’t very nice.
Some games have experimented with coordinate based systems. There are two main variations on this; one that continues to use rooms, and one that does not. The room based solutions seek to solve one problem: moving around in large rooms. In these systems, you still move from room to room by exits, and each room is still its own separate container. You are able to position yourself in the room, which mostly becomes useful for combat. Some of the more advanced implementations allow for more intricate behaviour based on coordinate location, such as varying object descriptions based on which part of the room you’re in or limiting interaction with objects if you are too far away.
The second coordinate method is much more free form. Rooms are done away with, and instead “areas” are defined using geometric equations (most often a point and radius). When you are within range of an object its area description is added to what you “see.” The description will often change as you close in, getting more and more detail. For example, a forest might add “The trees at the edge of the forest are small compared to the towering giants seen deeper in the dark wood.” to the description printed with the “look” command when you are just barely within its radius. A waterfall might add “The faint sound of rushing water from a distant waterfall can just be made out.” to the description. And so on.
The second system has some very interesting possibilities. The world can be described in a way which in a much looser format while still providing very indepth descriptions. Especially when more complex geometry is used to describe the world and effects like blocking visuals, directional descriptions, and so on are put into place. The system can easily be combined with a room-based system when very precise and controlled movement is needed, such as in a dungeon or other indoor area. The main problem comes from the incredibly amount of detail and work that needs to be put into each area to make it work properly. The descriptions need to match various distances, direction (”You hear the waterfall to the east” vs “You hear the waterfall to the southwest”), blocked visuals, etc. You are, in essence, creating a 3D engine, but instead of just describing the object as a model, you need to write out full descriptions for all the different ways the object could be “rendered.” It’s a lot of work.
Additionally, coordinate based systems suffer from both a lack of fine grained control and complexity. You still need a room based solution to lay out indoor areas or dungeons, as otherwise you would need a complex 3D representation of the indoor area and an advanced text description generator. (”A passage opens to the north, leading along a torchlit hallway. The faintt outline of a door can be seen at the end of the dimly lit passage.” How do you get a good, indepth, varied description like that out of even a detailed 3D representation of a room?) Movement either becomes very inprecise (the “north” command moves some fixed units towards north) or requires very complex commands to specify the direction and distance, or raw coordinates, to move to. The player is then also required to know their coordinates and understand what those mean in relation to their destination.
The solution I’m in favor of, which I’m not aware of having been used yet, is to continue using rooms, but break them into smaller units which are heavily interconnected. I’m dubbing them sub-rooms.
The idea is very simple. Each sub-room works exactly like a traditional room. You are either in it, or not. The room contains a title, a description, a list of objects, and a list of exits. The big difference is in the exits. The exits not only describe ways to leave the current room and enter the next, but also a wide variety of flags which specify how events in one room propogate to the next and what can by default be seen or interacted with in adjoining rooms.
My favorite example is a large room broken into several pieces. There is the main floor of the room, a stairway running along the north wall with a balcony at the top. There is a door on the balcony and a door under the balcony, both of which lead into hallways. Players in any part of the room can hear things which occur in another part of the room. However, players on the balcony cannot see anything under the balcony, nor can players under the balcony see anything on the balcony.
Movement in this situation continues to work as it classically does. “go under balcony”, “climb stairs”, “out”, etc. Player interactions, however, can be much more complex. In a classic MUD, either the entire room is a single area, or the balcony is a separate room requiring special commands to see down to the floor and listen to anything occuring there. In this model, a player could run up the stairs, comment to his friends, and then go through the doorway. The sounds of battle occuring in the hallway would drift to the ears of people in the room. Players could leap off the balcony onto the floor below. A player could crawl onto the balcony above and listen to a private conversation going on in the room below. And so on.
This system would actually be very easy to implement. As mentioned above, many of the changes are on the exits themselves. You’d just add a number of properties to each exit specifying whether to display people in the adjoining sub-room, whether speech should carry through, and so on. The rest of the changes would be to carry through the actions. If you say something, check each exit in your sub-room and, if they specify for speech to carry through, print out what is said to the connected room. The room description code (for “look” and similar) would be updated to display characters in adjoining rooms if the exit specifies it to be so. (”You are on the balcony. Jay is also here. You see Rob on the floor below.”) Finally, the object lookup code (used to find the player object when you type in a command with “jay” for example) would then be updated to search adjoining rooms as well.
That fairly well sums up the sub-room idea. Combining it with features that exist, but are rare, in classical MUDs, such as basing an exit’s status on the status of an object in the room, would allow for very indepth areas. Imagine being able to jump on a table in a fight. Or being able to kick the table out from under someone in a fight. Pretty nifty stuff.
Coming along further on the ruleset for the table-top game. (And which I plan on later converting to use as the core AweMUD ruleset.)
Currently, it’s looking similar in many ways to D&D 3rd Edition, but definitely has some distinct differences. The core stats and health system are totally different, the XP system is different, the magic system is wildly different, and we have a few additional sets of rules like Knowledges and our Action Points.
Knowledges are basically Skills (which work pretty much the same in my game as they do in D&D), except that they’re cheaper. I figure that knowledge is something you are told once and retain, while other skills are things you must practice over and over and over to get good at. I also further classified it as a Knowledge being something you know, not something you do, while a Skill is something you physical accomplish. Many Knowledges and Skills overlap. For example, Lock Knowledge and Lock Picking Skill. The former lets you identify the culture and time period a lock was made in, the basic principles of the technology, etc. The later won’t give you too much information about it, but will let you know how to use a set of tools to open the lock.
Action Points are something that I fear may not work too well in table-top, and they’ll be done quite differently in AweMUD. (Although still very similar. For those already familiar with AweMUD, Action Points are basically round time measured in ticks. In the table top game, though, we still have rounds, only because we have to do all the book keeping and the computer can’t do it for us.)
Each character gets a number of Action Points each round. Faster characters get more. Various actions then cost some fixed number of points. A character may spend some or all of their AP each round. Character then also get turns in the round. During their turn, they can perform any number of actions that they want. When it isn’t their turn, they may only perform specific actions; some are things they can do at any time during someone else’s turn, while other actions are reactive (such as defending). So, during a character’s turn, they could potentially do a lot of things, but then they might not have enough AP left over to defend themself during the rest of the round.
It gets a little more complicated with a few actions which cost more AP than a character can possibly have. If the action cost is greater than the character’s max AP, but less than twice their max AP, then the character may perform the action during the round by spending a number of AP equal to their max. (Basically, they can’t perform any other action.) If the cost is twice their max AP or more, it takes two full turns; they may make no actions during the current round, and may only make the one action on their next. (They must declare they are doing this on the first round; they may not skip a turn and then announce that they spent the last preparing to do some multi-round action.) Actions which cost three times the character’s max AP take three round, and so on.
Good game, for the most part. The controls and action were great, although the defense moves were limited. (i.e, block. Later on you can block and move. Much later on block and attack, once.) As always, the game only makes me think of the improvements I’d make to it.
For one, back to the moves, more defense and counter type moves. Would be great to be able to catch an attack with the whip and toss the opponent or something. More environment-based moves would be nice too, like wall jumping or swinging. (The whip-swing action was very weird in this game.)
Probably most importantly, though, would be to make the thing longer. It had 6 areas. Not much at all. I personally like it when a game takes 50-100 hours to finish. So long, at least, as the game stays interesting during that time. 50-100 hours of the same old combat over and over would be boring as hell. Fill that time up with plot (and not just lame cut scenes) and exploration, and you’d have a pretty compelling game. I’ve been wanting a Castlevania game with multiple towns, multiple castles, independent plots, and (gasp) multiple vampires for a while. A couple older games had multiple vampires (like the N64 games), and Lament of Innocence had a minor one that you fought as a boss (and play as a secret character), but to be honest I’d expect a vampire lord’s castle to be crawling with the bastards.
A game where several known vampire lords existed, which you could take on in various order, perhaps multiplayer with some friends (working cooperatively for shared rewards, working independently on different vampires, or working competitively vying for the reward on a single vampire) would rock. A plot could tie together the vampire lords, and the game could even continue infinitely by generating new “random” vampires, although a console probably couldn’t handle all this without at least a hard-drive. If the whole world could be (at least partially) randomly generated, and castles/dungeons generated on first entrance, you could have a game that stays interesting and unique for a very long time.
The power up system in Lament of Innocence game is similar to that of other recent Castlevania games. You find little containers that increase health, mana, etc. I’d personally like to see some sort of level-based system, as then it rewards you for actions. I.e., after a while, I got to the point where I never bothered to fight monsters unless the room forced me to (by doing the “lock all doors until all monsters are dead” thing) because there was little reward for doing so. To stop power-leveling, I’d probably track how much exp the player has earned in each area, and top off based on that. So you couldn’t just keep going back and killing the same enemies over and over, but instead had to move on. Figure the average player fights maybe 70% of the enemies in the game and calculate ideal levels and such based on that. Players who find and fight every monster everywhere are rewarded by having a higher average level.
The weapons available are also rather pointless. You have the classic castlevania sub-weapons, which are always cool, but then these orbs that modify them. However, you really don’t have much reason to switch between them very much. The magic system was also limited to a handful of cheesy artifacts you could find. You then had gems which could be used, if you had a particular artifact, for various effects. I’d personally like to see something more like the gba Castlevania games merged with this system. You’d have a variety of spells that enhanced you main weapon(s), sub-weapons, perhaps gems, and the usual personal power ups. Your flame spell could add flame to the whip, a sword, your throwing axe, whatever. Much more intricate and varied.
Speaking of which, a larger variety of weapons would be nice too. Lament of Innocence had 4 armors and 5 whips. You got better armor over time (it becomes available in the store). There are then three optional/bonus whips (elemental powered) and one main upgrade near the end of the game. In a multiplayer game you couldn’t let everyone have the whip (the whip is unique according to the Castlevania story, although I suppose it’s possible more could be made), and since other Castlevania games have indeed had varying weapons (and, in fact, heroes besides the whip-wielding Belmonts) it would be just fine to have swords, axes, polearms, arrows, etc, and let players select the weapons they like best.
All in all, I suppose, I’m as always wanting a mix of a good action game like Castlevania with a great story/exploration game like Baldur’s Gate. I want a long, intriguing, depth-filled, action-packed game with the Castlevania theme. Maybe I should apply to work for Kanomi? ;-)
Fax
Guh. Finally got that project finished. Hopefully for real, this time.
I pity the next programmer/administrator that works on this system after me. It is the world’s biggest hack job. Seriously. *Horrible* hack job. I hate having all this crammed on one server, too, since that means even a small mistake on my part in this fax system (which is likely, given how it’s a *huge ugly* hack job) will compromise the whole system… :(
The way it’s setup is an LPR printer (LPRng) with a script backend, which runs under a setuid wrapper (the script needs web server privileges, LPRng runs w/ printer privileges - *gods* I wish we had ACLs on this system, would make life *so* much easier). The script parses the LPRng control files, and the postscript input (printing non-postscript files will be bad) for things like document title (the Novell print system the client machines are using doesn’t set job name), moves the postscript input to another spool directory, and inserts the basic info into the SupportWeb database.
Then, a SupportWeb module lets the user select files they printed, enter the recipient name/phone, and fax. That just updates the database with recipient info and a ‘ready’ flag. Then, a cron job runs that calls efax to fax the actual documents.
Yuck. The files sprawled everywhere, my wrappers for security, the fact that I’m a coder and not a system administrator… these all add up to a pretty ugly setup. Pity my replacement!
UofM
Application’s due in a couple days. Of course, the people that wait till the last minute have no chance of getting in, but I’m a last minute sort of person. Still haven’t finished the application; one essay left to write.
The essay’s on cultural perspective sorts of things. Depending on how you look at it, I either have nothing to offer there, or lots to offer. Translated, I’m not sure if being part of the global Internet community counts. If not, the essay won’t be very good, because that’s the extend of my cultural experience. :(
Patents
I have a question for my fellow Advogato readers. Is it ethical to patent a software algorithm that is original, allow it to be freely used with no royalties or resitrictions in software licensed under an FSF (or OSI) approved license, but charge money (personal profit) for corporations that wish to use it?
I’ve seen a lot of “defensive” Free Software patents; i.e., people who patent ideas and algorithms and don’t allow non-Free software to use it at all, to use as bartering or simply enforced Freedom (there’s an oxy-moron for you) of Software. The idea of expecting commercial entities to wish to use the idea, and happily accepting payment from them for it, feels to me like it’s on the borderline.
I’ll note now that I am not a Freedom Fighter. I’m much closer to the OSI view of things than the FSF, I believe proprietary software is perfectly ethical (as long as you don’t compete through lockin, but through quality of product and service), etc. I’m just not personally sure how I feel about software patents. And again, by that I mean things like coming up with a new compression algorithm and patenting it, vs something bogus like the Amazaon one-click patent. I.e., a real new unobvious process/algorithm.
Thoughts?
Anti-Red Hat-ism
I’ve seen a lot of people get incredibly vocal about how much they hate Red Hat lately. To the point that they make claims against Red Hat similar to SCO’s claims against the GPL.
I don’t get it. At all. One of the arguments I’ve seen (from a programmer I used to respect) is that Red Hat makes a profit off of community contributions, and doesn’t give the money back. This programmer is clearly incompetent at running a business.
Red Hat doesn’t give anything back? The amount of code they release, fully under the GPL, isn’t giving back? The programmers they pay to work on Free Software projects isn’t giving back? They make a profit, yes. Welcome to reality, they’re a business. If they didn’t pull in a profit, they wouldn’t stay in business, and all those amazing employees they have would likely be stuck working somewhere that really doesn’t contribute back to the community.
Giving this subject the depth it deserves isn’t something I’m going to do in a diary entry. I just… sometimes it amazes me what boneheads people can be. People who are usually very intelligent and logical.
AweMUD
Work has been slow, between work projects, UofM application, the contract job, bass practice, and the handful of new Game Cube and Gameboy games I’ve gotten lately. ;-)
Complexity
I got Dungeon Mater II running in DosBox last night. I only played for a few minutes. Still, tho, it was great. This is one of the two games that made me want to learn how to program when I was a child. (The other game was Lands of Lore, the Thrown of Chaos, or whichever it was called.)
Similarly, I was playing Dragon Quest I on my Gameboy lately. These games, both ancient classics, have sort of stirred this desire in me, one almost identical to that original desire to learn game programming.
Modern games, including my own AweMUD, are based on so much complexity. You need like 8 button mice to play FPS games efficiently, you need manuals bigger than most programming texts to handle most RPGs, “party” console games still have steep learning curves… everything is so complex.
Dungeon Master II was also complex for its time. Some things about it are *too* complex. (Mainly, casting spells to the point of being silly, and some “obvious” UI doesn’t work like one would expect.) Still, tho, compared to a game like Baldur’s Gate II (or any modern RPG), DM2 is wonderfully simple.
In the case of these old RPGs, I think one of the best ideas is to remove character creation. In modern RPGs, you can spend hours making a character, tweaking them out just right, and many players end up scrapping them and starting over because they find out they didn’t tweak it just right.
On the other hand, lots of old console-style RPGs gave you a “pre-tweaked” character. By this, I mean that all character s have various strengths and weaknesses, and your character has some specific set of thse, which may not be the set you’d prefer. You are still forced into this character, however; you aren’t playing the alter-ego you want to have, but the one the game forced on you.
Other old RPGs, however, circumvented this problem by simply reducing complexity. Instead of having a ton of statistics and a starting character with strengths in just a few, you end up with a few statistics and your starting character being mostly equal in all. How you build from then on is up to you.
In more complex games, this also works out well. It’s similar to, say, Dungeon Siege, in which you just play the game, and whichever style you prefer to use the most is the one your character becomes best at.
Ugh, I had a lot more ideas to write about this, but work calls. Time to get back to it.