This topic is now archived and is closed to further replies.

Woody FX

Testing a game..what needs to be done!

Recommended Posts

Woody FX    169
How do you go about testing a tile game. You should probably have your characters walk about the sides of the map to see are things like your characters trying to access anything out side the array values.. Maybe walk about the map with out killing any enemies till they are all chasing you to see cab it be handled... could anybody suggest anything as i''ve never tested a game before.. Oh and it is a simple tile game so dont go giving me any rocket science

Share this post

Link to post
Share on other sites
Waverider    169
By testing, you're just doing what you can to break things or get the game to do something that is outside what it is supposed to do.

It really depends on what more you add.

For instance. If you are going to have bags that can contain multiple items, it wouldn't make sense to allow the player to put a bag full of items into another bag also full of items.

Perhaps if you could give us a concise list of everything your game is currently capable of, we can make more suggestions.

You have the right idea so far though:
* Wander the whole area and make sure the display stays correct everywhere
* Collect creatures into a single area and see how the game runs
* Place MANY creatures all over the place and see how the game runs, just for curiosity and benchmarking limitations
* Watch for creatures ending up inside each other (bad collision detection)

That's all I can come up with for now.

[edited by - Waverider on May 2, 2002 11:25:52 AM]

Share this post

Link to post
Share on other sites
Michalson    1657
Testing and debugging stradegies is a big topic (I actually went through a section of my course where the text book was exclusively on that subject).

First off all you should record bugs when you find, if you don't you'll likely forget or assume later that you fixed them. You'll also want those notes so that after you've made so large changes to your program you can go back and see if that bug has been reintroduced.

There are two basic methods of testing (you should use both)

Black box testing : This is basically what you where describing. You test the game without any knowledge of how it works. Going around, trying to use features, trying to do things out of order, trying weird combinations of actions (I can't really offer any advice for this, it's a skill you can only get through experience).

White box testing : This is where you setup specific tests based on how you program works under the hood. You'll be looking for things like:

Variable ranges: Try testing both valid and invalid variables, such as trying to buy -1 swords, trying to walk past the edge of the map.

Stress testing: Test how your programs handles lots of data and how it handles lots of data at the same time. Try pressing the fire button as fast as possible. Try putting 100 enemies (if you're engine is designed to allow that) in one room.

There's far more to this subject than I could possibly post here, I would suggest for further information to go on Google and do a search for "debugging strategies" + the name of the language you are using.

[edited by - michalson on May 2, 2002 11:37:15 AM]

Share this post

Link to post
Share on other sites
BlueMonk    142
I am not trained in the ways of software testing, but I have this advice. I basically follow general testing rules (not so specific to games). Start by testing whatever you''re uncertain of. If you''re nervous about your engine''s ability to handle enemy sprite motions, examine the motions of every type of enemy sprite you can as you play... or make a test map with every type of sprite and see how they move and interact. If you''re nervous about the character''s ability to interact with solid tiles, try coming at every unique tile configuration you can think of from every angle you can think of. Again a test map with oddly shaped tile configurations is good. (Keep reading, this isn''t the most important part yet.)

For purposes of practicality, though, I don''t test my tile games terribly thoroughly. I simply play them through a few times, trying to be ignorant of almost everything I''ve known through the course of development. Usually playing the game all the way through a couple times with a couple different strategies ("get all the secrets" and "avoid all the secrets" to name a couple important ones) is a reasonably good test. It''s practically impossible to test for every error/anomaly that could happen, so just test what you can and don''t kill yourself with the effort (but do kill youself in the game and make sure the death sequence works ).

The most important thing is that there *is* a way to get all the way through the game. IMO, The biggest testing mistake you could make is only testing it pieces at a time and never testing the whole thing all the way through at least once when you''re done.

Keep in mind that you want to test unique features. There''s no point in testing every edge of every map. If you get as close as you can to each of the 4 edges of one map, you''re likely to be able to touch any adge anywhere on any map. But do be conscious of any special cases (for instance, if one map is big and is split into sub-maps or something, you might want to test the edges of that one separately).

The terms Black Box testing and White Box testing come to mind (which apply to software testing in general). You *do* want to test the software as you develop it to make sure each of the features you implement works as designed. So you test certain features with knowledge of how they work, trying to force the code to execute down all the various paths (with knowledge of what kinds of tests are going on etc) to make sure it works as expected. This kind of testing I generally do in an isolated test (not while playing through the entire game). This is what I believe is called White Box testing -- (light escapes? you can see how things inside work).

The ideal black box test, then, is to get someone who doesn''t know your game to play all the way through with no knowledge of how it works besides that which you will deliver to the end users. Ideally you shouldn''t even give them hints as they play the first time if you want to make sure a new player will be able to get all the way through your game. Honestly I fake it and try to do that kind of testing myself (now that most of my software is free anyway) . Then I release new versions if problems come in after I release the software. Usually my own testing turns up the worst problems so that the software is acceptable until a new release is available.

But IMO, the black box test is the most important and ensures that there at least IS a way to finish your game by playing all the way through.

"All you need to do to learn circular logic is learn circular logic"

Share this post

Link to post
Share on other sites
Woody FX    169
Thanks Guys thats just the start that i needed..
Bluemonk thats one long reply, you''ve been goin hard on the coffee

Will get to work trying to break my game..

thanks Brian

Share this post

Link to post
Share on other sites
Kooo    122
To expand on the "test as you develop" white box testing, you''ll want to to unit testing. Define what your "units" are (could be a single function, or it could be an entire code module). Then whip up some test code/data to test for areas that look like they could be a problem.

Here''s one of the checklists we are going to be using at work as a guide for unit testing. It came from the book listed below.

UNIT TEST CHECKLIST (use this as guidance when performing unit tests)
__ Check all paths and both sides of all branches

__ Ensure that all instructions execute (i.e. no dead code)

__ Verify operation at normal parameter values

__ Verify operation at limit parameter values

__ Verify operation outside of limit parameter values

__ Check the use of all called objects/functions/subroutines

__ Verify the handling of all data structures

__ Verify the handling of all files

__ Check for normal termination of all loops

__ Check abnormal termination of all loops

__ Check for normal termination of all recursions

__ Check abnormal termination of all recursions

__ Verify the handling of all error conditions

__ Check timing and synchronization

__ Verify all hardware dependencies

Source: "A Discipline for Software Engineering", pg 300.

Share this post

Link to post
Share on other sites
Err...just a side comment: if you can, give the game to a friend of yours or so (someone you can trust, or you feel confortable with). My experience is that people who have **not** written the code are more likely to do odd and unforeseen things than you (the coder).
Oh, yes (I didn''t see this mentioned...): tryto test on as many machines / configuartions /OS''s you can

Forever trusting who we are
And nothing else matters
- Metallica

Share this post

Link to post
Share on other sites
LordElectro    122
Have other people test it. As a programmer, you obviously need to do a lot of testing, especially while writing the game, but in the end, you just won''t be mentally capable of trying everything, particularly since you are intimately familiar with how it all works. When I give a program to a large group of people to test, I am always amazed at some of the simple stuff that has slipped by me, despite the inner feeling I always have that there cannot possibly be anymore bugs left after all the testing I myself have done. Find some friends, and if this game isn''t commerical, go ahead and even release a public beta. This is the biggest step you can take to reducing bugs in your programs.

Share this post

Link to post
Share on other sites