Need some help with designing a Java-based Angband variant

[Therem Harth]

I'm beginning to get sick of messing around with ToME 2, and I haven't learned a whole lot about programming, so I'm looking into starting a new *band based on Java and AWT. This time I actually intend to follow through with the damn thing.

(I know, bad track record... But life is slow right now, so what the heck.)

So. Armed now with some textbooks and the Java API reference, the first thing I intend to do is come up with the class hierarchy. I'd post a flow chart but it doesn't seem worthwhile, thus...

(And note I'm stealing some of this concept from the pyAngband project.)

Display stuff

AngDisplay: class that carries out interactions between terminals and internal game stuff. It would have methods for displaying messages in the terminals, for instance. Not sure if it should be all abstract/static, or not.

AngTerm (extends Frame): A terminal window, used to display whatever.

AngMainTerm (extends AngTerm): The main terminal window, which displays the dungeon and whatnot.

(There'd have to be more here, I think, but I'm very hazy on GUI programming.)

Monsters and players

Creature (abstract): a monster or player. Has the fields and methods common to both.

Player (extends Creature): a player character.

NonPlayer (extends Creature): a monster or NPC.

Terrain

Terrain: a floor or wall square. Has fields indicating impediment factor, damage or other effects, coordinates, and mapping/illumination, as well as the list of items and the Creature (or lack thereof) on it.

DungeonLevel: contains a two-dimensional array of Terrains, and stuff like depth, themed nature, etc. The way I figure it the constructor would contain the dungeon generation code. (Or would it be better to separate that into another class, DungeonLevelGenerator or somesuch?)

Items

Item: An item.

EquipItem (extends Item): An item that can be worn or wielded. (Is this really necessary, or would it be better to use a field and a method to indicate that it can be wielded? I don't want to create unnecessary distinctions.)

Properties of stuff

Things would be kind of complicated here; I want to be able to derive item properties from monster properties so that monsters could drop corpses, and maybe vice versa so that statues could turn into monsters. Anyway, my concept for now...

StatHolder (abstract): a container for stats. Would contain stuff like weight and resistances, which could apply to anything.

ItemStatHolder (extends StatHolder): has item-specific stuff.

CreatureStatHolder (abstract, extends StatHolder): adds more fields specific to monsters and players.

PlayerStatHolder (extends CreatureStatHolder): adds player-specific stuff such as ability strengths.

NonPlayerStatHolder (extends CreatureStatHolder): adds monster/NPC specific stuff such as alignment.

Spells and effects

I really haven't the faintest idea where to start here. Should each spell be an object? Should this be handled through a class with static methods? No clue right now, I'm quite open to suggestions.

Other issues and ideas...

- The current outline has a bunch of StatHolder subclasses. This seems maybe a tad redundant. Maybe I could use a single StatHolder class for terrain, items, and monsters/players? It would be one bloody huge class, but could it allow more flexibility? For instance, say I wanted a Petrify spell that could turn a monster into a terrain feature...

- There'd have to be methods for getting and displaying info - part of the StatHolder class(es) I think. And they'd have to be very different for e.g. items vs. the player. Perhaps separate classes are not so bad?

- The means of displaying a chunk of the dungeon in the AngMainTerm still has me bamboozled. I should be able to think this one out, but I'm drawing a blank at the moment.

- I'd like to read game info from human-editable (i.e. not XML) config files. Which means coming up with a config file parser. Anything in particular that I'd need to take into account there?

- For saving the game, I figured I'd serialize the DungeonLevel and everything in it. Which means DungeonLevel and everything it can contain must implement the Serializable interface, IIRC. I'll have to think more about how to do this...

- What about logging and history? What about items in the player's house, if applicable? Maybe I should have a CurrentGame class as a kind of overarching container, holding the dungeon level, the player's history, etc., and serialize that to save the game?

[Magnate]

Tell me you googled "java angband" before you started ...

[Therem Harth]

... I didn't. And I didn't realize that a Java-based roguelike engine already existed: http://sourceforge.net/projects/roguelike-eng/

Dammit.

[artes]

I've also made a Rogue-like in Java.

[smileyy]

Angband is as much about the journey as it is the destination, so if creation ex nihilo is what appeals to you, there's nothing wrong with creating your own Roguelike in Java.

My advice to you would be to not try to bite off everything at once. You don't need to solve every problem at the same time. Start small, build what you need, then add as you go.

My very first discrete feature was just ensuring that at the start of a game, the player was placed on a 1x1 empty level. That's it. Very minimal Game, Player, Level and Tile classes were all I needed.

From there, it was picking up an item under the player, then it was moving around an empty level, then not being able to move through impassable terrain. That led to needing a trivial Item, then Terrain and a way of setting Terrain within a level.

All of this happened without any sort of client display -- just a test harness injecting commands and verifying game state afterwards. The test harness ensures that, as I make changes to internals, everything I want to work still works afterwards.

That's just my advice, coming from about 10 years of Java and general software development experience. But YMMV. It's your toy -- you can build it as you like, or work off another piece of existing work.

[Therem Harth]

Ooh boy this is old...

I wound up not pursuing it. Partly because my idea of what I wanted in a roguelike wasn't really fleshed out, partly due to lack of time and knowledge. And in a way I'm glad I didn't put much effort in; Java isn't exactly popular in the desktop world AFAIK, I'm no whiz with it, and I don't find it endearing at all... In fact I find it an absolute pain to work with, and have no idea why on Earth they teach it in almost every university's CS curriculum.

In short, this idea was an overambitious product of boredom and ignorance. Sorry to disappoint.

P.S. I have wondered about doing a roguelike in Perl, which I now know somewhat better than Java. Not sure it would be feasible at this point... Or a good idea in the long run.

[d_m]

P.S. I have wondered about doing a roguelike in Perl, which I now know somewhat better than Java. Not sure it would be feasible at this point... Or a good idea in the long run.

IMO Python is a better choice than Perl. Although really any of the currently popular dynamically-typed languages would work (e.g. Python, Perl, Ruby, Lua, etc).

The biggest challenge with projects like this of course is not choosing the language (which is mostly a matter of personal preference and familiarity) and instead the difficulty of building something as big and complex as Angband from scratch when it already exists.

[smileyy]

The biggest challenge [is] the difficulty of building something as big and complex as Angband from scratch

And also the fun part