After the break

So I took a break from coding and design for a bit.  I’m back, and what I’ve been grappling with over the last little while have been the following questions:

How can I make a login server and game server that can work together to verify login credentials, allow registration, and be relatively secure without tying up the game server’s time waiting – with as little threading as possible (threading makes the complexity of a program increase in factors, I am avoiding where possible)?  After some research and asking around some of my coder haunts online, I have an idea.

First, let me start by saying a custom client will be necessary.  I had hoped to avoid this, so that anyone with a telnet client could connect.  Now I see that in order to create the sort of robust player experience I eventually want this MUD to offer, we really need to customization and standardization that a custom client would allow.  Coding for one client is easier than coding for two or more, obviously.

Basically, my quandry was how to pass a “Socket” which represents the player’s connection, from the login server to the game server, in a sort of “hand-off”, after the login server allows registration or validation of existing credentials.  This is probably not impossible, but is not going to be easy and really is not necessary.

One other option we have is the algorithm I have decided upon tentatively to handle this issue.  The player connects to the login server, which gives the option to register or login.  At the end of either process, the server generates a one-time use hashcode by random and assigns it to this player’s account in the database.  This hashcode and a timestamp is serialized using XML, and stored in a file included with the custom client.  The client automatically then disconnects from the login server, and connects to the game server, using the username, hashcode, and timestamp.  If the hashcode matches the database, and the timestamp is not more than a set amount of time old, login is successful.  Either way, the database then wipes the hashcode, and will not generate another until the player attempts to login.  The game server will not allow a null or blank hashcode from the client, thus it will not be possible to connect to the game server without having gone through the login server first.  One possibility, for added security, is instead of having the timestamp on the client computer, to have the timestamp in the database instead, associated with the hashcode.  That way, a player could not “fudge” the timestamp.

Thoughts?  Suggestions?  Can you think of anything that might improve this procedure?

Basic server functionality: In

As of today, the MUD server can be connected to via a telnet connection.  Currently there is no real interface to the game to speak of, except for testing purposes.  Database functionality will need to be added before accounts/characters will be able to be created, but at least the basic ability to connect and communicate with the server is in.  It’s a start!

More design considerations, a Client

From the moment I decided to go the MUD route, I promised myself that I would not restrict this MUD only to classic MUD paradigms either in gameplay or in design.  Granted, they will certainly share some (many) aspects.

One thing I definitely wanted to do, and something that few MUD have done is to make an optional, enhanced client for graphics and multimedia (frame-by-frame graphics reminiscent of old school Might and Magic, intermixing in potentially flash cutscenes for special events, and sounds/music) that would still allow the same gameplay, but with additional features that can add to the experience.  We will need to be careful that these changes do in fact add and do not take away from the experience, however.  More is not necessarily better.  In any case the client development will begin most likely late in the server development cycle.

Some needed Direction

Since this project began, I asked myself the question, “What is the purpose of this project?  If it is a game, what type of game will it be.”

Actually, I never asked myself that question.  I probably should have.

Nevertheless over the course of the last couple of weeks, the overall direction began to coalesce into what I should have realized all along.

I’m creating a MUD.

Perhaps in the beginning I thought of a text-based simulation as a stepping stone, or that a single player text game could go to a single player graphical fps, or even an isometric rpg.  In reality, though, it should have always been a MUD.  Why?

1.  A MUD has many of the features, in some fashion, that major and more modern games have.  Storyline, world design, artificial intelligence, multiplayer capability, etc.

2.  A MUD allows for a realistic timeframe of development, due in large part to the fact that art assets will be less of an issue, as well as the complex needs of a graphically rendered enviroment being left out.

3.  MUD’s are the technical and spiritual forefathers of today’s MMO’s.  Modern MMO’s could be largely considered larger, graphically represented, extensions of yesteryear’s MUDs.  While developing an MMO is likely beyond the horizon and certainly beyond the scope of this project, moving in a direction that is so prevalent in this game industry today is a step in the right direction.

And direction is what we’re looking for here.

A Little Snag, now Unsnagged

I had been having a problem trying to get Visual Studio to jehaw for me, and eventually found out I had to merge projects to make it work.  I’ve decided to eliminate real concurrency in order to simplify the project.  I started to realize I was spending too much time working on esoteric problems which in actuality won’t affect the game experience in any substantial way.  I now have the main structure of how the game will loop through each iteration, down on paper.  I hope to have this implemented within the next couple of days.  At that point I’ll have a small, text based world that I can walk around in, as well as the entities created being able to move around in the world as well.  Then, I’ve got to make them play with me and each other.  At that point, its a matter of adding features over time.

More Code Design

Did some flowcharting today, and some pondering over design.  The main questions I needed to answer were:

• How can I make entities (players, zombies, humans, fauna) take actions simultaneously?  Not as easy as it sounds.
• How much detail for the world?  Basic descriptions?  Or will we build it brick by brick?
• How complex will the AI be?  Will entities be able to remember where they’ve been, the experiences they’ve had, and make decisions based on those memories?
• Will the AI be able to make simple requests and answer simple questions?
• How to store entities so that I can easily get to them?
• What choices will the player be able to make about his character at the start of the game?  How will background, natural attributes, and even hobbies affect the character’s abilities when the outbreak occurs?

This and many more questions need to be answered.  What do you think?

Chasing the dream…

After a couple of false starts, time to get back into the project.  My understanding of the kind of design patterns we need to make this a reality are more mature than they were previously, and what’s more, I have momentum now.

The current project is an AI Simulation that will (hopefully) evolve into a single player, open ended RPG.  Once that is achieved, hopefully we can move on to some sort of multiplayer functionality.

It’s not going to be easy, and its not going to be fast.  Frankly, it might not even be pretty.  But it will be what it will be, and though it all we’ll learn.

I’ve actually been working on this for a week now, and so far we’ve done the following:

• Built a parser that will load areas, as well as play a role in saving/loading savefiles and player profiles.
• Started defining structure of game entities
• Partially completed a FSM (finite state machine) paradigm AI system, and stated building the AI Library
• Experimented with encoding data “bitwise” into integers to compress the data for each entity, to allow for a larger simulation population

More to come.  We’re just gamers chasing a dream.  Wish us luck.