The game is supposed to ask the luser if it wants another go. So it now does.

The luser is also left in no doubt that the game is over.

The basic game does what it should:

Swampy bloodbath!

1. It creates a swamp creating an ogre in a random position.
   
2. An enemy may enter.
   
3. All creatures in the swamp move to a proximate location.
   
4. Steps 2 and 3 repeat …
   

   until one or more enemies enter the ogre’s current location.

   • If there is only enemy in the ogre’s current location, it is killed and this happy event is reported.
     Then steps 2 and 3 begin to be repeated.
     
   • If there are two or more enemies in the creature’s location, the ogre is killed and this sad event is reported.
     

The remaining tasks are

• ensuring the ogre doesn’t start at (0,0)
• reducing the number of times the map is drawn
• creating an interface which is completely independent of the game
• enabling saving of the current game and later restarting it
• writing comprehensive JUnit tests for each method (excluding the constructors) defined on the class Swamp
• writing a report on
  • how I created the swamp
  • where and why I used polymorphic programming
  • my programming style (i.e. showing where and why you have used things like interfaces, enumerator, exceptions etc) There are none of these in the current code, although I suspect I should use an enumerator for the types of enemy.
  • how my swamp is extensible
  • any problems encountered during the coding of my game. Hence these blog entries!

I need to demonstrate my program and submit my report next Tuesday, so I better crack on.

One refinement I could make is to not use both type (‘ogre’ or ‘enemy’) and subtype of enemy (‘donkey’, ‘snake’ and ‘parrot’). I think these could be collapsed into just one type. Then I’d only need one non-abstract class of creature. But this would remove all vestiges of polymorphic programming from my code…

It really doesn’t help if I leave the line in the creator code to place an ogre commented out!

I think I have it: it seems I was still trying to take a step while examining the list of creatures in a different place. Back to the full game to find out.

I think the bug I’m currently trying to squash is in the ‘remove’ method called from battle(). I’ve traced it by putting single lines of code to display a number after each step. So far, the numbers appear in order.

The remove method works by finding the position (index) in the ArrayList of the creature to be removed, then removing the creature at that index. (You can’t do simply ‘remove this type of creature’. The remove step needs two parts so that you don’t try to remove something from a collection that’s currently being examined – that way lies crash city.)

I was puzzled because the index of the creature to be removed was constantly ‘1’, even though the first creature to be added was an ogre – and the remove code will only work if the creature to be removed is an enemy.

I’d forgotten that computing numbers start at ‘zero’. Bah!

Back to bug-squashing…

I’ve started assembling the actual game – a separate program which calls methods from the Swamp class as needed. It doesn’t quite work yet – the battle section crashes. One reason for this was that I wasn’t checking the current enemy’s type – so the ogre was killing itself!

Having cured this – suicidal ogres are not allowed – and temporarily removed the ‘battle’ section from the game code, the following occurred.:

A swamp is created and an ogre is added.
Turn 1. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 2. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 3. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 4. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 5. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 6. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 7. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 8. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 9.No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 10. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 11. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 12. An enemy parrot arrives.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 13. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 14. An enemy donkey arrives.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 15. Another enemy parrot arrives.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 16. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 17. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 18. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 19. Another enemy donkey arrives.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 20. No enemy has been added.	All creatures move.	A battle should occur here, resulting in the parrot at (1,1) being removed to leave just the ogre at those coordinates.
Turn 21. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are.
Turn 22. Yet another enemy parrot arrives.	All creatures move.	At this point, a battle should occur at (1,1), resulting in the ogre being killed by 2 parrots. But this code isn’t yet called, so the ogre lives on.
Turn 23. No enemy has been added.	All creatures move.	No battle occurs so everyone stays where they are……….

This is where the extra methods will be useful. I can create a swamp with creatures where I choose and see whether the battle proceeds as it should.

Original status
Returning to the programming project after a day of cycling and finishing some written coursework for another module, I was faced with a blur of methods (subroutines) written in the order I realised I needed them. These included some methods which were only there to test whether I could create, move and list my creatures.

The chronology followed the basic need to

1. create a swamp and its ogre
2. add enemies if luck so decided
3. draw a map of the swamp and its denizens
4. decide whether to have a battle
5. the actual battle (so far only pseudocode).

In short, my code was an inaccessible mess. It didn’t help that the code for the Swamp called code for ogres and enemies which are in separate files. Given that my code has to be read and understood, I needed to tidy it. (Currently, only my lecturer and I need to read my code. However, if I end up writing code for anyone else, they – and maybe later workers – will need to be able to read and modify it easily.)

Problem statement
Given that my code is an inaccessible blur, how can it be tidied?

Solution methodology
It is surely sensible to break any long piece of writing into chunks, i.e. chapters, headings and subheadings etc. So why not do the same to my code?

As far as I know, Java doesn’t allow headings and subheadings. I’m pretty sure there’s no such feature in the IDE I use. However, there are two comment styles:
//comment

and

/** *******************
* comment *
********************* */

The green style is used throughout to say what individual methods, bits of method and individual lines do. I believe the blue style is now used to feed the JavaDoc system and I’ve seen it used for header blocks (name of program, author(s), copyright status, etc). However, I’ve not yet got into JavaDoc.

Solution
So ‘chapters’ in my code are headed
/** *******************
* ALL CAPS *
********************* */

and ‘sections’ are headed
/** *******************
* lower case *
********************* */

Recommendations of how this should really be done are very welcome!

Corollary
Chunking my code and moving the methods so they fit the chunks has also been helpful in that I’ve isolated methods no longer used into a METHODS USED ONLY DURING DEVELOPMENT/TESTING. I feel I should get rid of them but I’m not sure. Recommendations are again very welcome.

I need to write a piece on how my code works, including some comment on development – so in this instance it might be better to keep them. Also, this code won’t be transmitted (unlike JavaScript doing stuff in your browser or naughty things to your computer) so it doesn’t **need** to be concise.

Current status
In my Swamp class, I now have chapters for

1. INSTANCE VARIABLES, CREATOR, SETTERS AND GETTERS
   8 items
2. CREATE AND ADD OGRE TO SWAMP
   2 methods
3. CREATE AND ADD ENEMIES TO SWAMP
   3 methods
4. DRAW MAP OF SWAMP, INCLUDING LOCATIONS OF ALL CREATURES
   1 method, which is currently horribly inefficient because all creatures are examined (swampSize)^^2 times
5. MOVE ALL CREATURES
   1 very short method that calls code from ‘Creature’ class
6. BATTLE
   This has 5 sections:
   • Find ogre’s location – this will be called each turn of the game and will update an instance variable (2 methods)
   • Find and record how many enemies are in ogre’s location (1 method)
   • Decide whether there should be a battle (1 method)
   • Actual battle (3 methods)
   • Methods for removing creatures (2 methods)

    

7. METHODS USED ONLY DURING DEVELOPMENT/TESTING
   5 methods

My Creature class has

1. INSTANCE VARIABLES, CREATOR, SETTERS AND GETTERS
   13 items
2. MOVE THE CREATURE
   2 methods – although I should split one of these into 3 separate methods
3. WHERE IS THE CREATURE?
   1 method, currently unused.

My Ogre and Enemy classes just have creator methods, so don’t need chunking.

Much experimentation on a simpler version of my swamp later, it turns out I can remove creatures from the swamp’s creature collection after all. The trick is to FINISH finding the position (technically, the ‘index’) of the relevant creature first (i.e. finish the for-each loop), THEN remove the creature with that index. Now to try it on the full version of the swamp!

Oops – I forgot to call the code that invokes a battle. So no matter how many enemies are in his current grid-square, the ogre is immortal!

The following should NOT be the case:

The music was unintentional but is amusingly appropriate.

I can add a lot of creatures, move them all around and draw a textual ‘map’ of where they all are. Even better, it agrees with where the creatures themselves say they are!

• List of creatures and their individuate coordinates 1
  
• Independently-generated map 1
  
• List of creatures and their individuate coordinates 2
  
• Independently-generated map 2
  

The code to draw the map is horribly inefficient: for each grid-square in each row, each creature is asked ‘should you be added to the list of creatures for this grid-square?’. For a 4 by 4 swamp, each creature is interrogated mercilessly 16 times! I hope I can find a better way – maybe each creature could have a record of whether it’s been added to the map. But then it would need to be interrogated about this too!

If I was still working with grid-square objects, the code would have been ‘for each grid-square in each row, ‘give me a list of your contents’. But that approach didn’t work because of the difficulty of moving creatures.