A few workflow questions

[Buckethead]

First off. I'm not totally sure if everything I'm going to ask here totally fits in this part of the forum but I guess it's the best place to post it.

Ok I'm at the beginning stages of developing a game but before I start I want to ask a few questions about how more experienced game designers work:

* How do you go around testing your own game? I assume that everyone does so, of course there are beta testers in many case but I think you always have to test yourself too. How do you do it? I mean if your game is quite long you can't go through it over and over again to test a puzzle pretty far in the end.

* How do you handle your rooms? Do you complete every room and then go to the next or do you make all rooms and then start coding and such.

* What do you use for the start menu? Do you use a gui or a background? And what do you do with the buttons like "start new game"?

* How do you fit in your objects?

* Where do you gather your background info and needed facts?

hmmm I think that's about all I want to know so far.

I hope I get some usefull awnsers.

Thanks for the help in advance! 

[TheJBurger]

* How do you go around testing your own game? I assume that everyone does so, of course there are beta testers in many case but I think you always have to test yourself too. How do you do it? I mean if your game is quite long you can't go through it over and over again to test a puzzle pretty far in the end.

Usually after I design a scene, room, or puzzle, I immediately test it to see if it works or what needs to be tuned.
If the puzzle is pretty far in the end, just have the character start there or teleport using Debug features.
(For alpha-testing) When I test my game, I keep a piece of paper next to me, and anything I see that is wrong or could be improved, I write it down on the paper (If I try to remember it, I always forget). After I'm done testing, I fix it up in the engine, crossing off every item on the paper, and then I repeat the process over and over until I find nothing on the paper next to me after a test.

* How do you handle your rooms? Do you complete every room and then go to the next or do you make all rooms and then start coding and such.

Usually I take it one room by one, but I might not finish everything like hotspot descriptions, etc.

* What do you use for the start menu? Do you use a gui or a background? And what do you do with the buttons like "start new game"?

I personally decide not to use start menus most of the time, but if I do, I probably use a background with hotspots/objects. If you want the buttons to animate, I usually use objects.

* How do you fit in your objects?

Uh, I don't know what you mean by this.

* Where do you gather your background info and needed facts?

Usually in one, if not several *.doc files.

[Shane 'ProgZmax' Stevens]

* How do you go around testing your own game? I assume that everyone does so, of course there are beta testers in many case but I think you always have to test yourself too. How do you do it? I mean if your game is quite long you can't go through it over and over again to test a puzzle pretty far in the end.

I test it as I make it, basically.  This slows down development but vastly reduces the chance for bugs.  With the debugger on I usually make some Function keys that skip to certain events, and there's always ctrl-x for skipping rooms.


* How do you handle your rooms? Do you complete every room and then go to the next or do you make all rooms and then start coding and such.

I make the game as I go along, which I suspect most people do.  If the next sequence needs a room I make the background and then consider the objects and characters that need to be there.  If you are a person that relies on other people to do art you may have placeholder graphics here and a good portion of the game done before the finished art is even in place.

* What do you use for the start menu? Do you use a gui or a background? And what do you do with the buttons like "start new game"?

Sometimes objects (for buttons) coupled with a background, sometimes just objects.  I've never had a need to waste a gui on a title screen, but it could easily get the job done.  With an object you can just as easily check for a mouse click, and since title screens very rarely have a ton of things going on it's less wasteful than using a gui.

* How do you fit in your objects?

Do you mean how do I decide where they will be placed?  I decide ahead of time when the background is being created so I can make room for them.

* Where do you gather your background info and needed facts?

As in research or as in documenting the game?  For research I recommend a library if it's something historical or an area you need to know about to not look like a fool.  If it's documentation I tend to combine in game help with text files.

[GarageGothic]

I've never had a need to waste a gui on a title screen, but it could easily get the job done.

Using GUI button text and/or labels makes it easier to translate the game to other languages since you won't have to create separate graphic resources. If you need any special effects that can only be done with graphics (glowing fonts or similar) however, you might as well use objects.

[m0ds]

Your questions are fine in this forum

[Radiant]

* Testing. You NEED testers other than yourself, because you will miss things that you take for granted. You MUST take their input seriously; for instance, if they can't figure out the interface, you may assume that they're just being stupid, but the proper answer is that the interface is lacking. Good testers are rare - cherish them. Bad testers are worthless and a time sink. The game being long is no excuse; I can play through ATOTK 100% in about two hours, and yes you'll have to do this over and over again. Oh and yeah, good debugging tools help.

* Rooms: You'll need the map pretty much laid out before you start coding rooms, otherwise it doesn't make sense. You should make skeletons of all rooms (so that you can walk to the next room and the game is technically playable) and fill in the rest from there, in whatever order your inspiration tells you.

* The start menu is easiest implemented as a GUI, although using hotspots also works.

* How do I fit in my objects where? It's part of the room code.

* Background info - you need to read up. I use an encyclopedia mythica, and a variety of internet sites.

[Buckethead]

Wow thanks for so much nice awnsers already. Sorry about not being clear about the objects question. What I meant was: Do you draw in your objects in the background and later really place them in? Or do you draw your ojects separately?

Anyway. The info I got so far already helps lots. Thanks alot. 

[RickJ]

Testing
The best way to debug your game is to not have bugs in the first place.  This is, of course,  not 100% achievable but you can significantly reduce the likely hood of bugs by being extremely organized in the way you write your script code.  Create a naming convention for everything and be neat and consistent.   Write script code in  a manner that is easy to debug (i.e. how will you or a tester know it it is working or not?).  Having done this realize there will be bugs.  Find all the ones you can yourself and then enlist the help of beta testers.

Rooms
Everyone has their own preferences.   When I first started with AGS I read a tutorial somewhere that suggested creating all the rooms and room transitions so that the character could walk throughout the entire game.   I found this to be pretty good advice.  Here is the order in which I prefer to do things:

* Create a rich and interactive game world
- Create rooms and room transitions so character can walk entire game.
- Make interactive game elements functional  so that character may interact. (i.e objects such as doors, etc, can be opened, closed, unlocked...)
- Create GUI and other user interfaces
- Add global functions that implement any required game world physics or other calculations

* Add game logic and plot
- Add NPCs and dialogs
- Add puzzles
- Add script code to enforce game logic, progression, and scoring