Is it possible to make a rougelike in Java ME?

[Sithun]

The question is like the subject. I have been looking for good rougelikes for my cell phone, and ive found one. I tried it, but didnt like it. Since i am currently studying Software engineering (2nd term), I would like to give a try at making a VERY basic roguelike engine for my phone, a Nokia 5800 XM, as a 2 week project.

A few problems arises: As ive read on other sites, colored characters will be a hindrance, even with standard Java its difficult to make it work. I expect it would be worse with Java ME.

Has anyone tried this before? Succesfully? Unsuccessfully?

[Etinarg]

The old roguelikes for mainframes also worked on monochrome terminals. I would assume that the lack of colors is no problem really, particularly for a small roguelike.

[Slash]

The question is like the subject. I have been looking for good rougelikes for my cell phone, and ive found one. I tried it, but didnt like it. Since i am currently studying Software engineering (2nd term), I would like to give a try at making a VERY basic roguelike engine for my phone, a Nokia 5800 XM, as a 2 week project.

A few problems arises: As ive read on other sites, colored characters will be a hindrance, even with standard Java its difficult to make it work. I expect it would be worse with Java ME.

Has anyone tried this before? Succesfully? Unsuccessfully?

What JavaME roguelikes did you try?

[Sithun]

What JavaME roguelikes did you try?

Im not certain it was developed in JavaME at all, might have been something else. I cant remember the name, but Ill look it up.

Ah, yes, I found it:
http://roguebasin.roguelikedevelopment.org/index.php?title=Dweller

As for the problem with color, I got a tip from my teacher that I might be able to print a colored char on the screen via the graphics class. Im looking into it.

EDIT: I solved the problem with colored characters. Using the setColor and drawChar in the displayable class Canvas works just fine.

Now i have to make the actual map. As it is supposed to be centered on the player, like in dweller, i have to give this some thought. Im thinking of using an array of "AsciiTile"-objects that contain a char, a color and a boolean "passable". How have you guys handled the map in your games? 

[Sithun]

It does seem like it is possible. Althou Java ME does seem to have some inherent problems with switching from a gameCanvas to the menu, i have so far managed to make a playable and working alpha. It features one map, that demonstrates passable and non-passable objects, colored characters and tiles, and an extremely high-tec ai that controlls the other creatures on the screen (no, srsly.  ). Controll is handled by either using the phones (or the phone emulators) arrow-keys, or by tapping the screen (for touch-devices) in the direction you want to go relative to the center of the display.

People with touchscreen-devices will want to disable any on-screen buttons that the Java ME adds during runtime. Different devices handles this differently. The program has been tested on a Nokia 5800 XM so I cannot guarantee that it works for your phone.

It is open source, but i hardly think any of you will use it at this early stage. Standard procedure for giving thanks to the original programmer is of course i order if you should decide to work on it.

[Etinarg]

Cool to hear about your success. A few times I tried to get into Java ME, too, and studied the API. But not having a java capable phone I didn't pursue this further ...

Thanks for letting us know about your progress, and good luck with your project

[Sithun]

Version 0.1.6
More has been done. Least among the things ive done: The game has been christened  TOMRL for The Only Mobile RogueLike. Thats not entirely final, because i will rename the game to something like "Test of Mokroul" when it has an actual story. It just needed a name.

Secondly, the display can now handle maps of a size up to 100x100 if need be. This value is likely to change if the amount of information in each square increases. Hopefully, both my testing-platforms will survive such an expansion.

Thirdly, i remade the way the game draws the screen. Everything from stats to debug and messages, to the map, to the buttons SHOULD now independent of phone-resolution (read: blatantly ignorant of actually testing the game on any other phone). Basicly, the screen got a bit more appealing to the eye.

Fourthly, sent the gameCanvas a pointer to the "main screen", so that the game can actually exit back to the menu. Added funtionality to start a new game or resume one currently in progress.

Fifthly, buttons (the drawn ones on the screen) now work. CMDS still doesn't do anything, and MENU only returns the user to the menu. In theory, i will have little to no problem linking the buttons to any desired effect.

What the game still can't do:
- Generate random maps.
- Add enemies on the fly.
- Combat (bumping into them isn't combat, it's barely even rude.)
- Be fun to play.

I am on the other hand getting closer to something remotly enjoyable.
Also, i passed the project. Yay me.

Next up is:
- LOS (that will be fun)
- Maps with occupantHandlers instead of the current system of tacks and post-its.
- Basic combat? (bump into enemy and they DIE.)

At least one of the above should be done by version 0.2.0.

Also, i've tried to talk to my teachers in software development about version-handling, but they seem to have forgotten. How do you guys handle versions in your RLs? Do you keep meticoulus track of changes and additions? Do you just increase one digit everytime you make something work? Is there any book/site you would recomend me to read?

[Etinarg]

For my more elaborate projects I use a version management like CVS or SVN.

Version numbers I do increase for each release. I have no strict scheme, but the idea is roughly

1st digit: 0 until completed, 1 then
2nd digit: increase for every major feature being completed
3rd digit: increase for every minor feature completed
4th digit: For hotfixes which require a new version tag

Lately I got sloppy and only number stuff like 0.x and increase x a bit with each release. if I have a bugfix, that will be 0.28a or 0.28b if the base version was 0.28

That seems to work too. For the players the most important thing is to know which versions are newer or more complete than others.

[purestrain]

I usually specify my goals in advance aka "roadmap".

a.b.c.d

a = usually zero up until roadmap is completed
b = step of roadmap
c = minor step / re-release with bugfixes

if you are more or less addicted to software development you could have a branch for each B so you don't introduce new features while releasing a bugfix C.

[Etinarg]

Do you keep meticoulus track of changes and additions?

I use to keep a dev log or diary where I write short notes about each change. Usually just a line for each change, starting with "fix: " if it was a bugfix, "chg:" for any sort of change and "new:" for new features.

I found this very handy for writing release notes later, otherwise I'd surely forget most of the changes in between two releases.

[Slash]

For this, mantis is much better....

this, for example http://slashie.net/mantis

I can keep track of all the bugs fixed and request for enhancement implemented. I can also plan new features in the roadmap...

[mariodonick]

Well, yeah, bug tracking systems are nice, especially for professional projects with more than one developer.

Sometimes I use the one from Google Code:

http://code.google.com/p/lambdarogue/issues/list

But most of the time I'm too lazy to open up the web browser and to add a new entry -- a simple line in my local TODO file is written much faster. Some weeks ago, somebody gave me lots of bug reports and RFEs, and I actually added them to that issue list. That took much longer than simply adding it to my TODO file. Then, I often forget to change the status of open issues to "fixed" and "verified" -- cutting the issue from the TODO file and pasting it into the CHANGELOG is much easier.

[Krice]

I hate todo lists, because if you list all stuff it's going to get big and depressing. What I started to use in Teemu was a short "next thing to do" -list with observations I made that time I was coding, and added them to do next time. That way the list never grows too big and you have only few things to fix. It's also good in a way that at least my plans change all the time, so I don't have to worry about huge to do list becoming outdated and requiring cleaning/updating work as well.