Olympus, my new and hopefully longer-lived project

[Therem Harth]

In the wake of my giving up on TFork (again ) I've decided to start my own roguelike project. The working name is Olympus. Right now it's very much in the planning stages; my main goal for now is to learn something about programming from the project, though I do intend to try to make it fun.

Currently I am planning out the way the game will actually work. Actual programming won't start until I have a reasonable idea of what I want. If anyone has suggestions, I'm listening.

Meanwhile, I can say that it will have:

- No town, no stores, only one way to go (up) until the end of the game
- 4 stats, which can be raised with skill points (STR, WIL, AGL, and SPD)
- 3 classes (Warrior, Archer, and Thief)
- Mostly defensive/augmentative magic for the player
- Powerful offensive magic for monsters
- Skills for various types of usable items

As for the programming language I haven't yet decided. There are two main contendors.

Python with a Tk interface. Good because I like it better; bad because interpreted probably means more runtime errors.

Java with a Swing interface. Good because I know it better; bad because the JVM is total overkill for a text-based game.

I'm pretty ambivalent on the language right now; Python is quite enticing and IMO easier to code in, but Java might make my debugging work a lot easier, so I'm undecided.

I don't expect this thing to reach a playable state for a while, so don't hold your breath... And again, if anyone has suggestions I'd be glad to hear them.

[Sirridan]

If doing either python or java, try to make it so that you can have a display interface so that you aren't locked into Tk, or Swing.

For anyone who doesn't know what I mean, the interface has a set of methods to display text, clear the screen, and do all that other display related stuff. This way the game itself doesn't have to know *HOW* everything is displayed, and can use any display that implements those interface methods.

As for language, it's really up to you. I've done work on both sides, both are good.

[Therem Harth]

Ah okay. I should be able to write an interface in Java for that, given the time. Not sure about Python, I'm not really familiar enough with it I think.

(And it looks like interfaces in Python are really different. So different that I'm not quite sure what they really are. Hmm.)

I'm starting to think I'll probably stick with Java. I prefer the way Python "feels", but it looks like working with what I know could save me a lot of trouble...

Edit: On the other hand, if I want to learn something new, I might as well use Python. Hmm.

[Derakon]

Python 2 doesn't really have the concept of interfaces, but you can accomplish something similar using inheritance:

class FooInterface:
    def bar(self):
        raise NotImplementedError("Function bar has not been implemented")

class FooImplementor(FooInterface):
    def bar(self):
        print "This class implements function bar"

Also, in my experience, Python code is easier to read than equivalent Java code -- Java tends to be needlessly verbose. Just my opinion though.

[Therem Harth]

Thanks. And IMO you're very much right about Java being needlessly verbose.

Anyway I've decided to write some basic code in Java, mostly to help me clear up my ideas of what I'm doing. I'll see where it goes I guess.

(Though I've generally heard that, the sooner you sit down and start writing code, the longer the project will take...)

[AnonymousHero]

I'd recommend trying Scala.

It's as concise as Python, it runs on the JVM and is 100% compatible with Java classes, so you can use all of your favourite libraries. It's also strongly statically typed.

In particular you can use Swing without trouble. There a PDF with lots of examples here.

EDIT: Changed link.

[konijn_]

<snip>

As for the programming language I haven't yet decided. There are two main contendors.

Python with a Tk interface. Good because I like it better; bad because interpreted probably means more runtime errors.

Java with a Swing interface. Good because I know it better; bad because the JVM is total overkill for a text-based game.

Good luck and more importantly have fun. Note that Apple has recently deprecated their Java implementation for Mac..

T.

[Atarlost]

Note that Apple has recently deprecated their Java implementation for Mac..

They what? Are they in some stupid tiff with Sun? Because that does not do anything good to the value of their operating system.

[Derakon]

At a guess, Apple had their own implementation because they didn't think Sun would be willing to bother maintaining one themselves (thus the choices were either no Java on OSX or Apple-supplied Java on OSX). Now Apple thinks they're big enough that they can get Sun to have to do that work instead. If they're right, that's actually a good thing for Java on OSX since IIRC Apple's been pretty laggardly about keeping the JVM up to date. If they're wrong, though...

In any event, it's not like the current OSX JVM goes away as soon as Apple says they're deprecating it. They just won't supply updates any more.

[Therem Harth]

Ooh I hadn't thought of that. Maybe part of the problem is that it's Oracle now though, not Sun any more?

[Therem Harth]

Okay is it just me or is Python 3's stringformat.format() really confusing?

[Mangojuice]

So as someone who had considered "starting from scratch" in Java, I just wanted to share a couple of thoughts.

1. Angband's main bottleneck is the AI. There can be lots of monsters and for each one the program will need to compute its point of view so it can decide on its action. The good news about using Java is that you might be able to use threading to optimize that a bit. I know that the C code basically runs in a big loop and that there's lots of AI computation that doesn't happen when the program is waiting for the user's input.

2. There's a flip side of the coin with threading: normally Angband will behave deterministically, which discourages save-scumming. But with threading you have to be careful: if the random number generator gets invoked in multiple threads, then the outcome of it may depend on how the threads are scheduled, which you wouldn't want to determine.

[Atarlost]

Pathfinding's probably the real problem and that should have no RNG calls. If you can come up with a way to multithread only that section of the AI you should be fine.

[Pete Mack]

Two points:
I. AI performance
Angband AI shouldn't take a whole lot of time: the basic computations are trivial.
There shouldn't be any need for multithreading. After all, Angband should run well on single-processor handheld devices like PSP and smart-phones.

For pathfinding, you don't want to treat each monster independently; you want to use some kind of dynamic programming (aka lazy) model, where the optimal path from any given point is computed at most once.

II. UI model
The choice of language should be a personal choice; whether or not to use Swing library, etc, should not affect this. Whatever OO language you pick, you will need to define a simple Interface model (or Abstract class model if you pick C++) that hides the details of implementation. If you want to use swing, fine. Just make sure to hide it behind a generic interface. If there's one available, use it, even if it means downloading another library. For java, this might mean Open GL.

This is one place where the current angband implementation gets things more or less right. The combination of z-* files and main-xxx.c files gives some hope of portability, even when there's no universal implementation. It's a very low bar; you shouldn't regress beneath it.