Where to start?

On 6 Feb., 12:18, addcombatine... RemoveThis @gmail.com wrote:
> I want to get into roguelike development, but I have no idea where to
> start. If anyone can give me a push in the right direction, I'd be
> forever grateful.

This list might be used as a starting point:

http://roguebasin.roguelikedevelopment.org/index.php?title=How_to_Writ..._Roguel

Christopher Charles
 >> Stay informed about: Where to start? 

On 6 Feb, 12:18, addcombatine....RemoveThis@gmail.com wrote:
> I want to get into roguelike development, but I have no idea where to
> start. If anyone can give me a push in the right direction, I'd be
> forever grateful.

1. Write code.
2. ?
3. Zorkmids!

-the ru
 >> Stay informed about: Where to start? 

I myself begun with thinking of some general mechanics of the game,
and them porting them to the programming language. I mean, that it is
good to know what do you need your code to do. It is also vital to
remember to not make mess in your code. This is because as your
project will get more and more complicated u may find yourself having
no idea on how the thigs are working,

This is what I've done writing my roguelike:
1. Invented general type of game. In my case it is battle-centered
2. Thought about what i will need my interface to do
3. Created some basic classes which are going to be bases for more
specialistic ones. Base classes can be i.e. map tile, base creature,
base map object, base item, etc
4. Made a serious attempt to to make a '@' move on a meadow with
randomly generated trees (in the way that trees block your movement).
5. Made a search in my code to find which operations were repeating
and closed them into functions.

In case u were using c++:
-make each class definition in separate file+header. This will save
you from a serious mess (believe me ;p)
-use definitions extensively. it is easier to use values like
TERRAIN_TYPE_GRASS, than to remember that 1 is grass, 2 is dirt and so
on. As your project grows in size u will find defines priceless ;]
-be sure to make your code immune to most regular exceptions, like for
example index out of array of division by 0. This will help you,
because it lessens the amount of thing u have to check if something
doesn't work as you expect it to (believe me, it will happen ;] )
 >> Stay informed about: Where to start? 

On 11 Feb, 22:46, poorch... DeleteThis @gmail.com wrote:
> I myself begun with thinking of some general mechanics of the game,

<snip>

Please quote some context. USENET is not a web forum; some users might
get the messages in another order than they appear on Google Groups.

> -use definitions extensively. it is easier to use values like
> TERRAIN_TYPE_GRASS, than to remember that 1 is grass, 2 is dirt and so
> on. As your project grows in size u will find defines priceless ;]

Use enums if possible; they are often better than #defines as the
compiler can help you detect problems with them (example: gcc can
report when you switch() an enum and not all values are covered in the
switch).

I'm not sure if it's a good idea to use them as array indices though;
I do it, but it's probably bad practice.

> -be sure to make your code immune to most regular exceptions, like for
> example index out of array of division by 0. This will help you,
> because it lessens the amount of thing u have to check if something
> doesn't work as you expect it to (believe me, it will happen ;] )

You should *always* check for null pointers, out-of-bounds array
indices and division (and modulo! - e.g. rand()) by zero. Never trust
your code to be doing what it should. It *will* save time - you'll be
able to tell *where* it breaks instead of tracing a bad pointer
through 7 levels of function calls.

And while we're on the subject: learning to use a debugger properly is
time well spent.

-the ru
 >> Stay informed about: Where to start? 

On 12 fév, 09:22, "Ulf Åström" <ulf.ast....DeleteThis@gmail.com> wrote:
>
> You should *always* check for null pointers, out-of-bounds array
> indices and division (and modulo! - e.g. rand()) by zero. Never trust
> your code to be doing what it should. It *will* save time - you'll be
> able to tell *where* it breaks instead of tracing a bad pointer
> through 7 levels of function calls.

I personally never check for null pointers or out-of-bounds array
indices for several reasons :
- the code is easier to read without all those tests
- using gdb + electric fence, it's much easier to detect those errors
if you let the SIGSEV reach the debugger. The program stops exactly at
the incriminated line and let you watch the content of the variables.

Sadly, this applies only to Linux developpers because I've never seen
something equivalent to electric fence on Windows. Even the Visual
Studio crtdbg tool is not as powerful. Maybe electric fence compiles
on cygwin but I never tried.

--
jice
 >> Stay informed about: Where to start? 

On 12 Feb, 10:35, jice <jice.nos....RemoveThis@gmail.com> wrote:
> I personally never check for null pointers or out-of-bounds array
> indices for several reasons :
> - the code is easier to read without all those tests
> - using gdb + electric fence, it's much easier to detect those errors
> if you let the SIGSEV reach the debugger. The program stops exactly at
> the incriminated line and let you watch the content of the variables.

Doesn't this mean you only catch the errors that actually *occur*? A
seldom-used part of the code could have a million dormant bugs that
aren't noticed until your game crashes on some players machine (where
it will be much harder to debug).

I try to catch errors as soon as possible - if my functions don't
receive the required information, I won't allow them to proceed.

-the ru
 >> Stay informed about: Where to start? 

On 12 fév, 10:52, "Ulf Åström" <ulf.ast....TakeThisOut@gmail.com> wrote:
> On 12 Feb, 10:35, jice <jice.nos....TakeThisOut@gmail.com> wrote:
>
> > I personally never check for null pointers or out-of-bounds array
> > indices for several reasons :
> > - the code is easier to read without all those tests
> > - using gdb + electric fence, it's much easier to detect those errors
> > if you let the SIGSEV reach the debugger. The program stops exactly at
> > the incriminated line and let you watch the content of the variables.
>
> Doesn't this mean you only catch the errors that actually *occur*? A
> seldom-used part of the code could have a million dormant bugs that
> aren't noticed until your game crashes on some players machine (where
> it will be much harder to debug).
>

If the crash can be reproduced, this is not an issue. A crash occuring
randomly (due to a memory corruption or a very rare condition) will be
difficult to debug in both cases expected if your error logging system
gives you enough information like the call stack and some variables
values, which would probably result in a very bloated code. The only
way to deal with those errors is heavy testing by spending lot of time
playing your game or using automated tests like Jeff Lait.

I'm not saying that my system is better. I think both are as
effective. Mine is more adapted to lazy people like me . The
differences from my point of view :
- you spend more time in coding tests and error logging and your code
is heavier
- I spend more time in testing my game by playing it under gdb and my
code is lighter

--
jice
 >> Stay informed about: Where to start? 

On 12 Feb, 11:29, jice <jice.nos... DeleteThis @gmail.com> wrote:
> If the crash can be reproduced, this is not an issue. A crash occuring

I think the fundamental difference is that I'm trying to prevent
crashes from occuring at all. As player, I'd rather see feature X not
working than losing a promising character because of a crash. As
developer, it's much more useful to get a "feature X doesn't work" bug
report than "my game crashes randomly".

> - you spend more time in coding tests and error logging and your code
> is heavier
> - I spend more time in testing my game by playing it under gdb and my
> code is lighter

I don't think it's that simple. Our basic designs are probably very
different as well, so just comparing line count or whatever wouldn't
make much sense. :-]

-the ru
 >> Stay informed about: Where to start? 

On 12 fév, 11:55, "Ulf Åström" <ulf.ast... RemoveThis @gmail.com> wrote:
> On 12 Feb, 11:29, jice <jice.nos... RemoveThis @gmail.com> wrote:
>
> > If the crash can be reproduced, this is not an issue. A crash occuring
>
> I think the fundamental difference is that I'm trying to prevent
> crashes from occuring at all. As player, I'd rather see feature X not
> working than losing a promising character because of a crash. As
> developer, it's much more useful to get a "feature X doesn't work" bug
> report than "my game crashes randomly".
>

Ok, I'm kind of intentionally playing devil's advocate here. I'm not
saying that I'm right and you're wrong. I think both approachs are
viable. Of course, the less crashes you have, the better it is and if
you can avoid some of them by pre-conditions, it's ok. But avoiding
blindly the crashes everywhere will make it very difficult to find the
nasty bugs. I'm speaking about this kind of error handling code :

void my_func (params) {
if (crash condition meet) return; // do nothing
... // do something
}

This will take you to the hell of debugging because you may never
notice that there was something wrong during this function call and
the first visible impact may lead you to the wrong track. IMHO, the
proper handling of an unexpected crash condition would be :

void my_func (params) {
if (crash condition meet) {
// log error and everything needed to track its cause
exit(1);
}
... // do something
}

The exit() is very important because it will allow to correlate the
player's last action/situation to the error. If you only write a log
and keep running the game :
- the player may never notice the error
- he may notice it much later in the game and may not be able to find
out what was its cause.

To finish, I think our two approachs follow two distinct goals :
- either you add lots of controls in the code so that the game never
crashes whatever bugs it contains. This will smooth the player
experience, but your code will be more complicated and some bugs will
be difficult to fix without a very advanced logging system.
- either you let the bugs crash or stop the game. This will be very
painful for the player if you don't do enough testing before
releasing, but eventually, bugs will be corrected faster (and the code
is simpler) (and you need electric fence to use this approach)

--
jice
 >> Stay informed about: Where to start? 

On 12 Feb, 15:05, Gerry Quinn <ger....RemoveThis@indigo.ie> wrote:
> In article <bc29874e-db48-48b9-8691-
> f04827440....RemoveThis@j20g2000hsi.googlegroups.com>, ulf.ast....RemoveThis@gmail.com says...
> > You should *always* check for null pointers, out-of-bounds array
> > indices and division (and modulo! - e.g. rand()) by zero. Never trust
> > your code to be doing what it should. It *will* save time - you'll be
> > able to tell *where* it breaks instead of tracing a bad pointer
> > through 7 levels of function calls.
>
> ...on the other hand, a good debugger can already check for these.  And
> maybe adding a default potion might be quicker than writing the
> assert...

I don't really understand what you mean. It doesn't matter what
debugger you have if you're using an unchecked variable as array index
- it's gonna crash anyway.

-the ru
 >> Stay informed about: Where to start? 

On 12 fév, 15:59, "Ulf Åström" <ulf.ast... RemoveThis @gmail.com> wrote:
> On 12 Feb, 15:05, Gerry Quinn <ger... RemoveThis @indigo.ie> wrote:
>
> > In article <bc29874e-db48-48b9-8691-
> > f04827440... RemoveThis @j20g2000hsi.googlegroups.com>, ulf.ast... RemoveThis @gmail.com says...
> > > You should *always* check for null pointers, out-of-bounds array
> > > indices and division (and modulo! - e.g. rand()) by zero. Never trust
> > > your code to be doing what it should. It *will* save time - you'll be
> > > able to tell *where* it breaks instead of tracing a bad pointer
> > > through 7 levels of function calls.
>
> > ...on the other hand, a good debugger can already check for these.  And
> > maybe adding a default potion might be quicker than writing the
> > assert...
>
> I don't really understand what you mean. It doesn't matter what
> debugger you have if you're using an unchecked variable as array index
> - it's gonna crash anyway.
>

Not crash, halt the program at the incriminated line, allowing you to
watch variables content and fix the bug very easily.

--
jice
 >> Stay informed about: Where to start? 

On Feb 12, 7:52 am, jice <jice.nos... DeleteThis @gmail.com> wrote:
> > report than "my game crashes randomly".
>
> Ok, I'm kind of intentionally playing devil's advocate here. I'm not
> saying that I'm right and you're wrong. I think both approachs are
> viable. Of course, the less crashes you have, the better it is and if
> you can avoid some of them by pre-conditions, it's ok. But avoiding
> blindly the crashes everywhere will make it very difficult to find the
> nasty bugs. I'm speaking about this kind of error handling code :
>
> void my_func (params) {
> if (crash condition meet) return; // do nothing
> ... // do something
> }
>
> This will take you to the hell of debugging because you may never
> notice that there was something wrong during this function call and
> the first visible impact may lead you to the wrong track.

This is a very good point that I agree with. You don't want to hide
bad behaviour, you want it to be detected immediately.

> IMHO, the
> proper handling of an unexpected crash condition would be :
>
> void my_func (params) {
> if (crash condition meet) {
> // log error and everything needed to track its cause
> exit(1);
> }
> ... // do something
> }
>
> The exit() is very important because it will allow to correlate the
> player's last action/situation to the error. If you only write a log
> and keep running the game :
> - the player may never notice the error
> - he may notice it much later in the game and may not be able to find
> out what was its cause.

This, however, I disagree with. The player's job isn't to debug your
game. If the player never notices there was an error, was there an
actual error?

Take something like the GBA which will happily let you dereference
null pointers. Players would be justifiably angered if I had POWDER
crash in those cases rather than keep playing.

The problem is there are two audiences for the same program. The
progammer/tester wants the program to crash rather than generate a
wrong result. The program user would rather get a wrong result than
crash. (Indeed, in a game, they might not even know it is a wrong
result!)

Fortunately, there is a workable compromise:

> void my_func (params) {
> if (crash condition meet) {
> ASSERT(!"Crash condition met!");
> return;
> }

Your debug build has the assertion trigger a break into your debugger
of choice. The release build removes the assertion test entirely, so
the player gets the safety-net code.

I would, however, also suggest a minimization of safety-net code. If
you think it is likely you'd make that mistake, it might be better to
make the safety-net code an explicit part of your interface.

I recently, with Richard Quirk's help, added the ability for items to
teleport and fall down holes. This proved surprisingly tricky - it
took four tries to get right. Each try took a few hours of automated
testing to find the next unusual confluence of conditions that messed
up my object model. (Clearly this is also a sign that my semantics
for object ownership are horribly convoluted, which is correct :>)
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 >> Stay informed about: Where to start? 

On 12 Feb, 13:52, jice <jice.nos... RemoveThis @gmail.com> wrote:
> Ok, I'm kind of intentionally playing devil's advocate here. I'm not
> saying that I'm right and you're wrong. I think both approachs are

There isn't really any right and wrong here. :-]

> viable. Of course, the less crashes you have, the better it is and if
> you can avoid some of them by pre-conditions, it's ok. But avoiding
> blindly the crashes everywhere will make it very difficult to find the
> nasty bugs. I'm speaking about this kind of error handling code :

I consider anything that crashes my game a nasty bug. :-]

> The exit() is very important because it will allow to correlate the
> player's last action/situation to the error.

I don't see the advantage of using exit() - I'd rather let it crash,
and be able to backtrace from that point?

> To finish, I think our two approachs follow two distinct goals :
> - either you add lots of controls in the code so that the game never
> crashes whatever bugs it contains. This will smooth the player
> experience, but your code will be more complicated and some bugs will
> be difficult to fix without a very advanced logging system.

You're exaggerating. Coding defensively doesn't require much of a
logging system. I only fprintf() some stuff to stderr once, and most
things can be determined anyway by just peeking around with the
debugger. The extra checks might indeed make the code *bigger*, but
not necessarily more complex. Bugs are easy to find; once I'm beyond
the checks and have made sure I have sane values to work with, I can
be fairly sure any logic errors that occur are *in the function* and
not somewhere else.

> - either you let the bugs crash or stop the game. This will be very
> painful for the player if you don't do enough testing before
> releasing, but eventually, bugs will be corrected faster (and the code
> is simpler) (and you need electric fence to use this approach)

Nothing prevents *both* coding defensively *and* testing the game
thoroughly before release. :-]

Anyway - I doubt a game that crashes randomly will help any bugs get
fixed. Most players will just be frustrated and quit playing instead.
I also believe it's easier for non-technical players to report missing/
malfunctioning features than crashes. And if they don't notice
anything is wrong, perhaps the bug is even a feature? :-O

-the ru
 >> Stay informed about: Where to start?