Please take some time to read my questions. Thank you.

My current C++ exercise project is a win32-console text-only MUD engine. (MUD = "Multi-User-Dungeon" referring to the game genre in which the player wanders around in a 'map' of 'rooms' and can interact with many 'items' and 'characters'. In the text only example, this is done by entering commands such as "go north" "view room" "take hammer" "open chest" etc.) Being that my goal is for exercise (and not for some assignment i need to get done), also since a project like this involves many common concepts used in any C++ game project (or any C++ project for that matter), i wanted to inquire about several questions and issues that came up when i was designing this project.

First let me start with an example of what gameplay i am expecting:
Robot is activated.
UT (=user types): "view room" robot reports room description.
UT: "Take <object>" robot takes object into inventory.
UT: "take north wall" robot reports it cannot take the wall.
UT: "use <device>" robot activates device and reports device's interface view.
UT: "option 1" robot chooses option 1 on device, <machine> <does something> or <lights> <turn on> etc.
UT: "exit 34" robot exits door #34.
Upon entering adjacent room, robot is detected by sensor, a signal is sent to guard 5 rooms away, guard is making his way to current room.
UT: "test detection" robot scans for detectors and cameras, reports been detected.
UT: "use plasmagun" robot appropiates plasmagun, reports ready for combat.


Issue #1: Vast-Variety versus Inheritance & Polymorphism

I want my MUD to support a vastly variable variety of objects, each having x amount of data (members) and x amount of behaviours (methods). All of these objects should be stored in a single container (by sharing a common base class and having the container hold pointers).
Obviously the answer is inheritance and polymorphism, however, i realized (tell me if im wrong) that polymorphism is useful when designing a hiearchy that has SOME common behaviour and data structure, just that derived types differ in the way they do func() (= a base class function). But here i am dealing with a hiearchy which has too much variety. A flashlight object will probbably have a bool (on/off) and a switch() function, a vehicle object will have several driving functions, and a pda will have vectors of files and tons of interface functions. Many objects will be carriable, destroyable, movable, openable, closable, droppable, startable, stoppable, interfaced, single-useable, multi-useable, insertable, effective, detectable, invisible, etc. etc. etc. while many other objects will not. There are too many capabilities such as these to mention here, switchable, drivable, pressable, wheighted, electric, and any other concept that can turn up from the game story itself... Any object may have any combination of any of the capabilities said above. How to go about designing the hiearchy?
Should i make a class for every single type of capability (something like utility classes or mixins), then have objects inherit from any of the capability classes needed? I get the impression that thats alot of overhead and using lots of memory.
This issue is intertwined with the rest of the issues discussed, read on.

2: RTTI

Apparently, my MUD is futile without RTTI. As said above, im planning to store all objects in a single container. When a certain command is to be executed upon an object, the object is checked if it can actually do it. This will be either with RTTI or with my own defined rtti (like an enum TYPE variable every object will have, etc.)
I read it all over that RTTI is frowned at and shows on bad design. Any advice?

3: Responsibility

Who is in charge of executing x? lets say our game object contains the player object and the map object. When the user commands the player to take an object from a room, the pointer to the object needs to be removed from the map's room('s container) and added to players inventory('s container). Should the player access the object? Should the object-container access the player? should the command handler send a signal to the game object to conrol the transfer 'from above'? after all, the game object contains the player and the map, he should be the one operating between them. Or, should the game & objects be contained differently than mentionned above?
Taking an object from a room is just an example. Who should take care of actions affecting the game mission, actions affecting the MUD options, creating/destroying objects in the map, or in the player, etc.?

4: Updates; "Hard coding" versus "Soft coding"

So far my projects are designed in a way that the game engine with all its details are hard-coded in the exe file my compiler produces, and some files that stick around the exe are just directives which the exe will load to know in which order and in which setting to create the map & objects & how many of them to create etc, though what is a map / what is an object is hard-coded in the exe. Thinking in the long run, after my game ships to the market, what if one day i want to invent one or more new types of objects, to be added somewhere in the hiearchy? or change some behaviour of existing objects, etc.? Do i have to recompile, then post the entire exe on my game website as 'download update 1.1 - 500MB'? (a thought; is there a way to make an updater-setup program which can add and change small changes in the exe file itself?)

Then i had the soft-coding idea, which might solve not only this issue but also the others mentioned before; I can make a small exe which will be an interface between c++ and my files. I will basically be inventing my own programming language, with all necessary logic rules, comparison rules, etc etc. Then, i will 'program' the MUD in external files, what is a map, what is an object, command strings which will execute comparisons and actions, etc. The exe will then 'compile' the game from the files, learn what is a flashlight and how does it work. There is a common denominator between all actions performed in all commands in the MUD; they all do one or more of the following;
-print text to console
-get data (from any object)
-set data (of any object)
-create objects
-destroy objects
-transfer containment of objects
-perform logic and execute conditionally
what else?
There can be ultimate variety of objects and their behaviours.
When there are any updates as to how a flashlight works, or a new type of flashlight etc, all that needs to be updated are the files.
Some issues of the soft-coded idea include; 1) Why dont i USE c++ instead of re-inventing it. (is it possible to update an exe file?) 2) I thought i learned that one of the ideals of c++ is not to separaete data from operations. Objects should execute whatever execution concerns themselves. But in the soft-coded idea, the objects are just variables which only set and get themselves, and at most contain strings of commands as to how they behave. But the flashligt's action of turning on (for example) is executed elsewhere completely- probably in the execution handler which received the behaviour string from the flashlight. 3) How should the ultimate template-object be designed, an object which can have any amount of data decided at runtime based on the loaded file's info? 4) Arent there enough levels of abstraction already; Binary, Hex, Machine code, Assembly, C++, and now my level of abstraction?

5: Main issue

Anytime i face c++ issues as such, i always wonder how do they actually do it out there in real companies & developing teams. Do they 'hard code' or 'soft code', or something else altogether? How do they conceptualize their class hiearchies? How do they update their programs with small update packages you download from the website? How do they setup which object is in charge of what? (browsing through my Warcraft 3 directories, i see that the warcraft3.exe is only 268 KB, and another war3.exe of 1536 KB, but there is a war3.mpq file which is 430.5 MB big, makes me beleive they do the soft-coding way...)

Thank you, if possible, please answer to
<<email id snipped>>

You might want to take a look at existing C++ codebases such as SocketMUD, and I believe TinyMUD is C++. ftp.game.org has a huge archive of mud codebases along with MudBytes.net

Building your own codebase is an extermely in-depth endeavor and most are written with entire teams upwards of 10 people. I have made additions and changes to existing codebases (mainly SmaugFUSS),
this is much easier. Diku, was original made at the University of Copehagen so perhaps your school can create the new Diku as it were, where hundreds of codebases would derive themselves from.

Well, as i said, i myself would really like to learn how to go about all this stuff.

Well, as i said, i myself would really like to learn how to go about all this stuff.

Well there are a few things you would have to ask yourself:

  • What is the theme going to be?
  • Automated or Manual combat system?
  • Online? (will you need to code sockets?)
  • Encryption for passwords? (SHA256 recommended)
  • Room based, grid based, or overworld?
  • Quest systems?
  • Ingame building system?
  • Mob scripting system?

This is just a few out of a huge collection of details you have to ask yourself before you even begin to code. I recommend heading over to MudConnector.com and join in on some discussions.
I've been MUDding for about 7-8 years, been an administrator for 2 and been coding them for about a year and a half. Detail is key if you want a good game, most fail within the first month if not the first week.

If you have anymore questions feel free to PM me or shoot me an email.

Comments
Great information

What is the theme going to be?
-scifi adventure (not really combat oriented)
Automated or Manual combat system?
-manual if any
Online? (will you need to code sockets?)
-not yet
Encryption for passwords? (SHA256 recommended)
-not yet
Room based, grid based, or overworld?
-room
Quest systems?
-mission-progress-tracker? yes
Ingame building system?
-whats that
Mob scripting system?
-spawning? yes

i really want to know the good approach to all the issues mentionned even if it werent a MUD project. I think the questions are very general.

(Was sent in a PM, I figured I might as well post it for searching purposes)

Right from the start let's differentiate between the different types of text games. We have:
MUDs(Multi-User Dungeons): These are the bread and butter of the hack and slash genre of text games (most people play these). They have a Intermediate to small amounts of story for players to go on and focus on raw fun.

MUSH(Multi-User Shared Hallucination): These generally have no combat system to speak of and are solely for RP(RolePlaying) These are probably the second most popular

In both cases they focus very heavily on player interaction. If your game is not online and doesn't provide that interaction then the story, every room, every item, every mobile must have extremely in depth descriptions to make up for it.

Well what you want to write is more of a Zork clone with a sci-fi twist. The whole point of a MUD is to be a MULTI-USER Dungeon.
Manual combat is much harder to code than automated combat, room-based areas is definitely the easy way to go, overworld being the next easiest and grid-based has only been pulled off successfully in one MUD that I know of EVER.

By in-game building system AKA OLC (OnLine Creation), will you allow other people (most likely admins[imps, immortals]) to create areas, items, mobs directly in the game?

By Mob scripting I mean a scripting system in which each mobile can potentially have a script attached to execute certain actions on certain events. IE.

entry_prog 100
    if level($n) > 50
       say Why hello there, $n
    endif

would create a program on a mob that would greet a player every time they walked in the room if they were above level 50.

Spawning mobs is just an update system that should be inherent (Updating MUD time, refreshing areas, cleaning up garbage, etc.)

As for the mission tracker, having one main quest in a MUD severely limits a player's potential experience in the game. There should be many things to do. Some people like hack'n'slash and hate questing so you have to accommodate, some people love questing but hate hack'n'slash so, once again, you must accommodate. Other people love to stay with the main storyline, create incredibly in-depth backgrounds for their character and just roleplay, without actually fighting or questing(Though this is more grounds for a MUSH or MOO)

There are so many more ways to go about creating a MUD if you are inexperienced, most MUDs have hundreds of thousands of lines of code. I recommend you get familiar with how current MUDs work (it takes a long time to learn the in's and out's) by either downloading a codebase and working with it or by playing a MUD.
As I mentioned before ftp.game.org and MudBytes.net are great repositories for current codebases. If you want to play a MUD, there are a couple I play on that I could help you out with, just ask me and I'll send out the addresses, otherwise you can take a look at MudConnector.com which currently has about 1650 games I believe.

This article has been dead for over six months. Start a new discussion instead.