Need some ideas (Engine Design)

[Zach]

Hi all.

I haven't coded in a long time, due to various reasons.. Free time / interest being the main sticking points. But I want to try and get things going again. I am trying to get started with some very basic work, as I have decided that if I am going to do anything reasonable, I need reasonable short-term goals.

Mainly my previous work consisted of prototyping a development tool for myself, using ProGUI, but I want to put that aside for the moment.
The first thing I want to do is get the basic engine for the game setup, which means doing the "rendering" (for lack of a better term) first.

Since I'm working on a text game, there is really nothing to "render", but I'm misappropriating the term anyway.. My current short-term goal is to design an implement the necesarry systems for the user to "load" the game. Meaning basic interaction with the database to display the game rooms and navigate through them.

As part of that goal, I got to thinking about the Engine as a whole. I don't really want to put myself in the situation of building the game in a few dozen files (as well structured as they may be) and then having to go back and extrapolate the Engine out of them..

But I realize I have little idea how to design an Engine, or how the process is supposed to work. I know there are half a dozen ways, but the reading I do rarely translates into productive ideas / results I can actually use. I figure it is best to start with the "Interface" or something like that.. Basically I want to decouple the engine from the GUI as much as possible, and use communication facilitating processes to allow the main program, and various sub-processes to communicate with each other, as well as talk with some form of universal input, and return output in a format I can universally adapt to whatever I want to do..

I'm not sure how to do that though.. I have little idea how to accomplish "passing" data and variables between functions in a simple to understand way (pointers??? ugh...).

In terms of how I see it working. Let's say I have a couple different "layers". An "I/O Layer" which basically takes input send from the command bar in the GUI, and returns output to the screen in response (but also outputs as a result of internal game events). The GUI sends its input to some kind of listener, and it decides where to dispatch it to from there (command parser, that one is easy enough). But lets say a creature decides to attack - how does it initiate an attack routine and what is it attacking? An NPC decides to walk North - how does it tell the game to move it?

Once that is done, if output is required (Tell the GUI to print the result of the Monster attacking the player, or if the player is in the room with the NPC, print "NPC walks away, moving north." etc)

Basically I need to come up with some kind of internal communications method, that doesn't involve writing some elaborate scripting language or anything complex like that.
If anyone can help with example is how this might be done, it would really help me out.. Hopefully it doesn't need to be anything complex, just something basic I can get an idea from and implement in my own way. I am guessing examples of easy, clean, ways of passing data between Procedures and stuff like that is going to be involved? Or can I do something different like user sockets locally on the machine? (i.e a "Fake" server/client interface?)

Here is a crude example, I guess?

Code: Select all

[GUI] -Player inputs command  "Attack Orc"
[GUI] sends input string to command parser
[Parser] -Ok I have recognized an "attack" command, with a target of "orc"
[Parser] sends notification to listener  "run the "attack" procedure on target "orc"
[Attack Procedure] -I got a message to attack target "orc"! OK
[Attack Procedure] Runs, verifies target is attackable,  runs calculations and needs to return output
[Attack Procedure] sends output result of the attack command to GUI
[GUI] - I just  received input from the game!
[GUI] Prints (formatted/parsed) output to screen

I hope I have the right ideas - and its just that I don't know how to implement it. One of the reasons I want to keep everything decoupled in this manner is so it makes modifying things easier. i.e improving the GUI without having to worry about changing how it handles input based on other changes in the game. A simple but effective example, I suppose.

[kenmo]

Hi Zach,

I can give you some general advice to start with... in the last few years I have been realizing more and more the usefulness of programming top-down... structuring your program very simple at the top, and breaking everything down into simple steps and procedures instead of having large, complicated 5000-line functions... (I have a procedure in my last game that is ~1700 lines of code... it started small but became enormous, in retrospect I should have written it much differently!) Basically, don't be afraid of having too many PIECES of code... as long as they are simple, figuring out how to write each part of your engine will seem much easier.

For example, a pseudo-code version of your main engine loop might look like this:

Code: Select all

Repeat
    
    UserInput = GetUserInput() ; whether this is console, window, keyboardinput, etc. doesn't matter here

    Verb, Noun = ParseInput(UserInput)
    If Valid(Verb, Noun)
        PerformGameAction(Verb, Noun)
        UpdateGameWorld()
        Print New Message(s)
    Else
        Print Invalid Message
    Endif

    UpdateDisplay() ; screen, console, etc.
    
Until (Exit)

You can always write placeholders while you get things up and running, like Valid() might always return #True (just remember to come back to them later!)

Now you might work on ParseInput(), which might in turn call FindVerb() and FindNoun(), which could search for a list of specified game keywords. PerformAction() would look at these, and either change the game state, or queue the message "You can't do that to that!", or something. UpdateGameWorld() would then handle events, timers, enemy fights, etc...... Each of these can break up into lots of quick sub-functions. (Many master programmers say all functions should implement exactly one operation or action, ie. don't cram the entire game logic into one RunGame() like I would years ago!)

OK maybe I'm rambling and you don't need tips on structuring programs, more about games specifically and how to store and process data and entities and such... well we could go into much more detail as you run into specific questions..... but I have to have dinner now.

[Zach]

Yes, it is more the practical implemention aspect I am concerned with.. I could "design" a "pretty" looking (functioning) game engine all day.


But its actually building it, settting up how the subsytems communicate in the first place, and how to share data and such that I am in extreme need of guidance on.