Creatures Caves | Community

The last and final part of Liam's Creation of a Metaroom: From Inception to Release series.

The last and final part of my Creation of a Metaroom: From Inception to Release series of tutorials.

This part details beta testing, catalogue files, release, websites and more!

Beta Testing - Introduction

Beta-testers should actively try to break the object, after they?ve tried using it normally ? if they fail to wreck it, then it?s well-done. - malkin

There are many methods of beta testing, but the general rule - as Malkin said - is to play with and/or abuse the object, room, or whatever, until you break it or conclude that you can't. Beta-testing is what will give your room that final polishing, to make sure there are a minimum of errors and problems. Bugs always slip through, but a good developer will minimize these as much as they possibly can.

Lets break something then, shall we?

There is no set method to how you test, but I find going through a methodical evaluation of each function of each agent generally helps. When you've surveyed everything the agent is supposed to do, subject it to everything you can think of that it's not supposed to do. (Someone out there will, and it's best to avoid surprises!) Once you have found an error, document it and keep a copy of exactly what the error message said- this will help when pinpointing exactly what is going wrong.

Once you?ve tested all you can, decide which error you want to fix first. The first thing you need to do is take a look at the error message... here?s an example one from a secret new Aquatilis Caverna critter called the Sherbert Lemons- nah, just kidding. This is from the AC Shrimps, to which I recently added an additional piece of code which doesn?t seem to be functioning.

The important part of this message are highlighted in green. This will identify the agent with a name if you have a catalogue file for it, and even if you don?t it will display the identifier. It also gives you the exact script in which the error occurs - another useful datum to save you from having to trawl through large cos files.

Pointers from an Alpha - by Kate

?Beta Testing, by most accounts, the most tedious and boring part of creating a metaroom ? simultaneously, it is also one of the most important. Squishing bugs in your room can be a laborious process, but once again, is well worth it in the long run when your users don?t have to deal with annoying disappearances and errors while playing with their norns.?

- At least, that's what Liam thinks Really, being a beta tester can be a lot more fun than most content creators realize. The creators see testing as tedious because they were involved in the creation of the product, and as such it holds no novelty for them anymore. For an outsider, beta testing is an enjoyable and exciting experience. You get to play with a brand new product before anyone else, and you have the chance to complain about the flaws in it, and be thanked for your efforts!

The most important thing for a beta tester to remember is to click everything. Even if you don't believe it will do anything. Right click, left click, try to move things around, etc. Also check the descriptions of everything to ensure accuracy. That can be done by pressing F1 and then right-clicking an object.

If something doesn't seem right, report it right away. Never assume that someone else has found the problem first, unless it is already clearly documented. Be sure to always copy and paste any error messages into your report.
It's a very good idea to keep a log of everything that goes on in your testing. It may sound like a bore, but it is extremely useful to content creators to see the processes behind everything. Also, you may notice problems later that you missed at first glance.

The best advice for a beta tester is the same as for an alpha tester: Try to break things. Do everything you can think of to every object in sight, come at objects in various ways, use norns to push and pull things to see if the effects vary, etc. And above all, try to enjoy yourself.

The Sandwich Method - by malkin

The technical side of beta testing is important, but for the beta tester, how you present your findings to the creator is an equally important consideration. Developers with hurt feelings generally don?t develop. Some flaws will be immediately noticeable - such as an installation problem because not all the sprites were packaged. Minor problems may only get noticed later (Why oh why doesn?t this room have a toy? etc). Regardless of the amount and types of flaws, there will also be some good points about the object. It's important to present a balance of both positive and negative feedback, in order to avoid injuring the sometimes delicate egos of agent developers. Ideally, you want the agent maker to go forth happy about the prospect of correcting the flaws you've discovered.

Now, to the writing of the report! I use something called ?The Sandwich Method?, which basically goes: Good-Bad-Good. Start off with the things that you noticed that were good, or that you particularly liked. Then go on to some minor quibbles, such as any sprite glitches. Go on to the worst stuff, then phase out of the ?bad? back into more trivial quibbles.

Let's reprise how to avoid shattering your developer's confidence. Present your findings positively. Never say "It's bad." Say something like "If these problems were fixed, this would be a truly good object." Then give some overall, positive, comments on the object, and some encouragement: "You've done such a fine job on this, I'm sure you'll have no trouble making it absolutely perfect. I'm really looking forward to seeing this finished!"

Following the Sandwich Method, and keeping your compliments sincere, will let you give honest, comprehensive feedback, while allowing the developer's dignity to be maintained. Give as much thought to your presentation as you give to your results. The Sandwich Method will ensure that you will always be a welcomed and trusted beta-tester for your favorite developer.

Catalogue Files

Catalogue files are an integral part of a room for the user, and you really cannot afford not to have them. Catalogue files are the ingame help for your agents, so if you wish people to know what everything is, you?ll need to catalogue it.

For an example of how to make a catalogue file, I?d recommend looking at your /Catalogue/ directory of DS or C3 - fairly simple and easy to understand, really! I don?t think this section needs any more explaining, so we?ll move onto the next part...

Advertising - Hype

Ah, now we?ve come to my personal favourite part of creating a metaroom... hyping it up! As some of you may remember, I was Public Relations for Metacore, so I know a thing or two about advertising a metaroom. We?ll look at two completely different ways of advertising and releasing a room, as well as looking at those final details which will make your metaroom release perfect.

Hype is just one way of getting interest for a project, and though it isn?t always the best way to go, its undoubtedly the most fun!

There are several ways to use hype to advertise a project. The one I employed in Metacore was the ?mystery project?, using the letters MC in a variety of contexts and generally spreading rumours and conjecture until the interest gets to boiling point, where we revealed ourselves to a very interested public.

Another slightly more innocuous way of advertising a project is to create a signature image for it, and put it in your signature. I personally prefer this method, simply because it is less annoying than the ?mystery project? one, while still bringing interest in.

You can also post on forums about it, displaying information and previews- this can work just as well as any other method.

Of course, these are just a few ideas - there are hundreds of ways to ?hype up? a project, you just need to find the one which suits you the best!

Website

Having a website is another good way to get your project out there- you can see an example in the Aquatilis Caverna website, which has been met with quite a bit of success, and the Den website which was similarly well-received.

I won?t go into the specifics of how to make a website, but I will point out a few things which could help enormously.

The main thing is: have a nice, at least somewhat original design which incorporates some recognizable element of your room. People need to be able to associate it with your room, and having an element from the room itself always helps - be it a critter, a feature, or a design.

Your design needs to be clean, simple, efficient and easy to use - all these things contribute to a good site.

There are plenty of tutorials on web design out there; I?d recommend googling ?html tutorial? or ?introduction to web design?.

Release

Generally, when you release something you post a link to the website or download on the vast majority of websites and forums so the maximum amount of people know about it.

When you make your post, make it simple and concise; a review of the room by someone else is always useful, perhaps by a beta tester. Put an enticing teaser image up to show what people are in for when they download it, and get them interested straight away.

And finally... the readme

The readme is where the known bugs, story, credits and any other miscellaneous data go. Often readmes contain vital information about the agent or metaroom - if there is a known conflict with agent x, put it into the readme and hope people check it before they inject!

For an example of a good readme download the Aquatilis Pod- simple, concise and blatantly obvious what every section contains.

Conchord

There you have it; a completed room! I hope this series of tutorials was useful to you, and I also hope you have fun making addons for the games.

I would like to thank everyone who helped contribute to this tutorial whether they knew it or not, including in no particular order:

Kate
malkin
Knytetrypper
fuzzie
GreenReaper
Moe
zareb
Don
Sent
Pez

Originally published as part of the Creatures Community Spirit Festival 2006.