Okay a more complete and easier to read versionof what Ive covered so far is up along with some working sample source.
Im having a small problem with the formatting in that im getting way too much headroom before each table. if some HTML guru wanted to look at the page soruce and tell me how to fix that Id much appreciate it.
Btw I just noticed you mentioned “NPCs” above. I shoudl mention that gets a bit mreo complex and is a more advanced feature then I thought you were initially describing.
Typcially in an infocom game an NPC is a commandable invetory item. It may have its own state machine to respond to commands depending on how complex it is.
Yet now im joing java and not C, and I want to work with graphics, which is a whole new dimension and scarry. just dont give up… dont let yourself get offended by how long you take, program is hard… most people cannot do this, even a hello world program(because most dont try :D).
anyway i have dreams just like anyone else does, and i cant wait till i am in the middle of creating my graphical 2d civilization-like game ;D, it will be so fun if i can understand some concepts.
Wow, I didn’t know this thread would create so much conversation, but I am learning a lot and I am very encouraged to continue working hard on my game. I am currently looking at the TADS environment to create a game, and then I’m thinking about going from that design to convert what I create into java. That way I will understand much better how that type of system works.
Also Jeff, I am VERY interested in reading your blogs on FSAs and your step by step tutorials on using FSAs to create a simple text adventure game (at least it looks like it will be a set of tutorials).
Even just thinking about all of this I am having a lot of fun and I can’t wait to see what becomes of all this. I will be sure to post my game if I ever complete it so anyone can criticize it or whatever.
Anyway I hope to continue to learn a lot from this project and I appreciate all the help I’m getting from you guys. I hope you’re having fun with it as well.
My NPC reference was not intended to relate directly to creating a text adventure game but rather as another example of FSMs in games ( AI behaviour for NPCs ) so that the OP will understand that learning about FSMs has payoff down the road as well, not just in the context of a basic text-based game.
I looked at the html, and there’s an unnessecary abundance of br tags in there… like 2 after the paragraph, and one after each line in your table definition. if you’re unfamiliar with the html, br is a new line. so just clean up the html around the table blocks and get rid of the br tags at the end of each line.
You don’t have to map out every possibility like that. Viewing a text adventure as an FSM is a very abstract way of looking at it. I imagine that you could view any program you write as a modified Turing Machine, but you probably wouldn’t.
First, you’ve read Jeff talking about inventories. There won’t be a seperate states for which items are in which rooms. Instead, each room will just have an array (or a collection of any kind) of what items are in it. Effectively, each room has an inventory.
You’ll have options like “get apple”, but these won’t be modeled with a bunch of states. They’ll just move items from the room’s inventory to yours. You’ll also have options like “drop apple” if you have an apple in your inventory. That will just move your apple from your inventory into the room’s inventory.
There are some exceptions to that. There may be items you can’t pick up, and there may be items that burn you or something.
Second, there’s alot of things that you might do in one room that won’t affect any other rooms. For instance, in one room, you might be able to open a trap door, sleep in a bed, or search the fireplace (or whatever). Doing any of those things doesn’t affect any other room. So you can have one FSM for all the states within that room.
Then you can have one big FSM for the whole game. Each state of the FSM is another FSM representing what can happen in each room. What I would do is just have an FSM for each room and then have some sort of variable storing which room the player is in. This could be a problem if you want to add something special to a text adventure game, but then you’ll just have to adapt your design accordingly.
I read the articles - nice to see some more texts explaining concepts
I wasn’t going to post - since I’m sure there is a reason to all this - but I really don’t see the benefit of modelling a text adventure as a FSM - seems ok for moving around (it almost looks like the map) - but everything from that point on seems like pushing an square abstraction into a round problem.
Whats the benefit of using an FSM over just using a normal object model for instance?
I mean isn’t the object model for adventure games is beautifully layed out implicitly; This thread has almost inspired to go write an text adventure engine (like I haven’t got enough toys to play with right now).
As you migth see in the lates article, I actually am evolving towards an OOP model, but its still an FSA just a modular object oriented FSA.
The justification for this is that it makes the core concepts much easier learn. Its easy to get distracted by trying to actually code physical simulations of the world and a text adventure isn’t a physical simulation, its a textual one. To put it another way, a text adveture is a lot more like one of those “make your own adventure” books then like a world simulator. Thats a key distinction. In fact I strongly suspect thats where the original poster that kicked this all off went wrong and ended up spending a year on what is a month project at most.
It also gives us a useful language of tables we can use to talk about adventure design, even as we move away from actual tables in the code. It also makes the histyorical adventures that werent written in OOPLS (Infocom, Scott Adams) easier to understand.
Having said all that, i DO have a radcially different archotecture that is better suited to multi-player MUDS that Iintend to introduce once the disucssion of single player text adventures is finished-- but it will be muche asier to udnerstand in the context of the single player adventures then beign introduced “out of thin air” *)