12.29.05
KaladeaMUD – Comming along (part 1)
Time: 16 hours
Total Time: 103 hours
—————————————–
Done a lot of work on Kaladea over the past few days. I’ll try to recap since the last thing I reported on was colors (and that was an accomplishment done seemingly ages ago).
The first real night I buckled down to work I did quite a bit. I managed to enhance the command structure and make a lot of tweaks, as well as test commands with a non-human (that is, my random num gen and some previously written messages).
All went well until I realized one mistake, a rather large one if I had implemented a great many commands. The problem was with the design. I used the player structrure instead of the (at the time, non-existant) character structure. This would be a problem down the road when the NPC’s wouldn’t be able to use any in-game commands (such as attack, flee, get, drop, etc.).
I sat wondering to myself why I had done it this way and then, after some sleep and time to think, I remembered. I initially wanted to derive my player class from the character class (as each player is a character with more information). However, this created a potential problem, and the program initially (with this design) looks more like a C program. I later derived the players from the socket class as each player also has a socket. This also makes it safe for me to cast between the two if I so please (mainly from socket to player).
At the time I only had two commands (say and quit), so the change wasn’t too hard. If I hadn’t caught this it could have taken several hours to fix correctly. Now I have a character class which is the basis for most things in the game, which points to a player class if one exists (which in turns points back).
A few other simple enhacements followed, like fleshing out a bit of the character class (still isnt much) and adding Trust Levels to commands. For the unknowing (which is most of you I’m sure), there are different levels of commands in online games. For example, you dont want players to be able to warp from room to room, but immortals (admins, implementors, enforcers, etc) will need to. Also, you dont want your “guests” to have the ability to full out play the game without making an account. Likewise you dont want all of your immortals (ones you hire) to have access to vital commands that mess with the game (such as reboot, slay, or copyover). Trust Levels (TLs) is a simple concept which just checks a players TL in relation to that of the command. If it falls short (that is, too low) then they can’t use it.
I later spent some time revamping my *nix Makefile. I got annoyed with having so many files in the same folder that I seperated all of them into folders for easier finding. Unfortunately this screws up the makefile, which thinks they are all in the same file until you tell it otherwise. So after a bit of revamping I got it to work correctly and added some nice features to it (all of my object files are now in a seperate directory, which is nice).
Several hours have been spent tinkering, playing with formats and testing things. You can now specify your name when you login which gives names to the chatters. My friend and I spent some time chatting over it using colors and what not and the base (at the time) seemed quite stable. I also left it running on Cygwin overnight (to see if it would crash) but alas, it was here when I returned today.
I also added the now infamous glog() function to the code base. My attempts thus far to port Xlib for Kaladea have failed. Granted I havent spent much time, but I realized I don’t really want an elaborate logging scheme. I need something that is easy and works.
I have written a bit of code to deal with the hashing I will need to do, but it remains untested (haven’t even attempted a compile yet). It has been designed as an abstract data type (ADT), but from my experience with templates deaing with my binary tree code I’m not sure how well it will work.
Currently I’m working on adding one of the three core elements to the game: rooms. One thing about a mud is you need to move around. It is part of the game. Which is great, but it means a lot of work. Luckily I don’t need to design prototype structures for this (unlike objects and mobs), as rooms stay the same and are governed by resets.
One other thing I should be working on is file loading. I need a good system. I can think of a very space inefficient way to do things which is easy, but it is not really flexible. I could make the loading somewhat like that of my last CS I assignment, where everything is done line by line, and how the next line is interpreted is dictated by the previous line (meaning the previous line tells how to hanle the next line). This means that each line contains one bit of information. This isnt a problem, but I’m used to the very flexible loading of DIKU derived bases where everything is read one word at a time and interpreted that way (usually putting a key and a piece of data per line). I’m sure I’ll figure it out.
Ok, I think thats all for now. Time to go continue smashing my head in… I mean programming.