Text RPG Design Thread [1 new, on: Screenshot, working cmd]

[TomS]

No. Sorry.
I was just explaining why I recommended something I previously said wasn't a good idea.
I wanna help as much as I can, so I just wanted to remove the tiniest piece of doubt about my intentions in your mind

People always want to get taken seriously. And sometimes they don't.
And sometimes it's hard to see (especially in written form, and furthermore especially when a not-native speaker is involved). And then they complain.

This is a public forum. Maybe someone stumbles upon this thread and to him the difference is not quite so clear. Then he'll be thankful for one or two sentences more than necessary to clarify some things.

Don't think I'm a serious, serious man, who never laughs

[Zach]

Nah it's cool, I just wanted to make sure you weren't annoyed... cause this thread would suck without you

[Zach]

Not much progress going on lately.. I've been side tracked with general surfing habits, and working on organizing my audio library and stuff.. Sometimes I do sit down intending to code, but then I get hit with tiredness and end up just dozing off for an hour while thinking about what I was gonna code...lol

Aside from fussing with the IDE Font & Colors to something easier on my eyes, I have written an additional supporting Structure for my main Room Structure, which hopefully will let me do some cool things I have been planning on doing.

Code: Select all

;// ===========================================================================
;// Special Room Properties.
;// 1 = ON
;// 0 = OFF
;// For: block_combat, magic_debuff, lights_out, exposure_damage
;// ===========================================================================
;// move_penalty & entry_requirement both work on a 0 - 5 scale.
;// 0 = OFF, any other value indicates a requirement be met.
;// ===========================================================================
Structure Room_Environment_Structure                                      ;// Environmental and other Properties.
  block_combat.i                                                          ;// Prevent any combat actions by all Entities.
  magic_debuff.i                                                          ;// Debuff / prevent defensive magic casting.
  lights_out.i                                                            ;// Require external light source to see properly.
  exposure_damage.i                                                       ;// Player takes damage from exposure to elements unless protected.
  move_penalty.i                                                          ;// Player suffers movement penalty via extra Round Time.
  entry_requirement.i                                                     ;// Player must meet a size requirement to enter the Room.

As you can see most of it is pretty standard stuff that has been thought of before. However I think the most interesting and challenging effect for me to implement is the size restriction. This is going to tie in with the racial components of the Player Character, and will also have influence on things such as combat and potentially some environmental interactions as well (manipulating objects or NPCs). Some races will be large, some average, and some small.. So while the average or smallest races might not have any problems aiming at a particular spot on a creature (in combat), obviously a larger race would lack the finesse and dexterity to say, aim for the left leg of a giant rat, in the middle of a demanding task such as combat.

Size & Strength can also play into general concepts such as encumberance and how much a Player could carry before they start to see penalties applied to their actions (slower movement, harder to dodge certain attacks, etc).

I'm moving closer and closer to the realization that I really need to start building my World Builder application, even to do simple Alpha Test Compiles of the Engine. I am starting to lose track of things, and find myself reviewing my code and updating comments more than adding new code.. Especially with all the ON/OFF and sliding scale integer flags I am starting to use, writing data for a test session of the game world is going to be nearly impossible to get done by hand without introducing bugs.

I'm also going to have to do some clear thinking about combat & general world mechanics as related to ideas such as limb interactions. But I'm also still thinking about the possibility of having a party based system as well, and how I would represent that on the screen. Party based combat is going to generate too much scrolling if done in the traditional MUD sense. Where you have a multiline attack description, additional displayed information such as die rolls and stat values etc.. Single player vs a couple opponents and its not much of a problem, but multiple parties versus each other? I just think it will generate so much scroll the player won't actually know what is happening; just as can happen during intense large participant combat scenarios in MUD games.

One brief idea I had was to mimic somewhat, the console or traditional CRPG battle screen, in that it is a fixed screeen with combat done in rounds, and it is updated every so often. I have some neat ideas for how it might look, but I would have to solve the issue of changing out the process that is writing to the TextBox (which remember will also be doing color/font parsing, and scrolling in general navigation / interaction mode).

I would have to maintain a separate "buffer" for general world activities, and then switch to a different "buffer" strictly for something like a combat screen. Scrolling could work in purely turn-based combat, but I'd like to keep a more real-time feel to it if possible... Having simple "turns" where each side makes decisions for all party members, before giving up control for the Round, might work.. But I'm not sure I like it too much. Some MUDS kind of do this for their Shopping interactions.. i.e you type something like "order" and you can then interact with a menu that can be repeated, and you select by number, but you receive no outside stimuli while you are within the "Store System". The screen scrolls with your choices and you get feedback from the store, but that's the only thing you can interact with until you "leave the store system".

[Zach]

************************************************************************************
I know some of you like to skim, but please read this post entirely before responding.
I have many questions in almost every paragraph
************************************************************************************


Well I'm approaching the point where I need to build a skeleton GUI (Just a window with the Text Display gadget and an input bar for commands - peace of cake, not the problem).
I have most of my basic Structured prototypes done, so I will be able to house the data I need to at least build some rooms, and make a few items to play around with and experiment with parsings. I just have to review and finish up my RTF parsing code for the main Text Display. Then build some internal functions to handle Database loading/saving (can't test what you can't populate!) and setup a rudimentary printing function to pass data to the Text Display line by line.

However I am new to both Event Driven GUI programming, as well as Threaded programming, and this is where I am afraid I will stumble.. I understand that if I do something CPU Intensive, in the same thread as my GUI it will block the GUI from updating.. I want to avoid this using threads, right? So even if the user is 2 sub menus deep and has an option window open, if the screen is updated (and NPC walks through or something), I want that to update without delay..

I really don't know how to visualize the logic in my head at all.. And this is my concern. It would help me out if someone could give me some examples of basic threading, and threads communicating with each other if possible; I'm afraid this might involve pointers (my arch nemesis!!!) too.. I will try and outline a scenario, so maybe it will help the person writing the example to explain to me, and help me to understand what they are saying..?

I only know how to build a loop inside a GUI's Event Loop, like all the examples that show how to make a GUI and "keep it open".... Is there a differen't / easier way? Or are the threads ultimately launched from inside the Event Loop, as well?

Scenario: (i.e This is what I want/need to do)
--Non-Blocking GUI
------On Demand Parsing (A command needs to be parsed immediately, including any printed feedback to the player, even if an intense calculation is running)
---------| Player commands must be given CPU priority, especially in combat
---------| Monsters in combat with the player must get equal priority for A.I calculations

----(Background Tasks)
----------|Preloading / Saving tasks (Potentially bubble loader, otherwise periodic updating of the database on the current state of the game)
----------|Periodic Junk Item Cleanup, i.e "Janitor" (Iterates Rooms which have Items on the ground that are XX minutes old, deleting them)
----------|A.I Operations
----------------|Monster population control (spawning / despawning of monsters based on player location and Monster death rate)
----------------|Spawned Monster A.I (Deciding whether to move to adjacent rooms, or if actively in combat whether to use an attack, call for help, or flee)
----------------|NPC Movement Control (Move any scripted NPC's (haven't figured out the scripted part yet), decide to move any "wandering" NPCs to the next room, etc)
----------|Other Stuff like Quest Monitoring/Timers, etc.

I'm sorry, I know that looks like a lot.. I'm not asking you to write the code I'm just asking you to give examples on how I would approach the tasks using Threads, how to assign Priorities, etc!
Something I'm interested in, is Time Slicing. I think it would really optimize the way the Engine works? Like the Periodic Database operations, Cleaning up a few Junk Items on the ground, deciding to move an NPC or not, those will likely only take a few nano/milliseconds right? So if I could Time Slice them and say "Don't spend any more time than 15ms on this task unless you have spare cycles" that would be pretty neat.

But then again, is that really needed, since I am using threads? Would the OS take care of giving the threads slices of time, and be more efficient at it?
One of my chief concerns is, the game remaining responsive to the Player at all times. Also the Text Display needs to be updated properly, almost always in a first-come first-serve basis; i.e If a Player is in a Room with a Monster and that Monster decides to attack but the player decides to keep moving, or was just passing through the room on his way somewhere else, the Attack needs to be displayed in that room and that room only, even if the player was only in there for a split-second. I don't know if that might involve a write buffer or not, so that things can be printed in the proper order... Or if its not really needed..

Keeping all the above things in mind. Would it be best to have a logic loop that spawns all these threads, or to open and maintain threads that process information passed to them as needed, and then passes any return information back to the screen to be printed, or that updates variables /lists etc?

I'm not sure how much inter-thread communication I will ultimately need, but Threading as a whole is a new concept to me so I really need someone to hold my hand with some very basic examples demonstrating how to do different things, and then how I might tie them together.

I will greatly appreciate any assistance that those experienced with Threading can provide, to set me on the right track.. In the meantime I will do my best to understand the Help documents.

[TomS]

>>I understand that if I do something CPU Intensive, in the same thread as my GUI it will block the GUI from updating

Not necessarily.
You just have to do everything after you made sure there are no more events.

Code: Select all

Repeat
event = WaitWindowEvent(#TimeOut)
If event
    Select event
        ;Case...
    Endselect 
Else
    DoStuff()
Endif

You just need to make sure that you don't do too much in DoStuff().

This will hold up your gui, ofcourse:

Code: Select all

Procedure DoStuff()
    For a = 1 To 100000000
        Delay(1)
    Next
EndProcedure

This won't:

Code: Select all

Procedure DoStuff()
    Static counter.i
    For a = counter To counter+10
        Delay(1)
    Next
    counter+10
EndProcedure

This is useful for loading data etc. While the player is still reading the first lines of your intro text, each 200th (or however long one whole run through the loop takes) of a second a part of the world is loaded.

But you've seen how fast a less complex operation, like comparing a million integers, is in the last posts.
This can be done at once and the user doesn't even recognise a 20ms or even 100ms delay on a slower machine.
It's not a FPS where every ms the mouse doesn't move could cost you your life.
So threads are imho an unnecessary feature for a simple text based RPG.


>>...the Attack needs to be displayed in that room and that room only, even if the player was only in there for a split-second

Are we not talking about an Text RPG anymore?
Because any other types of games might have a different way of solving things.
How can you be in a room for only a split second if you have to type "Go North" or "use exit 1" etc...

Anyway. You are in the room so the monster hast do decide to attack while you're in the room.
The parent ID of the player is the roomID. After you type "leave room" and hit enter the roomID changes.
At this point the monster in room is either disregarded or "asked" one last time if it wants to follow or not.
If you're using threads and you're not doing it properly, there's a chance that the monster thinks you're still in the room but you really are not.
But if you don't use threads you have a linear structure and no such problems. Everything in the room "receives" the event that you left and acts accordingly.

I can't help much with the rest of the thread, since I have no clue about threads. But you should probably open a new thread (in this forum that is) to ask those questions as you might reach more "pros" with a thread-specific thread

[Zach]

I appreciate your thoughts TomS.

But I'm still interested in Threading, because while a Text Game may seem simple, and Perhaps my first "Final" version of the engine will be simple, I may want to build in based on threads, so that I don't need to do a huge rewrite later on..

Ultimate I may decide to progress the engine have to a multi-threaded, server based component, for multiplayer. I know a Text game "seems" simple on the surface, but the truth is that under the hood they can be very complex beasts with hundreds or thousands of calculations per cycle happening. This is especially true for Multiplayer, since you are dealing with potentially hundreds of people issuing commands at the same time, plus the AI for all the NPC's and Monsters going on.

I actually re-opened my GemStone IV account yesterday.. Partly for inspirational purposes, and partly to see if I could get into playing again. The game does not have the population it used to, for sure.. Currently there are about 260 players online, however its not peak hours right now.. I think we may have around 500 or 600 then, at the maximum (the population took a big hit a few years ago and hasn't really recovered from what it was).. Back at its most popular time, there could be anywhere from 1,000 to 2,000 or even more players logged in at once and the lag would really show during those times.. IIRC the machine that powers it is a Dual Xeon running at 450Mhz. Not impressive today but certainly beefy for a Text Game, and pretty powerful back in the day.

Now I have no illusions about how many people would ever play my game, running on a multiplayer variant of the Engine.. But I still would like to be prepared so I don't have to worry about it in the future.. Even if it was just a couple of friends getting together via a server running on one of their machines, it might be a slow machine or something.. So you never know.

The combat system is going to be very intricate and involve a lot of math, so I have no way of knowing what the average CPU load is going to turn out to be, with A.I calculations and everything. So I'd just rather be safe than sorry, if possible. This is almost the farthest I've gotten in any decent programming language, so its all been a learning experience for me. I definitely want to complete my Game Engine, but I want to do it "right", and build in some future proofing as well.

>...the Attack needs to be displayed in that room and that room only, even if the player was only in there for a split-second

Are we not talking about an Text RPG anymore?
Because any other types of games might have a different way of solving things.
How can you be in a room for only a split second if you have to type "Go North" or "use exit 1" etc...

Yes, we are still talking about a Text RPG However, I think you are thinking more in the Text Adventure mind set, where things do not happen so "fast"... In a MUD, it is common to have command shortcuts, as well as simple keyboard macros to make life easier, since you have large areas with lots of rooms to navigate through, just to get to a specific area you might want to go..

I plan to have the Numeric Keypad macro'd, so that it automatically sends movement commands to the game.. So you hit "6" on the keypad 5 times in a row as fast as you can, and you will move through 5 rooms in the Eastward direction, or as far East as you can go before you are stopped.. So it is quite plausible that just passing through a room for a split second (on your way to your actual destination) you may get attacked by a monster who happens to be there, and sees you the very moment you enter the room.. It doesn't happen too often, but it does, and sometimes can lead to death if you are not in a defensive posture; most in GemStone refer to it as a cheap shot. But its just part of life in a MUD like GemStone..

So yes, while I may be building a "Text RPG" the style is very much influenced by MUDs and how the behave.. I am trying to recreate a single player environment that can somewhat provide the broader "multiplayer experience" and level of interaction you would find in a MUD.

For one thing, I don't think this has really been attempted before.. So I think it would be neat, especially if I can later work-in a multiplayer component that allows a group of friends to have their own adventures together, or maybe even run their own server for public players to use.

[TomS]

Yes I wasn't aware that such fast movements are possible.
However you still have to "go" through the rooms.
In order to process 5 keytrokes you have to run through the Mainloop at least 5 times. Each time you simply check for things like monsters or other holdups (broken bridge etc).
At this time you don't even need to check what kind of holdup it is.
A simple #True / #False check will do.
There's plenty of time until the player realizes he's not in the room he wants to go but in a room in between his starting point and destination and there's a holdup.

As for multiplayer.
You don't need to parse anything on the serverside.
The client does the parsing and simply sends an integer command UID.
All the server does is checking if there's an object/NPC/other player to interact with.

[Zach]

That is a bad way to design multiplayer, because you have no way of controlling the environment at that point.
You have no way of knowing if a player is cheating by manipulating values, etc. So it is actually imperative that calculations and command parsing be done on the server, and the Client only serves to reflect what is happening on the server, without any way of influencing it beyond legal player commands.

That is why the only way to actually "cheat" in a MUD or MMORPG like World of Warcraft, is to exploit a bug on the server.. Because all player data, and all processing is done on the server. All the client does is relay information about where everything is, update chat boxes, and of course tell the GPU to Render the graphics.

As opposed to an FPS game like Call of Duty, Counter-Strike, etc.. Who have to resort to client-side anti-cheat applications like Punkbuster, etc.. Because the only thing the server really does is relay the positions of players to each other.. All the hitbox stuff and everything is done on the client PC, so you get stuff like magically avoiding bullets, or running super fast, that the server really doesn't know anything "fishy" is going on, without an external client like Punkbuster, which can still be defeated by a skilled cracker.

[TomS]

Only the parser.
Instead of "Take sword" you simply send "1 77" after parsing on the client side.
How would you cheat?
The server checks if there's a sword with the uID 77. If yes than the player gets the sword, if not, then not.
It just tranfers the work of parsing jibber-jabber strings to actual commands to the client side.
If the player enters rubbish like "dfknz roi" why bother the server with this stupid "command".
The parser has to check if a command exists and what to do.
After that it's the work of another module to verify the correctness, eg if the object exists, is it locked in a save? etc...

[Zach]

I suppose so. It's academic at this point though. I'd rather not take the thread in that direction just yet.

[Zach]

Another (simple) question..

The way I am structuring my code tree, I am trying to keep things separate, so I'm not pouring through overly huge files to get to something specific.. Although I'm not sure if I understand how the GUI will affect all of this.

I'd like to keep it in a separate file (I also have a separate file, where my RTF parsing code sits), and use Procedures to call stuff. However with GUI code this becomes confusing, or at least to me it does.. I almost wonder if it wouldn't be easier on me to keep my GUI code and other stuff for the logic loops, all in one file, the "main" project file (compile target), which includes all the other source files in the project.

Or maybe I am over-analyzing any potential problems, and calling procedures from within the procedure that creates and keeps the GUI on screen?

Anyway, here is my current tree structure.. Should be able to tell others if it will work or not..


Root\
---------\Structures\Item_Classes.pb
---------\Structures\Player_Classes.pb
---------\Structures\Room_Classes.pb
------|Database.pb
------|Main.pb
------|Parser.pb
------|Gui_Windows.pb
------|Gui_RTF_Parser.pb


The idea being, all files are tied together through "Main.pb" with Xinclude statements, and I would call any Procedures from inside that file, whatever they may be. Making up my main loop with it. Can I do that with GUI stuff? i.e separate the GUI creation code, while keeping the Repeat/Until Event Code in the "Main.pb" file?

[TomS]

Yes, you can.

Code: Select all

;GUI.pbi
OpenWindow(0, 20, 20, 300, 300, "", #PB_Window_SystemMenu|#PB_Window_ScreenCentered)
ButtonGadget(0, 5, 5, 100, 20, "Button")

Procedure MyEvents(event)  ; <-- Maybe a macro would be the better choice here^^
	Select event
			
		Case #PB_Event_CloseWindow
			End
			
		Case #PB_Event_Gadget
			Debug "Event_Gadget"
			
	EndSelect 
EndProcedure 

Code: Select all

;Main.pb
XIncludeFile "gui.pbi"

Repeat
	MyEvents( WaitWindowEvent(20) )
ForEver 

[Zach]

I recently got my hands on an electronic copy of "MUD Game Programming" by Ron Penton, on the recommendation of another GemStone IV player. There is lots of good stuff in this book and it also covers things like multithreading and networking, and scripting (integrating python).

Granted it's all in C++ (typical...) there is lots of good info to glean. Plus I got confirmation that I'm doing most of my stuff the right way already, so that's good to know.. I also got my hands on a couple books on Computer AI for games, hoping I might learn something there.. It would be nice to have NPC's that are minimally restricted by rules and learn the rest themselves, plus adapt to the Player and the environment.

The biggest thing I have taken from this book so far, is the idea of logic modules. I'd really like to do something like that I think.. Basically they are scripts that you attach to objects/npcs/players and they execute when certain things happen.. Mainly helps to reduce wasted memory and code.

[Zach]

Long time no post for this thread

I haven't actually worked on any code for a long time, due to various reasons.. One being I've had 30 hour-ish work weeks the past couple of months, as I'm helping cover for a co-worker out on medical from a bad car accident.. The other is my computer is in pieces, because of some upgrades I got, and I've been too lazy to put it all back together since I have everything I need now! (Was waiting on an extension for 8-pin CPU/EPS power cable, my PSU's is too short for my new case)...

That being said, I got a new core system.. Phenom II x4, overclocked to 3.5Ghz Hopefully I can play around with some scalable multi-core programming one day... Anyway

I have been reading up on some programming books and currently having a good read through "Game Coding Complete, Third Edition" by Mike McShaffry. It is a really nice book that looks like it will be talking about a LOT of things I have had questions about, from a fundamental design/system architecture standpoint.. Even though it's examples are in C++ I am really hoping to take the concepts and apply them to my PB projects more so than code.


Two things sparked my interest so far (not very far into the book).. The topic of Random Number Generators, and also the idea of building Multiplayer into my Text RPG Game Engine from the start.. I'm nowhere near the point where I would implement either (and the RNG would be easier for me by far) but I had some thoughts and ideas I wanted to bounce around..


RNG:
I'm sure most would probably tell me that the RNG provided by Purebasic is sufficient enough (I'm fairly certain it provides one anyway, haven't looked for it yet) but I'm curious about making my own, and keeping it as random as possible.. I don't need to worry about saving/loading the Seed with a game as the world itself is meant to be persistent in that no experience should be 100% repeatable. But I definitely want combat to be random every time. The book discussed the concept of using several RNG's for different systems (Loot table, Combat, Random enemy taunts or other random dialogue, etc.) There was a joke about including a piece of hardware that uses the decay of cesium which I didn't really get (does cesium decay randomly? I thought all radioactive decay was a consistent predictable time, based on the element in question?) but anyway I was wondering about using some arbitrary procedure to randomize the seed on every roll, or at least create a "Seed" table that could be cycled through.. Like using the execution time of a simple math expression, or getting a directory listing, or something mundane like that.

How complex does an RNG really need to get to be fair, but difficult to predict/manipulate in the players favor (not overly concerned with hacking/cheating, but still.. the more random the better).


Multiplayer
This is an interesting topic in itself. I always liked the experience of meeting and making new friends when playing MUDs online, having adventures and all that. So I would like to be able to do multiplayer although I fear I am in for a long, hard road as I know nothing about Networking, sockets, packets, TCP/IP & UDP, etc. However I really do want to try and make my game cross-platform so at least people on both Windows and Linux systems can play it.

These days it seems like multiplayer servers are actually built into the game client, so one player can act as a "host" server, while still playing. In some cases it seems like the game itself runs in server mode even locally, and the local client "connects" to it.. I saw this in Sacred 2 I think.. I remember playing single player and it would still give message such as "connecting to server" etc.. This idea intrigues me and I would like to explore it for a couple reasons.

One is that the book itself, when discussing various ways to design systems and link them together, uses the concept of "Views".. The views interface with the game logic by use of commands (as opposed to manipulating variables directly). So you would have a Player view for the screen the player sees, and you could also have a view for the AI to respond to events and do some logic then send commands back to the game accordingly, and of course you could have a remote-type view for a player on a Networked PC somewhere.

I was thinking if I could design the game like this, where it had a set of interface commands, etc that the client can send to the game (either through GUI interaction, or passing the input string on to the game to be parsed by a command parser, like a MUD would parse commands from a logged in player) it would make cross-platform easier for me? I stand to reason that I can do work on the core of the game which runs as a server, and connect to players via local or remote connections; This would leave me free to concentrate only on the Game Client itself, and I could develop a Windows client/server, and a Linux Client/server. Either client can connect to either server, so a player hosting multiplayer on a Windows box can connect with others players whether they are on Windows or Linux, or whatever OS... as long as a client exists for that system.

The client and server would just be sending/receiving packets of data that should be OS neutral anyway so it could work out nicely, depending.. I could make a remote session completely remote in that it receives everything from the Host server, or I could make it share only data that has changed (So it will update the server if the player moves to another room, and likewise all other clients will get that update, but the actual room description for the player who just moved, could be fetched locally instead of having to be sent from the server, like in a traditional MUD).


The thoughts are kind of incomplete but just a starting point for discussion.. I imagine it will be a but more complicated than I have lead myself to believe.. But my biggest concern with cross-platform has been how to do a Windows client and include it with game code, and interface the game logic itself with the client, while also doing a Linux version... For some reason I think there would be more rewriting of code if I tied clients into the game logic than if I just used a local client/server mode, with the option to allow remote connections as well.

[Zach]

Ok so the whole Client/Server/GUI thing was more of a brain fart than anything. I clearly over-analyzed the problem and made the solution more complex than it needed to be.

Granted I can still see merits in the the design itself, I think I can still retain those merits by using the "View" concept Internally instead of also thinking about it externally..


Question:
In Theory I should be able to get my code to compile on either Windows or Linux by keeping the actual GUI code in separate files (Win_GUI.pb & Linux_GUI.pb), yes?
As long as all the other code has no distinct outside Windows/Linux dependencies (no outside DLLs/code, pure PB code) and I don't use any commands that only work on one OS.. It should simply be a matter of using Compiler Directives to make sure the appropriate GUI code compiles for each target?