This site requires JavaScript, please enable it in your browser!
Greenfoot back

Report as inappropriate.

botman presents ...



This is my first play with Greenfoot.

A little demo, inspired by a few PC games: Majesty, Dransik and SimAnt.

You can't control the heroes directly (that's the idea...), but you can click on them or monsters to see their stats.

For now, if your heroes die, you'll just have to restart. :)

Plans for R3: interactive buildings (be able to recuit heroes).

Release 3:
- Implemented factory pattern. Now have different types of monsters and heroes.
- Heroes should live longer: they'll rest between fights if hurt, or run home if close to dying.
- Heroes now heal slowly compared to monsters when roaming around, but heal very quickly at their camp.
- Monsters have different behaviours: passive (mind their own business), agressive (attack heroes) and ultra agressive (attack heroes and other monsters!).
- Improved movement algorithm. Still simplistic, but mobs wont get stuck as often.

Release 2:
- Made some improvements to the code (see comments thread).

5686 views / 677 in the last 7 days

1 vote | 0 in the last 7 days

Tags: game simulation with-source rpg rts

open in greenfoot
Your browser does not support the canvas tag.


Yeah, I just consider it good practice to be as explicit as possible. :) Hopefully it doesn't make it harder to follow though.


If I was being picky, then I'd say it actually did make it harder to follow - when I see "this dot something" I generally expect it to be a global variable name that's been shadowed by a local variable or a similar situation. In the cases where the methods are actually in the same class, you could argue along the side that it's clearer and reinforces that you're calling the method in the same class. Similarly you could argue along the lines of using super to reinforce the fact that it's in a superclass and not in this one. Personally I wouldn't do either of the above because a) it can bite you sometimes if you have to refactor and b) personally I think the code should be nice enough to follow without such prompts. However, when things really do start to get confusing is when you use this to reference methods that aren't actually in that class - then you're essentially making it more confusing by adding it! For example, in your Monster class at the time of writing you've got the following line: this.forgetAttackers(); ...but the forgetAttackers method isn't actually in that class at all, it's in the superclass - so I'd say using the this keyword in this instance is definitely more harmful than it is useful. One other point relating to style, it's generally a good idea to put all global variables at the top of the class, not half way down - this just makes them easier to see and distinguishes them from the methods. That said, on the other hand well done with the commenting (looks like you've got javadoc comments in there for most methods) and indentation, that's definitely a plus! Looking forward to the next release :-)


Hmm, fair enough. My main motivation for using 'this' is I mostly work with PHP, which has a huge library of global functions. So I'm used to having to identify class methods when calling them. Next update, I'll work on removing 'this' from the method calls. I will keep them for variables though as I find a lot of value in being able to skim code and separate class properties from local variables. As for the class variable placement, yeah, that was something I was experimenting with. You've got the "Principle of Proximity": keep related actions together (see Code Complete, 2ed, pg 351). That works a charm within routines, but I was trying to extend it to the class level: if a class variable is only used by one or two methods, group them all together. I'm not sure it works though, so again, next update I'll try moving all the class variables to one place. Cheers.
A new version of this scenario was uploaded on Wed Jun 03 13:25:45 UTC 2009
A new version of this scenario was uploaded on Wed Jun 03 13:27:07 UTC 2009


I can see where you're coming from on the above points definitely - and if you've come from another language background then learning things differently just in terms of style will always seem a bit odd. Personally I'd say it pays to learn the fairly "set" conventions of another language if you want to deal with it seriously - but at the end of the day it's not unreadable at all, and as long as it makes sense to you and anyone else that needs to look at it you shouldn't run into many problems on that front :-)
A new version of this scenario was uploaded on Fri Jun 05 09:34:53 UTC 2009
A new version of this scenario was uploaded on Fri Jun 05 09:48:56 UTC 2009


This looks great. I definitely has some elements of design that I hope to learn from. It will give me ideas. Thank you very much for leaving the code open for us. It's appreciated!


Interesting discussion about using the keyword this. I personally _force_ my students to always use this when referencing a class variable. This might be redundant in a lot of casses, even confusing - but it has a huge advantage: My students are absolutely aware what "this" is. If we pass this to another class or if we are referencing other objects (like xy.getX() vs. this.getX()) they have no problems with this paradigm. So I keep the this-force rolling :-)

See all comments

Want to leave a comment? You must first log in.

Who likes this?