Re: Newbie Guide to Roguelikes (Update)

On Oct 23, 5:41 pm, Craig <craig.stic...@xxxxxxxxx> wrote:
jotaf wrote:
What about dungeon generation, are you leaving that one out? It's an
entire series of articles on its own, but a gentle introduction
wouldn't hurt :)

Good point! Dungeon generation was actually something I forgot
about... go figure. At first reaction, I'm a little scared to jump
into that. An introduction would be nice, but I want these articles to
have direct application and practicality - which I find hard to
reconcile the concept of an introduction with.

In walking around the map you will probably introduce the simplest
form of dungeon generation:
char *glb_mymap[] = {
" ", // 0
" ", // 1
" WWWWWWW ", // 2
" W.....W WWWWWWWWWWWW ", // 3
" W..U..D... W..........W ", // 4
" W.....W . W..........W ", // 5
" WWWWWWW . W..........W ", // 6
" ....D..........W ", // 7
" . WWWWWWWWWWWW ", // 8
" . ", // 9
" WWWWDWWWW ", // 10
" W.......W ", // 11
" W.......W ", // 12
" W.......W ", // 13
" WWWWWWWWW ", // 14
" ", // 15
" ", // 16
" ", // 17
" ", // 18

(This is the hard coded map that was used in the prototype for POWDER)

More serious techniques can safely be saved till much later.

I would take issue with a more important thing you are missing:
Monsters! Someone will have completed your entire tutorial and yet
still not have a game!

Insert the following chapters:

3.1: Monsters on your map

Create a bunch of rats that wander with (rand()%3)-1 around your map!

3.2: Mortal Combat

Add a HP variable and Bump To Attack

3.3: Smarter than your average Rat

"Chasing" AI: dx = sign(x1 - x2)
"Fleeing" AI: dx = -sign(x1 - x2)

Plus it's not my strong
suite. Perhaps another author would be better for that, I don't know.
It almost is a separate side of theory - I am intending to have the
guide to have the game-engine basics that everybody takes for granted.

I think it is best for the guide - at least the start of it - to stick
to those game engine basics everyone takes for granted. The idea of
computing a deltax and deltay for movement, to take the sign of the
difference for the direction, etc, are not obvious.

I also think it is important for the guide to build a *game* first.
This is building a "walk around a level with an NPC and elegant code
behind it". Screw elegant code. Save that for the rewrite. Get the
user facing a roguelike as fast as possible. Get them easy to edit
and tweak code.

On that vein, after introducing the monster chapters, I'd skip the NPC
chapter entirely (or put in a much later tutorial) In Using Items I
don't understand the log cutting example. What about zapping wands?
Throwing daggers? Firing bows? Equipping swords? Those are item
uses I'd like to see at that stage.

In data management, your Advanced Data Management section can be
difficult depending on how it is done. In any case, somewhere around
here should go a section in using external configuration files to
populate the data. Filling in C structs by hand gets old fast.

The OOP section all looks too abstract from here - return to the game!

Hmm... I'll have to think about that some more.

IMO, if the articles are well-written, many of these chapters would
only be describing a few lines of code, and wouldn't take more than
two or three pages.

The first few articles I had wrote (before the catastrophic crash of
doom) had averaged about 50-70 lines of code per article. Which, given
my line hungry style and excessive commenting isn't that bad actually.
Actual article length was about 5-7 pages. I tried to keep it simple
and practical, with a sort of feel of somebody sitting down and
walking you through the development process on the back of a beer-
stained napkin - where all great ideas originate. :P

A nice casual conversational approach to this sort of tutorial could
work very well. A big problem with programming is it is very easy to
start reading faster than one's comprehension. So one zooms past
"easy" parts and soon finds oneself drowning. This is where the
wordier "fun" explanation can slow people down so they actually
understand the example.

At any rate, we'll see what happens.

Good luck, sounds like a fun read.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

.

Relevant Pages

  • Re: Outline levels went bad
    ... same way as the map does. ... exactly as the articles say. ... then turn the outline level back to body text. ... After fixing all of the bad entries, everything is ok in both the ...
    (microsoft.public.word.application.errors)
  • Re: Direct extraction of BibTeX record from a doi
    ... A little trickier are DOIs like 10.1109/4434.588295 which you just have to know map to some article in IEEE Concurrency (although some IEEE Concurrency articles' ...
    (comp.text.tex)
  • Re: Fill an irregular shape with color
    ... Find great Windows Forms articles in Windows Forms Tips and Tricks ... Answer those GDI+ questions with the GDI+ FAQ ... Let's say I have a map of North America and I want to paint the USA ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: evidences against subduction theory
    ... It's in the "From:" header field of yours articles, ... inside brackets. ... This is not a valid email address. ... Then you don't know what is a map. ...
    (sci.geo.geology)
  • Re: Recommended backgammon resources?
    ... There is a good selection of strategy articles to read in the GammonLife.com Writers section at this link: ... Mary Hickey's series of "Game Plan Selection" articles are brief but instructive and there are 13 of them here: ... If you do not already have it, get the GNUbg program, which you can play against and analyze yourself with, a tutorial by Robert-Jan Veldhuizen on how to download and use it starts here: ... If you want to learn a method to record your live games so you can analyze yourself later with GNUbg or another bot, expert Jay Bidal has written "Towards a Better Method of Recording Backgammon Games" found here: http://www.gammonlife.com/06bidal1.htm ...
    (rec.games.backgammon)