Previous Entry Share Next Entry
Bastard Documentation From Hell
Or something like that:

Introduction to Programming
Assessed Coursework 2 (Exercise Sheet 6)

This program is designed to entertain and bemuse poor unsuspecting gamers. It models a castle as being an environment consisting of three floors of nine rooms, containing various monsters, items, puzzles and null pointer exceptions. The player has to smite his enemies in order to get bigger weapons of mass destruction, to further his goal of creating carnage left, right and center, ultimately leading to him destroying the nasty demon that makes up the goal of the game. Of course, the player isn't told much about his goal - the fun part is letting him find out, because we all know how daft these users can be sometimes. The game loops around the player's commands - he can move between rooms, pick up objects, discard objects from his inventory, use those objects, fumble with case sensitivity, and fight monsters.

This is done by having the main method create a three dimensional array of room objects for the player to screw up in. The player can then move between adjacent rooms at will (assuming he knows the commands), pick up objects in rooms, place his own objects down in the rooms, use his objects in the room, and use his objects with each other to create new objects. He can also fight bad guys with sharp pointy teeth and big horns, although this usually results a terminal condition known as "Game Over". This process is handled by a combination of the command prompt and a lot of trickery involving tactically placed bugs:

You are in a room on the ground floor at the north east end of the castle
There are steps leading upwards
You have 20 health
In your left hand you have a Arrow

at Game.main(Compiled Code)

In this way, the player is able to control his environment (assuming he has limited ambition), and choose what to do. In order to fight an enemy, he must use a weapon in his inventory, and pray that he has enough health to survive it. He may also use medical equipment to increase his health (assuming he can find it, because I'm buggered if I could during beta testing), use a talking skull (which gives hints as to how to win in case he can't figure it out), combine two items together (which actually only applies to two items in the whole game, but the framework for more is there), or get or drop items. Using these simple commands, the player can shape his sad little world. If the user instructs the character to get an object, the character searches through all available objects in the room until it is either found, or he has exhausted the contents array. He will either have the item, or will simply sit down crying, claiming that it doesn't exist in the room. The item names are case sensitive, which may present problems at first, and odds are he'll be more likely to pick up a null pointer exception than an item.

The game reports where the heck the player is every time a command is entered, like it could possibly help the poor guy. If the player uses the command look, then a seemingly more detailed description is displayed, which on closer examination proves to be just as vague, and only half as useful as the other one. It lists all those items, monsters, staircases, or special attributes that never quite got past the testing stage, and gives him a taste of what he could have played with if the coder hadn't been drugged up to the eyeballs on caffeine. The player is then able to enter another command, and so build up a sequence of actions, each more futile than the last.

Particular limitations in my opinion were related to the lack of color the environment had, not to mention the fact that the coding itself was a pile of wank. It's very sterile to read "You are in a room on the ground floor at the south west end of the castle" - it would have been nice (had I had the time and/or inclination) to have added a scenery randomizer to the constructor method of the rooms. That way, each room could have different features, which would be highlighted every time the room was described. However, this is far more an aesthetic feature for poncy morons who think that if a game doesn't use OpenGL then it sucks, rather than a functional feature for people who give a shit about the game. What would be more interesting, more functional, and wouldn't make my ears bleed in implementation, would be the random insertion of immovable objects that could contain moveable items. There could be a 50% chance that a room would have a container of some description, which might have to be opened (with a key, maybe) before the item within could be taken out. The advantage of this is that it could be done differently every time the game was run, thus confusing the user into thinking that perhaps the game isn't as bland and one dimensional as it in fact is. To be sure, if you also randomized which rooms all objects were put into, and perhaps managed to get it so that the bug in room [0][1][2] would sometimes appear elsewhere, you could define the arrays to be any size you liked, and come away with huge resource munching maps. Since you could even combine different types of objects (weapons that had healing properties for the wielders, because when jabbed into an enemy they sucked his blood out, ready for you to drink it, or indeed weapons which could unlock doors by means of extreme force), there is a wide scope for large, complex systems of rooms, stories, monsters and null pointer exceptions. Also, as specified by the rather sarcastic comments in the program code (which I feel I must apologise for - it's not that I'm treating the whole thing with contempt - it's just that your course has deprived me of sleep to the point where I know no better), the stairs need not be two way things. It would be quite possible to have elaborate systems where there are trapdoors in many rooms to get to lower levels, but few ladders. Perhaps we could implement a way in which players automatically fall through trapdoors on entering the room, which would seriously piss them off if we took all the ladders away.
I also didn't use exceptions. When you write perfect code, where the fuck is the point, eh? While it would have been quite possible to handle errors with them, I found that the way in which my rooms knitted together meant that trying to move outside the game area wasn't an issue. Additionally, it was simply easier to say "That object doesn't exist, you freaking moron" to erroneous requests for blatantly fictional objects than bother coding an extra exceptions object, just to look smart and clever. It's not smart. It's not clever. It's bloody poncy. However, while this was true of this small project, anything much larger would probably be difficult to catch all such problems with, and throwing exceptions in all sorts of random directions would be a simple and effective way of dealing with that - the solution is to crash the program out before the user finds that you can't code worth toffee..

In conclusion, I would say that this particular exercise has taught me a great deal, although not really about programming. I learned new methods for staying awake for extended periods of time, although I am still adjusting to the side effects of such activities. I'm sure that, given sufficient time, I'll be able to blink again, and maybe when I pass out tonight, I'll get the rest that your subject has deprived me of for so many hours. I hope my project formats your hard disks, you creativity parasites.


In order to test my code, I started the player off with a couple of random start states, and tried a couple of actions with them. Rather than running the program normally, I only tested one operation per state, thus limiting the scope for finding bugs. If you don't find them, they're not there, right? In order to pinpoint errors, I had it output all relevant information, such exactly how much of my memory Windows was taking up at the time, and why it was that you simply cannot run a program on 1kb of free memory. In this way, I weeded out (what I believe to be) all the major (although by major, I obviously don't include fatal exceptions, null pointer exceptions, or calls to the well loved new BlueScreenOfDeath(RandomMadeUpReason a); object) problems with the code. The code was, as far as I'm aware, working perfectly, until Mr Gates intervened with his lack of Java compliance in his POS operating system. It's enough to turn a guy to the Mac, I'm telling you. No, wait, shit, just kidding - BeOS or Linux, far more sensible… Really :o)

  • 1
So download proper Java from Sun for Windows... duh.

(Deleted comment)
Hey, it's only the third time........ ;o)

(Deleted comment)
  • 1

Log in

No account? Create an account