Hello--I am trying to build a game for the first time, I have been playing text adventure games for my entire life and I think it is high time I try building one myself! However, I am a little overwhelmed by the magnitude of the minutia that is required to build the kind of game I want. Here's a few things--
1. I don't like option games, I highly prefer games where you have to type out yourself what you want to do. I know there is a delineation in terms for this, but I cannot remember at this time what that is.
2. I want to build in clever responses to a wide variety of plausible verbs. It is something I always appreciated about classic games ala the Zork series, is that almost every command I could think of had a unique response.
3. I like the concept of a health-system, but I would want it to demarcate the end of a day which would be replenished by sleeping. I tried to play around with the concept of this, but couldn't find a logical way to prevent the player from dying too quickly before you could type "sleep?"

Anyway, I wanted some advice on where to begin. Do you usually build the map first? Dialogue? Major plot points? I just need a jumping off point. (Oh yeah, and an actual plot...)

best advice is probably:

1. learn/know how to do all the coding needed for your game's features/aspects already before you start making your game, as it's not fun spending your entire time trying to learn to code in everything you need, when trying to make your game, learn it first before you start making your game. Already being a very good programmer helps vitally. If not already a very good programmer, this can take a very long time to learn ( have this problem myself).

2. get your entire game, everything about it, planned out first "on paper"; lots and lots of preparation makes for easiest game making.

3. always get as much as you can done every day, at least work on it and get SOMETHING done EVERY day, don't take a single day off, or you'll never get it done.

4. try to build a skeletal functioning/playable game from beginning to end of game play first, then go back and expand upon it. Get a working/playable game done first, then you can go back and grow/enlarge it into the game you envisioned and planned out. This keeps you the most motivated, as you can always play and see what accomplishments you've made toward making your game being completed.

-----------

as for your questions about coding (health and dialogue/description systems and etc), read the threads, guides, and libaries on this sites main forum, its 'library and code samples' forum-board, and the quest documentation website, and post threads/questions as you need them.

I'm not being disrespectful to HK when I respond to this in any way whatsoever, but I, personally, do things almost the exact opposite!
I think the bottom line is: to each their own. What may work for HK doesn't work for me and what works for me might not work for anyone else on the planet.

1 & 2. You'll definitely want to do the text adventure route when you fire up a new game. I'm in your camp with this one. I really only like a VERY small percentage of gamebooks I've run in to and those are likeable because they are UNIQUE and well written of course (see my reviews). Accounting for a wide variety of verbs can be done through adding verbs and custom built commands but it is certainly tedious - I learned this the hard way with "Xanadu 2". It never fails that I think I have thought of nearly everything and a beta-tester would bring it to my attention that their input should work but it didn't. But, in the end, it is very much worth the tediousness to do this. I have a hard time finishing a game when I keep running into the "guess-the-right-verb" to get something obvious done. Personally, I would encourage you to try and limit this happening in your games.

3. Jay just helped me loop a day in my game. After I understood his advice, I looked back and thought... "What was I thinking? That wasn't that hard." So, if you need help with that, ask on the 'Quest Forum' (or PM me) and I would be glad to help you set something up.

Here is where my approach to making games takes a wild turn... I know how I want to start and I know where I want to end - that's it. Then... I just write. As I am writing the game, I learn how to most effectively use the Quest Program (or at least through my first two games). If I tried to learn all the nuances of Quest beforehand (especially coding), I would never even get started. Too overwhelming. I needed to see some progress pronto so I just dove right in. Then I create sub-plots as I go that build up to my main plot, and whenever I need help, I ask on the forums! As far as mapping goes... well, in my first game, I just kind of added rooms as I went. In game two, I had a basic design laid out and created all of my rooms at once and jumped around to work on rooms as sub-plots developed. In game three, I am creating chunks of connected rooms, finishing the chunk, and building another chunk of rooms. I did NOT worry about dialogue until the player ran into an NPC. When they did, I added as many "cases" as possible, then quite often added more as I wanted them to respond to more asks/tells.

If you REALLY want to complete a full game, work on it when you get the bug to do it. If it turns into something you HAVE to do every day, you'll learn to regret it pretty quick. I haven't worked on part 3 of my series in about two weeks, but as soon as I get the bug, I'll go several days in a row and get a big chunk finished. There's no hurry. It's not like a publisher has given you a deadline, right?

Most people probably write/plan the way HK does. I think I am in the minority, but when I have limited way-points, it feels like the story is writing itself. Sometimes I feel like the story is revealing itself to me as I go and almost every time I love how it turns out. If I don't love it, I redesign.

As far as getting things done with Quest, when I started I was DEFINITELY NOT a coder (still am not), but the more I have used it, the more I have understood. If I could travel back in time, I would probably rely on the forums to guide me through a proposed plan I had in mind. I butchered so many sub-plots and now I realize the solution was much easier than the hack job I put together, but I didn't ask for help until I was neck deep in $h!t. That is one of the reasons I tried to put together a basic troubleshooting GUI-editor guide. I hope that maybe you can check it out and see if it is helpful. If it is, awesome! If it isn't, sorry! If you can find areas it needs improvement or additions, please point them out to me. If you need help, ask on the Quest forums as that is where most of my tutorials came from. The name of the tutorial is "Quest - Tutorials and Templates".

Anyway, long story short... My advice is jump right in, ask on the forums if you need help, check out the libraries (if you are comfortable using them), and please consider using my unofficial Quest guide (and feedback is encouraged!).

Good luck! Happy Gaming!

XanMag

Also...

https://emshort.wordpress.com/

read as many 'emily short' guides on game making as you can! She really helps with understanding game design concepts

Lighnagain wrote:
1. I don't like option games, I highly prefer games where you have to type out yourself what you want to do. I know there is a delineation in terms for this, but I cannot remember at this time what that is.

Text adventures, interactive fiction, or parser IF are what you mean, though there's been a lot of blurring of the terms with the rise of Twine. The sort of game made with Twine where you just click options to progress a story, what we call 'game books' here have always been Choose Your Own Adventures (CYOAs) to me, though they get called interactive fiction a lot now too. Most IF sites, this one included don't categorize them separately yet for whatever reason, so it can lead to a lot of confusion.

2. I want to build in clever responses to a wide variety of plausible verbs. It is something I always appreciated about classic games ala the Zork series, is that almost every command I could think of had a unique response.

Getting your game beta tested will be a big part of this, as you'd be surprised what people think of to try that you'd never have come up with yourself in a million years while playing through your own game. But just keep in mind this can turn into a lot of work for something most players will never try or see. And as a player, it's far more important to me that a game covers all the 'standard' verbs first...though as a long time IF fan I'm assuming you'll already know to cover your bases there. A variety of unique commands allowing you to explore the game world in more detail is great for adding immersion of course, but if the new commands aren't clued at all it's very easy not to realize they even exist.

3. I like the concept of a health-system, but I would want it to demarcate the end of a day which would be replenished by sleeping. I tried to play around with the concept of this, but couldn't find a logical way to prevent the player from dying too quickly before you could type "sleep?"

Dying because you go to bed too late one night is pretty harsh. One thing to keep in mind when adding things like this is whether they would add to the actual play experience, or just be an annoyance and a frustrations. That said, there's plenty of ways using variables to make sure the character doesn't actually keel over, even if you want to give them penalties or nag messages about needing to sleep.

Anyway, I wanted some advice on where to begin. Do you usually build the map first? Dialogue? Major plot points? I just need a jumping off point. (Oh yeah, and an actual plot...)

Like XanMag said, everyone winds up with their own approach. Personally, I write down a rough outline of the plot and major puzzles I want to include in plain, humble Notepad. Then go into Quest and create the map with placeholder room descriptions, moving from there to adding in the most important objects or characters and knocking out any vital programming bits, interspersed with proper room descriptions or whatever I feel like to give myself a break when I run into major difficulties with implementing something. Then I get busy IRL, distracted by a shiny thing, etc. and by the time I come back I feel more like starting a new project them completing the old one. (I uh, would not recommend emulating that last part there... )