The Beginners Guide to Roguelikes (v 0.0.0.0.0.0.1a)

External Since: Nov 21, 2007 Posts: 15

On Nov 23, 8:16 am, Gerry Quinn <ger....RemoveThis@indigo.ie> wrote:
> The only thing I'd add is that it's a very good introductory tutorial,
> but you are not using C++ except for double-slash style comments!

Ha ha, true!

> I would describe the code instead as very simple C. (Which is fine,
> it is probably far more accessible to its target audience writing in C
> or similar languages such as Basic.)
>
> Making the map global is perfectly feasible when coding a simple
> roguelike, but it kind of vitiates any notion of using classes for
> encapsulation and access control.

You are totally right, and I've debated with my self about this at
quite length. I believe that OOP is an inescapable, fundamental tool
if you're making even a half-serious Roguelike. (Not saying it can't
be done without, but why on earth would you handicap yourself?)
However, it requires considerably more design and forethought than
your normal old-school procedural approach. My fear is that in doing
this, I will loose people right off the bat. I'm trying to keep it
simple and straightforward and (especially at the beginning) allowing
people to play and fiddle around with what they've made. I mean back
when I was 14, my first RL design did this. Didn't yours? My whole
goal is to let them "catch the bug" and progressively get more
involved in the intricacies of coding, which will be tolerable (even
interesting) when they see the reason for it.

Anyways, if you have any ideas about when and how to put OOP in action
let me know. I am leaning more towards the NPC articles. I used to
tutor back in my college days, and I would use NPC design in games as
a way to explain OOP to students. It always amazes me to see how many
people cannot understand that design paradigm, but putting it in
application helps infinitely.

But you're right though, and I'm not entirely convinced what I'm doing
is the right way to do it.

External Since: Jun 17, 2006 Posts: 20

On Nov 23, 11:53 am, Craig <craig.stic....RemoveThis@gmail.com> wrote:
> On Nov 23, 8:16 am, Gerry Quinn <ger....RemoveThis@indigo.ie> wrote:
> You are totally right, and I've debated with my self about this at
> quite length. I believe that OOP is an inescapable, fundamental tool
> if you're making even a half-serious Roguelike. (Not saying it can't
> be done without, but why on earth would you handicap yourself?)

*snip*

> But you're right though, and I'm not entirely convinced what I'm doing
> is the right way to do it.

Keep any lesson code that's not related to the lesson as simple as
possible to start, and gradually include the complexities as they
become relevant, I would suggest. Put the bulk of the code (and
comments) in whatever you're working on in that lesson, unless you've
already gone over it, I'd suggest...

Also, re OOP: A lot of people are not just learning object-oriented
languages, but beginning with object oriented languages, such as Java.

> Anyways, if you have any ideas about when and how to put OOP in action
> let me know. I am leaning more towards the NPC articles. I used to
> tutor back in my college days, and I would use NPC design in games as
> a way to explain OOP to students. It always amazes me to see how many
> people cannot understand that design paradigm, but putting it in
> application helps infinitely.

If by NPC design you mean this metaphor:

Class = class;
Object = one NPC;
Class variable = a NPC's stat;
Method = a skill or ability of that class;

When my first Java professor put it that way, that's when I finally
grasped OOP concepts. And considering your target audience, I'd think
that'd be the perfect way to handle it.

-- Shanya Almafeta