Java RL tutorial!

[XLambda]

Since quite a few people seem to be interested in RL development with Java, and since there is no fitting tutorial that I know of, I've started to just go ahead and write one.

If everything goes right, it should:

-> be generic and not based on a single specific library. I'll use Slash's libjcsi, which is basically a swing implementation of curses, so the basic methods should all be provided by whichever library you prefer. (I'll encapsulate it anyways, so no worries.)

-> provide basic algorithms that, while not up to most people's standards, do the job and are easy to understand.

-> not do any l33t r0gu3l1k3 h4x. Yes, there are some crazy programming things you can do to make your life easier. Do they make things easier to understand? No.

-> result in a horribly soulless, unbalanced, flavourless, boring, playable little game. The emphasis is on playable, lol.

Once I have the basic data structures laid out, others are very welcome to contribute. I might put it up at roguebasin if people like it.

I do need some help, though - I'm searching for a simple and easy to understand FOV algorithm. I usually use something like MRPAS, but that's just waaay too complicated for a tutorial.

[george]

Once I have the basic data structures laid out, others are very welcome to contribute. I might put it up at roguebasin if people like it.

I think that's a good idea, Jotaf's Python tutorial at RB has become very popular.

You might want to think about leveraging existing libraries for things like FOV. For the purposes of a make a RL tutorial it might sidetrack people too much, unless your goal is to write a FOV tutorial too.

[XLambda]

Once I have the basic data structures laid out, others are very welcome to contribute. I might put it up at roguebasin if people like it.

I think that's a good idea, Jotaf's Python tutorial at RB has become very popular.

Yeah, I'm going to put it there once the first parts are done.

You might want to think about leveraging existing libraries for things like FOV. For the purposes of a make a RL tutorial it might sidetrack people too much, unless your goal is to write a FOV tutorial too.

Yeah, that's true. I'm not too fond of using yet another library, though... I think I'll cheat and implement Rogue-style fov, since I track rooms and tunnels seperately. Or would that be too simple, seeing as most modern roguelikes use more advanced algorithms? What do you people think?


EDIT: In hindsight, I might want to drop the encapsulation of the library. It feels cleaner to me, and allows people to exchange the library if they want, but it makes the key handling horribly awkward and complicated, and I think actually understanding what's going on might be more important than making the library exchangeable.  

[XLambda]

Okay everyone, the two first chapters are done and the third is being worked on. As soon as it's done, I'll put them on roguebasin for everybody to look at and comment. Probably tomorrow, if things work out.

Urist McProgrammer has claimed a Writer's Workshop!
Urist McProgrammer is working furiously!

[XLambda]

Okay, the first two lessons are up at roguebasin. 

http://roguebasin.roguelikedevelopment.org/index.php/Java_Roguelike_Tutorial

There wasn't enough time for the third, unfortunately. I'll do that after the 7drl week.

I'd appreciate some comments and constructive criticism. I tried not to do to much Java leetspeak, but you kind of have to assume that people know what a class is, or that it has a constructor.

[Nachtfischer]

Just skimmed through the first two parts. Though nothing revolutionary happened until now (not that it needed to in a tutorial ) that seems to be some pretty neat and solid stuff. Make it nice small and easy to follow steps, many tutorials really lack that property.

[requerent]

Many newbies go for IDEs like eclipse. These are tools intended for experienced developers, and their features are intended to automate frequent or annoying tasks, not to remove the necessity of knowing how to do them on your own.

Code completion, context hints and dynamic syntax checking are GREAT for new programmers or anyone using an unfamiliar library.



For the second tutorial- just a quick recommendation-- You've got a bunch of independent if statements. They really should be a switch, or at least a bunch of if-else statements- otherwise you're making a lot of wasted comparisons.

I'm not directly familiar with the CharKey constants, but here's the gist

Code: [Select]

//...
switch(csi.inKey().code)
{
case CharKey.UARROW: if(--y < 0)y++; break;
case CharKey.DARROW: if(++y > 24)y--; break;
case CharKey.LARROW: if(--x < 0)x++; break;
case CharKey.RARROW: if(++x > 79)x--; break;
case CharKey.Q: stop = true; break;
}
//...

In this case, you always have O(C) comparisons where C = 2, whereas otherwise you have O(N) comparisons- where N is the total possible number of input keys. It's so insignificant, but stuff like this is good to learn when the concepts are still simple and can make a big difference later in generation time when doing world-generation and historical simulations.

edit: stumbled across the proper keywords.

[XLambda]

Many newbies go for IDEs like eclipse. These are tools intended for experienced developers, and their features are intended to automate frequent or annoying tasks, not to remove the necessity of knowing how to do them on your own.

Code completion, context hints and dynamic syntax checking are GREAT for new programmers or anyone using an unfamiliar library.

I don't doubt that. My main sentiment here is that IDEs - besides the pure coding, for which they are undoubtably awesome - offer such a large and confusing set of features that you actually need to know what you're doing when using them.

For the second tutorial- just a quick recommendation-- You've got a bunch of independent if statements. They really should be a switch, or at least a bunch of if-else statements- otherwise you're making a lot of wasted comparisons.

I'm not directly familiar with the CharKey constants, but here's the gist

Code: [Select]

//...
switch(csi.inKey().code)
{
case CharKey.UP_ARROW: if(--y < 0)y++; break;
case CharKey.DOWN_ARROW: if(++y > 24)y--; break;
case CharKey.LEFT_ARROW: if(--x < 0)x++; break;
case CharKey.RIGHT_ARROW: if(++x > 79)x--; break;
case CharKey.Q: stop = true; break;
}
//...

In this case, you always have O(C) comparisons where C = 2, whereas otherwise you have O(N) comparisons- where N is the total possible number of input keys. It's so insignificant, but stuff like this is good to learn when the concepts are still simple and can make a big difference later in generation time when doing world-generation and historical simulations.

Yup, that I forgot. I'll change it.

[purestrain]

Its really boring; thats just another tutorial like any c ones, isn't it?

[XLambda]

Its really boring; thats just another tutorial like any c ones, isn't it?

I would say that Java and C/C++ are quite different languages, though the first few chapters don't really emphasize that.

[requerent]

Its really boring; thats just another tutorial like any c ones, isn't it?

I would say that Java and C/C++ are quite different languages, though the first few chapters don't really emphasize that.

Java prevents you from needing to do as much work >_>.

[TheCreator]

Java prevents you from needing to do as much work >_>.

Java only prevents you from having control over low-level operations, which may be a good thing if you are writing a coffeebreak game, or if you hate programming .

[requerent]

Java prevents you from needing to do as much work >_>.

Java only prevents you from having control over low-level operations, which may be a good thing if you are writing a coffeebreak game, or if you hate programming .

So all Java developers hate programming? 

That's probably true. After all, the increase in productivity means you 'get' to do less of it.

[XLambda]

Could you stop the hating, please? I know that you C++ folks think your language is better, and I'd be happy to argue with you as I speak both. But this is a tutorial, and a newb is not interested in whether Java is better or C++. And he sure as hell won't care about low-level programming. For tutorial purposes, Java has a few big advantages over C++, it's portable (one toolchain and one exec for all platforms), it has a huge class library and it abstracts from some of the more mind-boggling aspects of C++ (Pointers? Really, Stroustrup?).

Also, the only other tutorial at roguebasin is in Python, and I know what you C++ folks think of THAT language...

[kraflab]

Could you stop the hating, please? I know that you C++ folks think your language is better, and I'd be happy to argue with you as I speak both. But this is a tutorial, and a newb is not interested in whether Java is better or C++. And he sure as hell won't care about low-level programming. For tutorial purposes, Java has a few big advantages over C++, it's portable (one toolchain and one exec for all platforms), it has a huge class library and it abstracts from some of the more mind-boggling aspects of C++ (Pointers? Really, Stroustrup?).

Also, the only other tutorial at roguebasin is in Python, and I know what you C++ folks think of THAT language...

This discussion makes me wonder if a better tutorial might be one that is entirely pseudocode based.  Give someone the gist of what type of problems/solutions exist for roguelike programming, and show off the basics.  Maybe provide an implementation in a few languages at the end of each section so that the viewer can decide for themselves which language looks best for them.  Of course, your tutorial is exactly what it is supposed to be: a "Java" rl tutorial.  So I think the debate over which language is better is kind of irrelevant to this thread.  Although, in terms of "newb" friendliness I would have picked a language that already has everything you need, rather than something that requires importing libraries, not that there's anything wrong with that in the global sense.