PINGUS DEVELOPERS ZONE

What is a beta tester?

A beta tester is the person that tests the unfinished, buggy and unplayable parts of a game. He sends in comments about levels and might also fix levels which contain only small bugs (say exit is a few pixel to high to reach it or something like that). So to be a beta tester you only need to be able to play levels and have a feeling for things that are broken or simply unfinished. You also should have a good knowledge of other games and what is fun. A basic understanding how the engine works might also be a plus, using the level editor for a few hours should be enough for that. In addition to the playing and rating a beta testers also needs to try crazy things, build bridges that reach to the top of the screen and things like that, which might not have been taking into account has the game was written and which might cause the engine to go crazy or crash. Being familiar with using a Unix shell is a big plus and might be necessary to actually get access to the levels.

What should I do as a beta tester and why?

Well first of all you should actually play the game, look for parts which don't make sense or which you don't understand. If something doesn't behave as you expected it might be broken and it should be reported.

One of your jobs as a beta tester for Pingus will be to playtest and rate all the ~200 levels that we currently have. Some of them are completely playable, some other aren't. Some are just test levels for graphic elements, some just lack the final actions tuning (lowering the number of useable actions to the minimum required to finish the level). Your job is to play, rate and comment them, so that we could along with your ratings and comments order the levels into a sequence that will give the player a good challenge without frustrating him to much. Easy tutorial like levels first, the real difficult ones later on. Sorting after topic and look is also needed.

Getting the game

So to play the game, you actually need to get the game first. Since you will be testing unfinished under development stuff, you won't be able to grab finished packaged tarballs, but instead you have to get the development version, also know as CVS version. Getting it is actually quite easy, first of you need the tool CVS, which in most cased might already be installed on your computer or might came with your distribution, so installation shouldn't be a problem. Once you have CVS you can actually 'checkout' the game, which means to download it. To check it out, you create an empty directory, change to it and issue the following commands:

$ export CVSROOT=':pserver:anonymous@cvs.clanlib.org:/var/lib/cvs 
$ cvs login (there is no password, just hit return) 
$ cvs checkout Games/Pingus

After you have typed that, you will see many lines which tell you what CVS is currently downloading, once CVS is done, you will find the Pingus source code in Games/Pingus/. Before you can start it you know have the choice between two ways, either you compile the game yourself (see the main webpage for details) or you use a precompiled static binary, which are available here. You can just copy the static binary to the source directory (Games/Pingus/src/) and run it.

Testing Levels

As the whole surrounding of the game hasn't reached a state where it is really useful to test it, we can basically skip that for the moment. Most of the bugs you will notice in the GUI, are actually not bugs, but only not implemented things. So we just skip the whole GUI for the level testing, since it doesn't help much. Especially there is no way to test levels which aren't hooked up into the GUI. So to actually test levels we fall back to the good old console. The level files are relative to your top level Pingus directory located in data/levels/. To start a level you just type:

$ ./pingus ../data/levels/somelevelame.xml

Once you hit return Pingus will start up and run that level and you can start your testing.

How to submit testing results?

• If you have found out things that aren't specific to a special level and you are not sure if they are a bug or something else. You can write a simple mail to the pingus-devel list.
• If you found something that is most likely a bug, be it a crash bug or an incorrect behaviour you should submit it to the bugtracker.
• If you found a bug in a level, that is specific to that level, the easiest thing to do is to simply fix it. To do that, start pingus with:

  $ ./pingus -e ../data/levels/somelevelame.xml

  Which will bring you directly into the level editor. By pressing F4 in the editor you can test the level and by pressing F6 you can save it. Once you have done that it comes the time to create a patch. A patch contains your changes and not the rest of the file which is already in CVS. A patch also allows us to merge your changes with the changes of somebody else. To create a patch, you just do a:

  $ cvs diff -u data/levels/somelevelame.xml > /tmp/your_patch
  

  From the top level directory of Pingus. The resulting your_patch file can then be send to the mailing list.
• If you have tested a level and want write a comment about it, be it a good one or a bad one (we need both kinds!), we need to try something else. Since most likely we will get multiple comments per level and would like to have a automatic way to sort and review them, we need comments in a special file format. Noting special, just so that we can track back who did the comment. An example of these comments file is provided here, you just have to insert your name, email address, the levelname and your comment. Comments to multiple levels can be enclosed in a single file. Once you have written your comments, you can mail them the pingus-devel list.
  There are a few things that you should have in your comment: things that where good in this level, things that weren't good, things that where missing and a rating for the difficulty (easy, normal, hard).
• If you want to rate a level, the rating has to be placed into a comments file. The the example file above for details. The following level ratings are allowed:

  very easy

  level is basically self-solving and doesn't require much user interaction and users can not really do anything wrong in these levels without really trying to. These levels could probably be used as tutorials, to introduce actions or new objects, though they should focus on a single action and basically doesn't require more than applying a single action to get solved.

  easy

  levels rated easy, are quite simple, not much for difficult than very easy ones, but they might lack the helper-signs that a very-easy level should have and they might require multiple uses of an action instead of just a single one.

  normal

  levels rated normal should form probably half of the game, they don't require to much thinking, but might require the combination of multiple actions.

  hard

  hard levels require the use of multiple actions along with good timing, setting the wrong action at the wrong time and must replay such a level. hard levels should only offer the bare minimum of actions that is needed to solve these levels.

  very hard

  very hard levels, provide a minimum of actions along with requiring precise usage of actions. They might have very tight pingus-to-save numbers with doesn't forgive a single kill. You can only solve this levels if you know all the voodoos of action combinations and object properties. While a hard level might only require a few voodoo-combinations, a very hard one might require multiple at once.

  unplayable

  a level rated unplayable, isn't meant to be played at all, its just a test level with should get removed from the distribution or be placed into the test/ directory

  unfinished

  levels rated unfinished are not playable at the moment, but contain structure that could be easily turned into a playable level. Unfinished levels can also be levels that contain all the structures for a level but don't have any action numbers set, beside the default ones (20 of each action), such levels should not make it into the final release and should therefore be marked unfinished.

• at a later point we might introduce the ability to record the gameplay of a level, so that we can replay it to analyse it, once that is implemented more details on how to use it will follow

References

• precompiled static binaries
• example level comment file