05.14.06
Posted in ALPHA, KaladeaMUD at 10:26 pm by Nick
Time: 1 hour
Total: 76 hours
————————–
The rest of my project will be devoted to planning out KaladeaMUD and quite possibly sticking it into a Wiki. While I have much to do (and little time for programming), I hope to read more of Bartle’s book and figure out more of the issues.
I also figured there is quite a bit more reading I need to do in general. I should check to see what introductory economic majors at UNI use and read most of it. The worst thing for an online game is a super inflated currency. Hopefully come next year I’ll begin programming on it again, and this time with a battle plan.
In the mean time I will, over the summer and perhaps sometime soon, be learning both Ada and Lua. Lua looks to be the best scripting language to tie into Kaladea, and Ada is the language of choice for CS III. Now, I have pretty much skated through CS I and CS II without much strife or personal investmet. I doubt CS III will be the same way, so I’m looking forward to learning a new language.
In other news, I have one assignment (one extra credit assign if I can muster it) before I take my last final at UNI. To get an A in the class I need a 92% on the final. However, to settle for an A- I need to get a 66% on the final, and since the class average was 71% I’m guessing I should at least get that.
Permalink
04.29.06
Posted in ALPHA, Computer Science, KaladeaMUD, Programming at 6:14 pm by Nick
Time: 1 hour
Total: 72 hours
————————–
Alright, so I exported the code (and SQL) and threw it up for the world to see. Sadly it is in a bad shape, as I made a last ditch effort something like six weeks ago to institute the character class that avatars were to be derived from. When I came back (within the last few days) it was hard to tell what I had done to it and what the errors were exactly.
The statistics are listed at the bottom of the display page. It resulted in a net gain of 2646 lines and 9 files. Sadly, I had to gather the stats by hand, so I’m thinking I may make a program that will tally lines.
In any event, here is Scratch MUD with all I have added (movement, rooms, help files, and a bit more):
http://www.nick-cash.com/download/cs2/final
— edit —
I have updated the KaladeaMUD project page on the right with a listing of added features, the stats, and a few comments.
Permalink
04.27.06
Posted in ALPHA, KaladeaMUD at 7:21 pm by Nick
Time: 1 hour
Total: 71 hours
————————–
Despite the listed time for this, I’ve given it some serious thought. Ultimately, I would like to finish reading Designing Virtual Worlds, reread parts of MUD Programming, and finally learn some more Lua. An alternative to Lua would be Python. There are several reasons I like Python (very clean and neat scripting language), and the book MUD Programming uses Python for all game logic, while the basic kernel is coded in C++. This is a very flexible and efficient design.
Something I would also like to do is iron out a few more issues due to the design. Ultimately the design process on Kaladea could take a year or more. I am not very satisfied with the way it has turned out from Scratch, as I think the MySQL implementation (and a few other methods) are very bulky and annoying.
Thus, I have decided to scrap this current codebase. It has made some tremendous leaps, but it is currently just to unwieldly to work in the long run. I do, however, plan to keep the code around and use it for my CS II final project.
Permalink
03.21.06
Posted in ALPHA, KaladeaMUD, Programming at 4:38 pm by Nick
Time: 20 hours
Total: 66 hours
————————–
This is my update for all of spring break about KaladeaMUD.
–
I have finished the room OLC. All rooms can be created, destroyed, and edited online. One of the things I am appreciating about the design is my implementation of vnums. I have dubbed the entire thing the Flex Vnum System. In SMAUG, a room only existed as its vnum, and if you wanted to change the vnum you either needed a new room or to redit the entire thing. In Kaladea, vnum is merely another field you can edit. Vnums are used for identification purposes, as well as exit linking, so they are quite vital. However, since we have 4 billion of them and we can now use them even more efficiently, I doubt I’ll ever have to worry about the mechanics too much ever again.
As noted before, all of the mud relies on Avatars to execute commands. Avatars are any player that is logged in. This presents a problem, as you want all MUD-driven players (NPCs) to be able to use commands as well. However, to make them Avatars is a waste, as they dont need a lot of the information associated with Avatars (sockets, ip address, etc). This is a good example of when to use a derived class.
A derived class is like a specification of a normal class. For instance, every rectangle is a shape, but not every shape is a rectangle. This is referred to as a is-a relationship. You can take that example further by saying every square is a rectangle, and every rectangle is a shape. Thus, a square is a rectangle and shape. Note how it gets more specific. In this instance, every player (Avatar) is a character, but not every character is a player. Thus, you can make players a derived type of character. Then they inherit all information based on characters (name, description, stats, etc) and add in the player specific data. Then the entire engine need only support characters as mobiles, instead of Avatars and NPCs.
I made the slight transformation required to accomplish this. Compiling and testing still have yet to be done, as well as modification of the editing interfaces. The character class is empty, but that doesnt stop it from being an inherited base class.
In other news, I installed the updated string library into the bowels of Kaladea. It already needs to be updated again. ::sigh:: Hopefully I will be able to put it to good use. In Ksilyan’s future plans for it he said he may make each bucket into a binary tree, which I think would be quite nice (even if not needed).
In other other news, I hope to get the actual www.nick-cash.com web site going agian, this time Kaladea related. I kind of miss having my own forums. Sorry to all of those two hundred members, you’ll have to sign up yet again. With any luck at all Kaladea will be in the alpha stage by the end of the year, in which we might be able to do some minor play testing.
And, finally, in other other -other- news, I’ll continue uploading the other 5 pages of ALPHA quotes into phpQuote and hopefully make a few modificaitons to the displays so its a little more clear what you can search for (I mean a list of searchable categories) and display the total number of quotes within the DB.
Permalink
02.20.06
Posted in ALPHA, KaladeaMUD, Programming at 8:09 pm by Nick
Time: 1 hour
Total: 37 hours
——————–
I’ve decided that after I get the OLC set for room creation I will take a bit of a break from the programming aspect. I seriously need to do some reading.
Richard Bartle’s book Designing Virtual Worlds has tons of information I should at least be aware of before I continue further. Beyond that book is the book MUD Programming by Ron Penton that I should also read in relation to design issues. His later example ties the whole mud to scripting, which would be -very- -very- nice to have. If I plan to integrate scripting, I need to do it now. It takes some serious work in the design stage (the SGE scripting system is a testament to feature addition without much through to the design aspect), and I should at least be aware of such things.
In the mean time I’ll keep up the programming with CS II and hopefully finish the phpQuote Engine (which will be publicly available to view).
In other news, I’m really far behind in my other classes and I definitely need to play catchup this week. I’ll see what I can do about phpQuote though, it would be nice to get it rolling so we can store the ALPHA quotes.
Permalink
02.16.06
Posted in ALPHA, KaladeaMUD, Programming at 2:19 pm by Nick
Time: 4 hours
Total: 36 hours
———————-
A very vital role of any program is to use resources efficiently to accomplish its task. This is no different for games.
When you create an object in game, it lives within the resources of the system the program runs on. You can conserve space by storing data that is the same (and always will be) one time for all objects of a given type. For example, if you have one hundred storm troopers prancing about the game, ready for interaction with your players, their name’s will never change.
The purpose of a shared string library is to cut down on memory usage by combining an efficient way to look up and store strings one time, as opposed to each time they would have been stored. As stated before, the name of a mobile game controlled character (NPC or mob) will never change unless a game builder deems it so. Thus, if you have anywhere from one to ten thousand of them (or more), you can get by using one allocated string. This works by keeping a number stored along with it to store the number of references to that particular string that the game needs.
My recent playing with binary tree’s helps a lot with this, and is, in fact, almost exactly what needs to be done. The examples we used for class stored string with reference counts, which is what the MUD will do. However, I have chosen to employ the use of an already tested and proven library produced by David Haley (otherwise known as Ksilyan). It is relatively simple to get working and produces good results. It operates somewhat differently, using a hash table (an array of linked lists it generally happens to be, though an array of binary tree’s may work better) instead of a binary tree. This can be good sometimes, as they can often be -faster- than binary trees. That is something very hard to do.
Most of this time was spent doing research, downloading, compiling, and fiddiling with the library. It still remains largely untested and unused within my code (rooms and players have little need for shared strings), though it has been successfully added to Kaladea. Now I must resume work on the OLC for rooms. Once this is done I’ll throw the thing up and do a bit of testing, and possibly work on the task system a bit more.
–
In related news (yay), O’Kane has given me permission (he even installed MySQL) to use the machine Sidhe that belongs to UNI. If you haven’t heard my rant, just know it is a very high end machine. You can find it at http://sidhe.cs.uni.edu .
Permalink
02.07.06
Posted in ALPHA, KaladeaMUD, Programming at 12:23 pm by Nick
Time: 6 hours
Total: 30 hours
———————–—
OLC stands for OnLine Creation. This means that without rebooting the game, and without the help of another program (even something like pico/nano/vi/notepad/wordpad..) you can create, delete, and otherwise edit features of the game. OLC is very powerful. Without it it can be hard to manage, add on to, and fix the virtual world that employs it.
I have begun work on the OLC system for rooms. I realized sometime ago that I would, in fact, need vnum’s (virtual numbers). This a number that will be assigned to each virtual room within the world (each one unique). Thus, we will have a finite number of rooms avaialbe to us. Luckily for us, that number will be up in the 4 billion range, so there is absolutely nothing to worry about. Also, with the way I’ve made it, you can reuse vnum’s, though the unique room id’s (employed as a sort of primary key in the MySQL table) are also finite and are never reused. This will probably never be a problem, and if it is I can just up the value and give us even more.
—
I didn’t mention this before, but I’ve worked on a task engine. This will simply be another way to keep track of what things need to be done, and I plan to have both a web interface and a game interface for it. It will note the urgency, and each player will be able to have tasks (though only admin’s can assign them). It will also note the details of the task, give a completion percent to be specified by people, and completion dates.
The system will be modified from a very similar system used be a fellow mud administrator who was kind enough to give me this code. Granted I will have to do all of the work to tie it into Kaladea itself, but a good portion of the web interface is done.
—
Unrelated to Kaladea, but still important (as working on one project all of the time can be frustrating), I’ve begun work on what I call the phpQuote Engine. With so many good quotes from people I’ve decided to make a web based engine to store them. This also will run off of MySQL, and I’ve downloaded the Apache web server to test this all on my own system.
You can expect this to be done by next week. Then we will have a place to store all of the ALPHA quotes and be able to look them up! Should be interesting.
–
On one last note, some user on Sourceforge wishes to take over the Xlib project. STRANGE! It has a rather high activity percentile when I check it, but a rather small amount of downloads. This is fine by me really, as I really don’t plan on doing much more (if any) work on the Xlib project itself. I’m interested to see what they will do with it, or if they just want the xlib name.
Permalink
02.01.06
Posted in ALPHA, KaladeaMUD, Programming at 10:56 pm by Nick
Time: 4 hours
Total: 24 hours
———————–
This update produced a very large and significant amount of code. Anyone who know’s MUDs, games, or just about any online application knows that you must have a way for people to get help and explanations on topics.
And thus I have created a help file system. It is complete with the name, author, creation date, last updated date, help text, and permissions. I made an online editor, which took roughly half the time I spent on this. With it you can churn out help files really quickly, and the interface is very nice. I’ve longed for something similar since the old days when I first started wtih MUDs.
With SMAUG/SWR, you must do everything one command at a time. Granted there was a string editor mode which allowed to insert text blocks (which I still may have to do), but nothing like this. With four lines you can make and save a help file, where as in SWR it may take anywhere from five to fifteen or more depending on the length.
Soon I will work on making/deleting/editing room’s online. Once this is done I can start a base layout for some area’s if I wish, though I think I will just make a bit more of limbo (the default “error” area), as building is more for my two designers at this point. Later, if the code ever gets to alpha testing (no, not ALPHA testing 
) then I may try making an area. That is a very long ways away.
Permalink
01.25.06
Posted in ALPHA, KaladeaMUD, Programming at 8:10 pm by Nick
Time: 15 hours
Total: 20 hours
———————–
This is an accumulation of effort that I never felt like blogging about. Most of it was done over our 4 day weekend.
I decided to switch the codebase to an interesting base called Scratch. It is designed to be the “socketmud of the C++ world”. All this means is you can connect and use some basic commands, but nothing else. This leaves most of the development up to the programmer/design team.
I’ve pretty much fallen in love with this code. I’ve been using C for so long I think like a C programmer instead of C++. This fellow knows his C++, though it took some serious tinkering to get it to compile. It runs on windows so I can test it on my local machine without too much trouble.
I’ve made so many enhancements, many of them minor, that I don’t remember them all. Most notably the base loads rooms. Oh, and since I didn’t mention it, the entire base run’s off ot MySQL as opposed to basic file saving. This promotes many things. First would be speed. Seaching a DB with MySQL is -fast-. Fast is good. Second is security. Anyone wishing to tamper with their player file would first have to log into my shell (not an easy task), and then log into the MySQL command line interface. This also makes additions, deletions, and modifications relatively easy. MySQL is also free.
You can now move around in the world. There are only a few rooms, but it works for now. I need to flesh out building, but there are more important things.
A small todo list (in no particular order):
- Create help file, help file editing system, and related code
- Store room’s in a balanced binary tree using the AVL algorithm described earlier. Possibly create an Abstract Data Template (ADT) so it will be easy to make tree’s of the type.
- Work on an editor interface. Straight up strings arent going to cut it for room descriptions or help files.
- Change say output format. It looks dumb.
- Create system wide data configuration and log key spots.
Permalink
12.29.05
Posted in ALPHA, General, KaladeaMUD, Programming at 11:30 pm by Nick
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.
Permalink
« Previous entries Next Page » Next Page »