xx: Added line or note about changed removed line (e.g 02: I added this and deleted this cause blah)
// To be removed (will be deleted in next version, tis allows me to keep track of changes done)
03: More reasearch into freeBSD
03: Clearing up on some thoughts
03: Extra thoughts on help command
02: Changed desicion and going to run and develope code in FreeBSD.
02: Revoled some self disussions
02: Futher Explainions on others ideas, desicions.
01: For running server on windows 2003 server.
Two Core Codes - This is to keep two parts of the process seprate and allow for easier
updating and Understanding of the codes. It's will hopefully also allow me to be
able to "switch" out the cores. Say in the future I wanted to do a information server,
I could easily just copy the Core Server Code and then create the information code.
Or I could recreate Core Server Code with something different without having to
touch the other core.
Core Server Code(CSC) - Is be the code responsable for running and keeping the server running
We'll offload the MOO/MUCK/MUD programming into it's own Core Code
Core MOO/MUCK/MUD Code(MMC) - Is responsable for dealing with the data processing side,
aka the game world.
//Note: Core Codes does not mean that they are all put together into one core file.
// It's more of a grouping, it's also a way of being able to see which files belongs
// to which part of the core.
// e.g. SocketsCSC.cpp, ProtocalCSC.h or MooBasicMMC.cpp
Note: Core Codes does not mean that they are all put together into one single file.
It's refers to grouping the program process together and it's also a way of being
able to see which files belongs to which part of the core e.g. SocketsCSC.cpp,
ProtocalCSC.h or MooBasicMMC.cpp
implentions plan (In no order)
- Think about treading for other process, e.g - processing revc commands,
Might just be simple to just get the treads to do it
- FreeBSD handles treading/processing is a different way. I do need to do futher
Research into this but it's lot more simplier to implentment then IOCP and easier to
change in freeBSD, if a better solutions has come up.
- When mutli-treading/process data is not shared between parents and child
unless using critial section which uses up memory and resource and even thou
they can control each other to some degree, they run indepentendly to reach other.
Debugging multi-treading is also tricky due to this independent nature.
Extreme care must be taken of how data is processed in each tread, this
need to be well thought out. This is also applies to treading under windows.
- This function is used in BSD, an improvement on the select() in sockets, has a much better
performence over select()
- The downside is that it will kill portablity however I can later add select()/poll() and so
on. But for windows, the real performances is to use IO Completion Port.
- Signals is part of POSTIX(or however that spelt) and I will need to be able to deal
with theses signals, like SIGUP to re-read config.
- Do I need this for MOO/MUCK/MUD Clients?
- I could test for data in OOB
- RFC can be bloody confusing -_-
- I'll add this into Core Sever Code but allow it to be turned on/off if needed for
- Configations should be stored as a text file, specially configations that relates
to the server start up. Other configs, I will stick into database, this should allow
for config to be modified in real time.
- In case of database corruption, or config being lost, I should allow configable
defaults in the text file.
- If I ever need to add more protocals, I'll put them in Core Server Code
- Allow to be turned on and off, May have it as a configuration option
- Group All protocals together into one file
- Will have to learn it sooner or later and the idea of it has slowly grows on me
- It will be useful for this project and it does always seem cleaner when projects are in classes
And it will allows me to reuse, and improve on code without actually causing a
big effect elsewhere. Just takes some bit of getting head around to understand and use
- Think about what classes and methods I will have
- Expections I should build from the start, before it start getting complexs.
This will give me huge control over my errors, and it's important to keeping server
running and not fall over unneedlessly.
- Allow the Game world to be built in it's own program language from within
- How would I build the language, in what way.
- What Commands would I need and what actions
- How should I store progamming that is created by users and read from it?
- Error Checking, Secuitity/Safety
- Idea is so that NPC AI, Monsters AI, Objects interations and so on, could be created.
- Allow basic functions to be altered, such like the weather. (e.g. say if you wanted
to add a werid weather where it rains frogs)
Core MOO/MUCK/MUD Code
- Unlike Programming, this will be repsoneable for BASIC actions, clearly
basic actions should be inhereted into programming
- What actions would be considered to be a basic action?
- maybe for things geneic or background workings that either should not be programmable
or things that just make up a basic gameworld //like the weather, sun and moon phases.
03: like ground type, weather type.
03: reason // weather, moon/sun phases while basic, don't have a fix patten. (aka,
the world might have two suns and no moons.)
// - Where should help command go, I think here because it is at least, a very basic command
- There's two basic helps, one I shall call Help, to relate to game usage, and other man,
for MUD Programming usage/syntax
- provided easy access and allow it to edited, updated and added, inside game and outside
- Our data storage
- I may use a different database and implent a OOP DB but may not.
This requires futher research
- Backups and how would I pervert gameworld from losing data in case of unplanned downtime.
03: Look also under downtime handling
- Should this be part of core server code or not? Clearly, I'll should only ever have one
or two connections during the time server is running.
- Question, should I added database connection handling to CSC or MMC. If I add it
to CSC then I could added on/off for it and it allow other core to have DB without
recoding it over and over but would it better to code it with MMC, closer to core
that need it and clearier, easier to visual data interaction.
- Note on connection, I must be careful about permissions to Database. Damage Limition.
- How would I protect the server from all types of attacks?
- Most text are fine as plain text but what should I do with user name and
password? Does the current MUCK/MOO/MUD Clients have some sort of Secuity option
that I can use to keep password safe at least?
- Damage limition, allow only what is needed.
- FreeBSD has this feature called JAIL, tis a niffy Secuity feature. It only allows
process to interact with process within it own jail. Even if it ever gets superuser
powers by a hacking attemp, it can't interact with anything outside the jail.
- How should we deal with things like open proxies, and banned players(note on bans,
what ban levels should I have? Of course, there's perm and temp, how long?
second chance? character, account, ip level ban?)
- I want to be able to keep track of what's going on within the game
It'll allow people to keep track of any roleplaying chat.
- Maybe add ways of seeing logs differently, e.g, see/hide OOC chats
- Could store this logging in database and allow it to be accessable
from web frontend. This would make above idea more simple to implentment
and the logging easier to access then if it was stored in file.
- Discuess, do I want to hold this forever or delete when it's old 03:(how old?)
- Formatting, XML, RSS, etc?
- Also I want to log data transfers, connections, uptime, downtime, etc
For Statitics and debugging reasons.
- Store this in a single or one for each new day or store in a database, etc?
- Timestampped, must have
- Should I add a special formatting. It be a good idea, could possible create
an Another Program that can check and report as it happening, realtime data of
gameworld. Or Allow this checking to happen in gameworld, this mean I could
allow Admins or Mods to be able to keep an eye on what is happening within
the game world?
- What data should I be recording?
- There are other things that's worth logging for increased secuity, like db connections
Thinking about having a third set of recording so that admin could keep an eye out
for anything happening that shouldn't be, a hacking attempt or game cheat.
- How should I handle downtime for different situtation.
- Database downtime, I could create a small game world where everyone is together and
keep trying(allows questions to be answered in this way but requires effort)
or bounce connections with configurbale error(less effort but less player-admin
relationship) And in the meantime, keep trying to connect.
- I should allow for planned downtime, downtime notices broadcast.
- Whenever possible, I will try and save the game state, however should the server get
knocked off due to power lost, what recovery should be attempted?
- How often should I save game state and how old should gamestate history should be kept
(for events of corrupted game state saves, or for roll back in possible event of
PHP Second Frontend
- Characters Screen
- Second Signup
- Etc, Full details will come under PHP frontend workings, tis to be part of second phase,
second phase is most likely be after Core MOO/MUCK/MUD Code is in (or during)
- This is a two tier appoach, The first tier is the PHP and telnet server,
the second is the mySQL database.
- Being portable. It's not possible to be completely portable but I can work on
keeping it simple and easy enought to make the right changes to allow code to be
As always, feel free to comments any ideas and comments to my brainstorm that you might have. I'm happy to read them ^-^
Current Mood: accomplished