Obviously, anyone with any sense has something sketched up on paper, detailing what they want to achieve whether it be a simple list or a full blown map.

My question though, is when translating it across into the world of Quest, do you lay out all your rooms first then populate them and block exits etc..., or do you do it all one room at a time, not moving on to the next until you are certain that the one you are in is finished.

And how do you make sure you don't miss anything?


I have something in mind at the moment. It started off around a simple idea, but researching that idea has led it to branch out (which is good, because that in turn has lead me to new "rooms" I hadn't yet thought of). However, despite being a simple premise, it is becoming quite complicated to think about so I want to make sure that when it comes time to coding it, I get it right.

Also, on the coding front - is it better to download the Quest engine, or is the online creator good enough?

thank you.

My question though, is when translating it across into the world of Quest, do you lay out all your rooms first then populate them and block exits etc..., or do you do it all one room at a time, not moving on to the next until you are certain that the one you are in is finished.

I think it partly depends on what sort of game you're making, but (and I can only speak for myself) the experience of making my game has been a combination of the two. I began by sketching out most of my rooms on paper because the setting implied many of the rooms that would need to be present. I knew I wanted to make it an off-rails game, (meaning that most of the locations in the game are accessible from the first turn and it's how you interact with and explore the world that progresses the narrative,) so I knew I had to have my rooms laid out to begin with before populating them.

Once I had that as well as a basic concept and narrative outline, it became a fairly organic process from there. You have an idea for a plot line, then you start making the objects needed and scripting it. Then that will give you an idea for another plot line which you might need a new room for so you make that. Along the way you've created a scenery object which gives you an idea for a puzzle so you change it's properties a bit and incorporate it. You have an idea for a cool puzzle so you craft a narrative thread around it so that the puzzle makes sense within the context of your game. Then you go back and realise some of those rooms you built earlier were completely superfluous so you demolish them, or amalgamate them with another room. You delete an object you thought was essential because you've come up with a better idea. You realise that an earlier stretch of plot is ridiculous etc. etc. etc.

All of that has happened while I've been building my game and unless you've 100% thought of every stage and possibility for your game, it will probably happen to you to. Like all creative endeavours, you have to be willing to adjust your plans and vision as your creation takes shape in order to stay in tune with it. There's no use trying to force something in that you had originally planned even though it no longer meshes with what's eventuated.

And how do you make sure you don't miss anything?

Make a few different word files and document everything, no matter how trivial. Create a TO DO list for every long and short term goal from the creation of the ending narrative to the addition of a single line of script, and regularly add to and cross off from it. Write out the framework for your narrative, make a list of different puzzles and what you need to do to beat them. Note along the way what's been implemented and what is yet to be done. Before you know it you'll have so many things going at once that you'll forget about something you thought was obvious to remember so it's good practice to have something to refer to.

Test, test, and test your game. It's so easy to make a little error in your scripts that you won't notice until you try playing and get an error message. You won't catch everything, but that's why you should get some beta testers to have a look before releasing it.

In terms of making your life easier while using Quest, here are some tips I would give. (If you haven't used the editor before then they might be gibberish to you, but they might make sense once you start building.)
- Use functions where you can. Not only are they good for applying the same outcome to multiple, synonymous commands, but they're also easier to find and edit in the object tree than a script is to located in a tab somewhere.
- Use custom boolean attributes rather than flags in all cases where the object's state has ramifications outside the immediate script. (i.e. almost all cases.) It's easy to forget the name of a flag, but an attribute is always easily located in an object tab to remind you. They are also easier to refer to in expressions.
- Pick a consistent naming pattern for objects and stick to it. Use only lower case letters. You'll have an easier time in the long run.

Also, on the coding front - is it better to download the Quest engine, or is the online creator good enough?

Desktop version all the way. The online creator is good enough if you're just experimenting, but if you want to really work on it then the desktop version is just smoother to operate and I believe has a few features the web version doesn't (even if you don't end up using them it's always nice to have the option).

Cheers for the in depth reply, very helpful.

I played around with the old editor, around v4 I think. Also, I am no programmer, but I think I have grasped the fundamentals.

Just one question, what do you mean by " custom boolean attributes"? Can you give an example?

I think Liam means to just make your own boolean attributes, which would be in the GUI~Editor:

Add a~new script -> Variables -> Set a variable or attribute

AND~OR

Object (or Object Type) -> Attribute Tab -> Add Attribute

an example, via Set a variable or attribute:

orc.dead=false

an example, via Add attribute:

Object: orc

Name: dead
Type: boolean
Value: false

in Code View (in code) it would look like, for example:

<object name="orc">
  <dead type="boolean">false</dead>
</object>

// or you can put it onto an Object Type (in the GUI~Editor, it's under "Advanced" in the left pane ~ the "tree of stuff"), and then put that Object Type (via~as an "inherited attribute ", in the GUI~Editor it's called the same thing in the Attribute Tab of the Object, onto your various objects):

<type name="character_type">
  <dead type="boolean">false</dead>
</type>

<object name="orc">
  <inherit name="character_type" />
</object>

That was all great advice. Being able to axe stuff that's not working is hard, but totally worth it. I just ripped out a pretty core feature of the main game I'm working on now and replaced it with a different idea and it's so much better, even though I was really unsure about giving up the work I had done. Also that game made heavy use of game-ending timers when I came up with it, and looking back I remember feeling the same way when I took them out, and now I can see they would've made the game way too frustrating to play for more than a few minutes.

I do the multiple word file documentation thing too, and it makes keeping track of what you're doing with the game currently so much easier. I also like to draw up maps and floorplans for reference. Another trick I use is to periodically save as a new filename (mygame1, mygame2, etc), especially if I'm about to change something major or try something that I'm not sure about. That way if I botch it and save accidentally I can just load up the previous file and not have to waste a bunch of time on damage control. I learned that one recording music and it's really helpful for any computer-based project.

I'll have to keep the custom boolean attribute thing in mind. I can never keep my flag names straight, heh.

Always go with your gut feeling and let your imagination take flight for without it the great authors would never be! And never be frightened to experiment for if ridicule be your fear then you only have yourself to punish. Terry Happy Adventuring

Game Making is extremely challenging and is a lot of work!, even for the simpliest of games!

1. Story~Plot~Etc Writing (need to be a good author)
2. Game Design (need to be creative, extremely organized)
3. Game Mechanics and Balance (need to be a good mathematician to figure out perfect formulas, algorithms, equations)
4. Coding (need to be an excellent Programmer, to code in everything, to code in your actual entire game, lol)
5. Media Content (if you want graphics, sound, voice, and etc)
6. etc etc etc

I myself, due to still being a noob at coding, am most limited by it. As someone who is good at coding, they just need to design ~ plan out (for example) a magic system, as the coding of it is easy for them. Me, on the otherhand, not only has to plan out~design (for example) a magic system, but I also have to take hours upon hours just trying to learn how to code in what I want from my designing ideas~plans, if I'm even able to do so that is. Huge wastage of time, even if eventually I do figure out how to code in something. And, almost as bad as coding, is the Game Mechanics and Balance. This is extremely hard to do as well, for example, just trying to figure out how to design (non-coding aspect) a level up or a physical_damage attack function, isn't easy, despite how easy I had foolishly initially thought it would be, lol.

-------------------

You HAVE TO make your focus~goals *SMALL*, keep each task you do, as simple as you can, and don't move onto some other task, until you've finished up the first task. Slowly, but surely, you'll build up your game. Just keep adding~completing small parts, as eventually you'll have them all done, and a finished (or at least a somewhat functional) game to play. Then, you can go back and "fine-tune" your game.

Some really great advice here guys, thank you.

HegemonKhan wrote:Game Making is extremely challenging and is a lot of work!, even for the simpliest of games!

1. Story~Plot~Etc Writing (need to be a good author)
2. Game Design (need to be creative, extremely organized)
3. Game Mechanics and Balance (need to be a good mathematician to figure out perfect formulas, algorithms, equations)
4. Coding (need to be an excellent Programmer, to code in everything, to code in your actual entire game, lol)
5. Media Content (if you want graphics, sound, voice, and etc)
6. etc etc etc

[snip]

If we are being clinical about it, then I fail all of those points and shouldn't bother - but then if we all did what we were told we could do, and no more, people wouldn't have invented things in the first place.

HegemonKhan wrote:[snip]

You HAVE TO make your focus~goals *SMALL*, keep each task you do, as simple as you can, and don't move onto some other task, until you've finished up the first task. Slowly, but surely, you'll build up your game. Just keep adding~completing small parts, as eventually you'll have them all done, and a finished (or at least a somewhat functional) game to play. Then, you can go back and "fine-tune" your game.

guzmere wrote:Always go with your gut feeling and let your imagination take flight for without it the great authors would never be! And never be frightened to experiment for if ridicule be your fear then you only have yourself to punish. Terry Happy Adventuring

Liam315 wrote:[snip]

Once I had that as well as a basic concept and narrative outline, it became a fairly organic process from there. You have an idea for a plot line, then you start making the objects needed and scripting it. Then that will give you an idea for another plot line which you might need a new room for so you make that. Along the way you've created a scenery object which gives you an idea for a puzzle so you change it's properties a bit and incorporate it. You have an idea for a cool puzzle so you craft a narrative thread around it so that the puzzle makes sense within the context of your game. Then you go back and realise some of those rooms you built earlier were completely superfluous so you demolish them, or amalgamate them with another room. You delete an object you thought was essential because you've come up with a better idea. You realise that an earlier stretch of plot is ridiculous etc. etc. etc.

All of that has happened while I've been building my game and unless you've 100% thought of every stage and possibility for your game, it will probably happen to you to. Like all creative endeavours, you have to be willing to adjust your plans and vision as your creation takes shape in order to stay in tune with it. There's no use trying to force something in that you had originally planned even though it no longer meshes with what's eventuated.[snip]

To me these are probably the most useful pieces of advice to keep in mind.

It's strange, because I think like Liam, mine is going to me mostly "off the rails" too. Which does make his take on things particularly useful.

I have had several ideas in my head over recent months, but never quite been able to flesh them out. Now, I have an idea that has some legs to it. It started out when I was researching an item (a tinderbox) and has organically grown from then. In fact the story/plot has now grown up around the items I want to include (for the most part), and the premise and reason for the protagonists actions have changed, and IMHO become a more believable plot, as I have thought up new bits and pieces.

So far I have managed to break my map down into about 4/5 sub-maps, and there may be more sub-maps to each of them yet.

I already have 1 notepad file on the go, listing locations and objects (and their combinations). The puzzle I have now, is getting it into quest (if my wife will let me have some time to concentrate on it - she can't "see the point" and can't understand that the only "point" is doing it ).

I'm just stating that Game Making ain't easy nor quick, not that we amatuers shouldn't try to do it, hehe. If something is not hard, then it's not worth it! The harder something is, the more satisfaction and accomplishment you feel if~when you're able to do it; success is earned~seized by your own sweat, tears, and blood

Though having a legion of a team, makes things much easier, in the early gaming days, individuals made games, but now it's corporated, with~using lots of team members.

Game Making is like trying to be good~knowledgeable with every field of science, it's just too much for one person, thus, the aspects of Game Making are broken up for the individuals of a team to specialize in that single area of game making aspect.

there's a lot of online resources for you to read up on for trying to make and design a game.

I like this one a lot, but it's mostly for programmers and at the corporate and high end gaming level, but it offers some good designing ideas~strategies~tactics~tips too. Although, its a massive read, lol, :

http://freecodingtutorial.files.wordpre ... mplete.pdf

and this one is extremely good too (game design):

http://emshort.wordpress.com/how-to-pla ... geography/

she has other really good articles too.

------------------------------------------------------

HK EDIT:

(here's some more links)

http://rpg-design-patterns.speedykitty. ... f_contents (really good link!)
http://www222.pair.com/sjohn/blueroom/five-elements.htm
http://mu.ranter.net/design-theory/general-topics (really good link!)