Delayed actions in turn-based systems

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Hey. Sorry for not keeping the other topics I started alive (3D ASCII
and Perl roguelike). I've got version 0.0.2 of my software done, but
it's still just a shell. I'll release everything soon, under the GPL, of
course.

I've run into a problem. If the player tries to pick up something where
multiple items reside, I'll have the game ask the player what to pick
up. But if they try to pick up two or more objects, should that cause
two or more turns to pass? A turn in my engine is pretty much figuring
out what's to be done (By means of inputting a command or delayed
actions; see blow.) then trying to do it. Different event handlers can
interrupt. But always, after all that, the event queue is processed,
which causes monsters to move and attack and things that happen every
turn to happen. In most of the roguelikes I've played, it seems picking
up multiple items compromises all of one turn. I suppose this is fine.
I'm not going for an overwhelming amount of realism or anything, but I
want the system to be flexible. In adom, for instance, eating takes a
while if you're being attacked. I recall a discussion on putting on and
taking off armour a while ago. I have a feeling adding this sort of
complexity to the engine this early could cause problems.

Now that I think about it, there's no reason to introduce too much
complexity this early. Is it OK to make every action be counted as one
turn, taking the same amount of "time" or should things get more
specific? I know it depends on the game itself, but I'm curious to hear
what others think.

I'll veer off-topic for a minute. I'm fortunate enough to actually have
a friend that I see every day in school that enjoys roguelikes, because
I introduced them to him. Are others fortunate enough to have
role-playing buddies in reality? If we were interested in role-playing,
where should we start? Dungeons and Dragons looks neat, but a bit
complex. Does anybody know of a sort of DnD board game? Same rules and
mechanics, but not really requiring a DM? Something easy for people who
know and enjoy roguelikes.

Anyway, I'll try and put up a page for my Perl roguelike sometime this
weekend and release 0.0.3. Good luck to everybody else!

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

At Tue, 13 Sep 2005 21:24:09 GMT,
Da-Breegster wrote:

> I've run into a problem. If the player tries to pick up something where
> multiple items reside, I'll have the game ask the player what to pick
> up. But if they try to pick up two or more objects, should that cause
> two or more turns to pass? A turn in my engine is pretty much figuring
> out what's to be done (By means of inputting a command or delayed
> actions; see blow.) then trying to do it. Different event handlers can
> interrupt. But always, after all that, the event queue is processed,
> which causes monsters to move and attack and things that happen every
> turn to happen. In most of the roguelikes I've played, it seems picking
> up multiple items compromises all of one turn. I suppose this is fine.
> I'm not going for an overwhelming amount of realism or anything, but I
> want the system to be flexible. In adom, for instance, eating takes a
> while if you're being attacked. I recall a discussion on putting on and
> taking off armour a while ago. I have a feeling adding this sort of
> complexity to the engine this early could cause problems.

It all depends on how you handle time in your game. What your main game
loop looks like?

From what I've seen and imagined, there are several ways to do it:

Player-centric:
Have the main game loop handle UI and call move_monsters() (or
generally any other function that advances the whole world a turn)
in the code for some of the player actions (the ones that consume
a turn). Generally inflexible approach, altrough might seem appealing
for animation-heavy and "modern" game.

Simple turns:
You've got your main loop that iterates over all the "actors" (things
that can act, be it the player character, the monster or self-closing
door), asks them what they want to do and performs it if it's
possible. The actors might still be able to do some things by
themselves, without consuming a turn.
This approach is better, but it's a bit awkward to write the actor's
code, because every turn the function is called anew -- you've got
to record all state information in the actor's data, and probably do
a switch statement at the beginning of the actor's code...
Note that "slow" monster may wait once per several turns, and "fast"
monsters can perform some actions without returning, but it's a little
messy.
If you want an action like eating to take several turns, you just
mark in the actor's data that it's eating, check for interrupts,
update teh counters and return.

Queued turns:
In this approach you've got a kind of priority queue, or other similar
thing, that holds the actors. You remove actors from the queue, call
their functios, perform their actions and then put them back into
the a sorted position into the queue. The position depends on how much
time the action took -- you must keep track of it.
Interrupts can be handled in two ways -- you can use small steps for
long actions, exactly like in the previous approach, or you can use
more accurate system:
Have the action separated into the preparation adn the effect parts.
When you add do queue an actor that decided to do a preparation
action, add it with proper delay, but add it also to a special
"watchers" lists. Every time any actor does something, all the
actors in the "watchers" list are informed about it and have to
decide whether continue the preparation (then nothing happends) or
interrupt it (then they are moved to the beginning of the queue), then
the "preparation" is cancelled and they are free to decide upon their
own action. When you reach in the queue an actor that was "preparing"
and didn't cancel it, it can do the "effect" part of it's action,
actually performing it.

Energy systems:
They are various and usually complicated. Basically, the game time
is separated into "ticks" -- they are like turns in the "simple turns"
approach. A main loop iterates over all the actors every tick,
increasing their "energy" counters. Every action has an energy cost.
When an actor declares an action, it's first checked whether it has
enough energy for it -- if yes, the energy is deducted and teh action
is performed instantly. If no, the actor waits until it accumulates
enough. If he decides to interrupt the wait, he can use up the
accumulated energy right away. You usually can't accumulate more
energy than a certain limit.


> Now that I think about it, there's no reason to introduce too much
> complexity this early. Is it OK to make every action be counted as one
> turn, taking the same amount of "time" or should things get more
> specific? I know it depends on the game itself, but I'm curious to hear
> what others think.

No matter how simple or complicated is your time system, you'll definitely
need both actions that take turn (walking, fighting) and "actions" that doesn't
(checking stats, reading manual, browsing inventory). So it's a "needed
complexity". On the other hand, you don't have to prompt the player
to choose all the items he wants to pick up. You could for example make
only the first pickup action in a row take a turn -- so that subsequent
pickups are "free".

Don't let your UI change your game mechanics. It should be the other way
around.

--
Radomir `The Sheep' Dopieralski @**@_
(@a) 3 Be?
. . . ..v.vVvVVvVvv.v.. .

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Radomir 'The Sheep' Dopieralski wrote:
> At Tue, 13 Sep 2005 21:24:09 GMT,
SNIP
> Player-centric:
> Have the main game loop handle UI and call move_monsters() (or
> generally any other function that advances the whole world a turn)
> in the code for some of the player actions (the ones that consume
> a turn). Generally inflexible approach, altrough might seem appealing
> for animation-heavy and "modern" game.
>
> Simple turns:
> You've got your main loop that iterates over all the "actors" (things
> that can act, be it the player character, the monster or self-closing
> door), asks them what they want to do and performs it if it's
> possible. The actors might still be able to do some things by
> themselves, without consuming a turn.
> This approach is better, but it's a bit awkward to write the actor's
> code, because every turn the function is called anew -- you've got
> to record all state information in the actor's data, and probably do
> a switch statement at the beginning of the actor's code...
> Note that "slow" monster may wait once per several turns, and "fast"
> monsters can perform some actions without returning, but it's a little
> messy.
> If you want an action like eating to take several turns, you just
> mark in the actor's data that it's eating, check for interrupts,
> update teh counters and return.
>
> Queued turns:
> In this approach you've got a kind of priority queue, or other similar
> thing, that holds the actors. You remove actors from the queue, call
> their functios, perform their actions and then put them back into
> the a sorted position into the queue. The position depends on how much
> time the action took -- you must keep track of it.
> Interrupts can be handled in two ways -- you can use small steps for
> long actions, exactly like in the previous approach, or you can use
> more accurate system:
> Have the action separated into the preparation adn the effect parts.
> When you add do queue an actor that decided to do a preparation
> action, add it with proper delay, but add it also to a special
> "watchers" lists. Every time any actor does something, all the
> actors in the "watchers" list are informed about it and have to
> decide whether continue the preparation (then nothing happends) or
> interrupt it (then they are moved to the beginning of the queue), then
> the "preparation" is cancelled and they are free to decide upon their
> own action. When you reach in the queue an actor that was "preparing"
> and didn't cancel it, it can do the "effect" part of it's action,
> actually performing it.
>
> Energy systems:
> They are various and usually complicated. Basically, the game time
> is separated into "ticks" -- they are like turns in the "simple turns"
> approach. A main loop iterates over all the actors every tick,
> increasing their "energy" counters. Every action has an energy cost.
> When an actor declares an action, it's first checked whether it has
> enough energy for it -- if yes, the energy is deducted and teh action
> is performed instantly. If no, the actor waits until it accumulates
> enough. If he decides to interrupt the wait, he can use up the
> accumulated energy right away. You usually can't accumulate more
> energy than a certain limit.

Wikified

SNIP
> --
> Radomir `The Sheep' Dopieralski @**@_
> (@a) 3 Be?
> . . . ..v.vVvVVvVvv.v.. .

--
Slash

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Radomir 'The Sheep' Dopieralski wrote:
> At 14 Sep 2005 04:43:27 -0700,
> SZDev - Slash wrote:
>
> >
> > Radomir 'The Sheep' Dopieralski wrote:
> >> At Tue, 13 Sep 2005 21:24:09 GMT,
> > SNIP
> >
> > Wikified
> >
> > SNIP
>
> I'm sure there are much better and in-depth articles about handling
> time in roguelikes in the group's archives (this one is messy).

A start is a start

>
> There are also very interesting time systems I haven't mentioned,
> like the DeadCold's one.

They can always be added.

>
> --
> Radomir `The Sheep' Dopieralski @**@_
> (*+) 3 Sparkle
> . . . ..v.vVvVVvVvv.v.. .

--
Slash

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster wrote:
> Hey. Sorry for not keeping the other topics I started alive (3D ASCII
> and Perl roguelike). I've got version 0.0.2 of my software done, but
> it's still just a shell. I'll release everything soon, under the GPL, of
> course.
>
> I've run into a problem. If the player tries to pick up something where
> multiple items reside, I'll have the game ask the player what to pick
> up. But if they try to pick up two or more objects, should that cause
> two or more turns to pass? A turn in my engine is pretty much figuring
> out what's to be done (By means of inputting a command or delayed
> actions; see blow.) then trying to do it. Different event handlers can
> interrupt. But always, after all that, the event queue is processed,
> which causes monsters to move and attack and things that happen every
> turn to happen. In most of the roguelikes I've played, it seems picking
> up multiple items compromises all of one turn. I suppose this is fine.
> I'm not going for an overwhelming amount of realism or anything, but I
> want the system to be flexible.

For it to be flexible you must be able to define the cost of the action
based on the parameters used to execute it; for example a 'Get' action
needs a list of items as parameters, and you may calculate the cost of
the action based on the quantity, weight, shape, materials, etc fo your
items... just dont get too fancy or *realistic*.

> In adom, for instance, eating takes a
> while if you're being attacked. I recall a discussion on putting on and
> taking off armour a while ago. I have a feeling adding this sort of
> complexity to the engine this early could cause problems.

A posible solution would be to make actors able to choose a chain of
actions instead of a single action via their AI modules; they then
proceed to execute each atomic action and get to pick a new one if
their routine is interrupted.
>
> Now that I think about it, there's no reason to introduce too much
> complexity this early. Is it OK to make every action be counted as one
> turn, taking the same amount of "time" or should things get more
> specific? I know it depends on the game itself, but I'm curious to hear
> what others think.

CastlevaniaRL uses a simple queue to control the actors and it works
fine; most people who play the game ocasionally wont ever notice the
difference.

On the other hand, Guardian Angel uses some sort of priority queue, I
guess it is because it is got more complex interactions and thus a
queue would make things look just weird.

So I guess it is ok if your interactions are not very complex.

>
> I'll veer off-topic for a minute. I'm fortunate enough to actually have
> a friend that I see every day in school that enjoys roguelikes, because
> I introduced them to him. Are others fortunate enough to have
> role-playing buddies in reality?

Not me... everybody looks weird at me when I show them a 'Game' that is
played on an ASCII window.

> If we were interested in role-playing,
> where should we start? Dungeons and Dragons looks neat, but a bit
> complex. Does anybody know of a sort of DnD board game? Same rules and
> mechanics, but not really requiring a DM? Something easy for people who
> know and enjoy roguelikes.

I dont have a clue, perhaps 'ADOM: The RPG'? xD

>
> Anyway, I'll try and put up a page for my Perl roguelike sometime this
> weekend and release 0.0.3. Good luck to everybody else!

Thanks,

--
Slash
[http://peltkore.net/~szdev

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

At 14 Sep 2005 04:43:27 -0700,
SZDev - Slash wrote:

>
> Radomir 'The Sheep' Dopieralski wrote:
>> At Tue, 13 Sep 2005 21:24:09 GMT,
> SNIP
>
> Wikified
>
> SNIP

I'm sure there are much better and in-depth articles about handling
time in roguelikes in the group's archives (this one is messy).

There are also very interesting time systems I haven't mentioned,
like the DeadCold's one.

--
Radomir `The Sheep' Dopieralski @**@_
(*+) 3 Sparkle
. . . ..v.vVvVVvVvv.v.. .

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On Tue, 13 Sep 2005 21:24:09 GMT, Da-Breegster <dabreegster@gmail.com>
wrote:

>I'll veer off-topic for a minute. I'm fortunate enough to actually have
>a friend that I see every day in school that enjoys roguelikes, because
>I introduced them to him. Are others fortunate enough to have
>role-playing buddies in reality? If we were interested in role-playing,
>where should we start? Dungeons and Dragons looks neat, but a bit
>complex.

There are a lot of free RPG rules sets on the web, some of which are
pretty incomplete, but many are useable and it's cheap to try them. [1]
There are also some reasonably simple RPGs that are still on the market
without having gone d20. Any Chaosium (www.chaosium.com) game would be a
good beginner game I think -- Call of Cthulu is the best known, but
Stormbringer is still in print, if you want sword & sorcery. (There's
some d20 versions of some Chaosium stuff, but I can't comment on that.)
They've also published a number of other games over the years using the
same basic system, including Elfquest and Ringworld RPGs. A shop that
carries games is perhaps the best place to look for a cheap, playable
with a single book, reasonably rules-light game. [2] If they have
adventure modules for the game you can use to help you get rolling, so
much the better.

However, since you're still in school, there's a good chance you could
find some other gamers who have experience, either with a game you could
join or interested in starting up a new one and helping the novices
along a bit. In that case, rely on the fact that the Gamemaster is more
important than the rules set and try whatever system they like. [3] Even
if you go on your own, remember not to sweat the rules too much; they're
just there to help the game function. If you're all having fun, you're
doing it right.

>Does anybody know of a sort of DnD board game? Same rules and
>mechanics, but not really requiring a DM?

Find a shop that carries a lot of games (and, again, there are some good
old games you can only hope to find used) and find something in your
price range that looks interesting. It might not even be something
D&Dish. Check reviews first if you're uncertain. Don't get started on
CCGs unless you have money to burn.

[1] And you can get guidance for some of the most popular. However,
there's some good stuff, like FUDGE, which is definitely not beginner
oriented.

[2] Or in a good shop, you can get someone to help you find a system you
might like, but chances are most places will try to steer you to d20
without really thinking.

[3] So long as they don't turn out to be crazy LARPers who like to place
in unsafe locations.

--
R. Dan Henry = danhenry@inreach.com

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On Wed, 14 Sep 2005 03:29:17 GMT, <edward@lore.net> wrote:

>I really wish Crawl would interrupt armor maneuvers when you get hit.

Haven't checked that yet, but the 4.1.2 alpha version has interruptible
eating and butchering. I've had a partly butchered corpse and a partly
eaten food item (I think a ration).

--
R. Dan Henry = danhenry@inreach.com

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster wrote:
> On 2005-09-14, SZDev - Slash <java.koder@gmail.com> wrote:
> >
> > Da-Breegster wrote:
> [snip]
> >> Does anybody know of a sort of DnD board game? Same rules and
> >> mechanics, but not really requiring a DM? Something easy for people who
> >> know and enjoy roguelikes.
> >
> > I dont have a clue, perhaps 'ADOM: The RPG'? xD
> >
> That's not a bad idea. I recently started playing adom a lot, and it'd
> be fun. I might design a simple board game RPG thing for people who're
> used to roguelikes, but not DnD and similar RPGs.

Why not contribute to the RPG that Mr. Biskup started doing some time
ago? it is available at the website...

> >>
> >> Anyway, I'll try and put up a page for my Perl roguelike sometime this
> >> weekend and release 0.0.3. Good luck to everybody else!
> >
> > Thanks,
> >
> > --
> > Slash
> > [http://peltkore.net/~szdev
> >

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

At Wed, 14 Sep 2005 13:41:44 -0700,
R Dan Henry wrote:

> On Wed, 14 Sep 2005 03:29:17 GMT, <edward@lore.net> wrote:
>
>>I really wish Crawl would interrupt armor maneuvers when you get hit.
>
> Haven't checked that yet, but the 4.1.2 alpha version has interruptible
> eating and butchering. I've had a partly butchered corpse and a partly
> eaten food item (I think a ration).

I just had a vision

d) Leather Armor (partly worn)
e) Full Plate Mail (partly worn)


--
Radomir `The Sheep' Dopieralski @**@_
(==) 3 Yawn?
. . . ..v.vVvVVvVvv.v.. .

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-09-13, Radomir 'The Sheep' Dopieralski <thesheep@sheep.prv.pl> wrote:
> At Tue, 13 Sep 2005 21:24:09 GMT,
> Da-Breegster wrote:
>
[snip]
> Don't let your UI change your game mechanics. It should be the other way
> around.
>
Quite correct. I have been falling into that trap. Maybe having two
interfaces will force me to use the abstraction I've set up for myself.
Either way, things will be kept simple for now; I can add in complexity
later without too much trouble.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-09-14, <edward@lore.net> <edward@lore.net> wrote:
> Da-Breegster <dabreegster@gmail.com> wrote:
>> Hey. Sorry for not keeping the other topics I started alive (3D ASCII
>
> There's no obligation on anyone to keep topics alive.
>
Excellent, I'll probably forget this one after a while. Or just give up
trying to wrestle with my newsserver and lack of knowledge about slrn.

[snip]
> ############
> # OFFTOPIC #
> ############
>
>> I introduced them to him. Are others fortunate enough to have
>> role-playing buddies in reality?
>
> My dedication to roleplaying waned after I left school. I'd be
> interested in getting back into it, but it takes a lot of time and
> dedication, and when everyone went off to uni and got jobs and had
> different schedules, organizing to get everyone together became a lot
> of effort. Too many days of having to play two characters because
> someone couldn't make it.
>
I'm not even in high school yet, though it's mostly like I am.
Disregarding that, time isn't a problem for me right now.
>> If we were interested in role-playing,
>> where should we start?
>
> www.sjgames.com/gurps/lite/
>
> GURPS Lite is free and quite neat. Has plenty of room for expansion if
> you want to buy hundreds of books... or just create your own extensions.
>
>
>
Looks good, I'll check it out.
>> Dungeons and Dragons looks neat, but a bit
>> complex. Does anybody know of a sort of DnD board game? Same rules and
>> mechanics, but not really requiring a DM? Something easy for people who
>> know and enjoy roguelikes.
>
> It depends on where you live, but if lack of GM is a problem, you may be
> able to find one through a local games/hobby shop if there is one.
> Alternatively there are groups who play over the 'net using a variety of
> chat programs, though it doesn't have quite the same social enjoyment
> that way. Still a good way to get some experience, and you don't need to
> know many rules, only the GM does. In fact, one of the reasons I prefer
> to make my own roleplaying system is that it's often better if the
> players are somewhat ignorant of the underlying mechanics. Cuts the
> rules lawyers right out of the picture.
>
There used to be a comic shop that probably had that sort of stuff
before I was interested in it, but unfortunately, it was torn down to
make way for Yet Another Walmart. Evil monopoly.
>> Anyway, I'll try and put up a page for my Perl roguelike sometime this
>> weekend and release 0.0.3. Good luck to everybody else!
>
> Thankyou. Back to coding...
>

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-09-14, SZDev - Slash <java.koder@gmail.com> wrote:
>
> Da-Breegster wrote:
[snip]
>> Does anybody know of a sort of DnD board game? Same rules and
>> mechanics, but not really requiring a DM? Something easy for people who
>> know and enjoy roguelikes.
>
> I dont have a clue, perhaps 'ADOM: The RPG'? xD
>
That's not a bad idea. I recently started playing adom a lot, and it'd
be fun. I might design a simple board game RPG thing for people who're
used to roguelikes, but not DnD and similar RPGs.
>>
>> Anyway, I'll try and put up a page for my Perl roguelike sometime this
>> weekend and release 0.0.3. Good luck to everybody else!
>
> Thanks,
>
> --
> Slash
> [http://peltkore.net/~szdev
>

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster wrote:
> On 2005-09-14, <edward@lore.net> <edward@lore.net> wrote:
> > Da-Breegster <dabreegster@gmail.com> wrote:
SNIP
> I'm not even in high school yet, though it's mostly like I am.

Whats your age?

> Disregarding that, time isn't a problem for me right now.

Cool...

SNIP

--
Slash

 

[Edward]

Archived from groups: rec.games.roguelike.development (More info?)

R. Dan Henry <danhenry@inreach.com> wrote:
> Haven't checked that yet, but the 4.1.2 alpha version has interruptible

Dear me, I have been relying on dungeoncrawl.org for my Crawl news.
Thankyou for alerting me to the existence of this alpha!

--
--jude hungerford.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

In article <slrndiemlt.uo0.thesheep@atos.wmid.amu.edu.pl>, Radomir 'The
Sheep' Dopieralski <thesheep@ sheep.prv.pl> says...

> No matter how simple or complicated is your time system, you'll definitely
> need both actions that take turn (walking, fighting) and "actions" that doesn't
> (checking stats, reading manual, browsing inventory). So it's a "needed
> complexity". On the other hand, you don't have to prompt the player
> to choose all the items he wants to pick up. You could for example make
> only the first pickup action in a row take a turn -- so that subsequent
> pickups are "free".
>
> Don't let your UI change your game mechanics. It should be the other way
> around.

I don't agree with that. The UI is at least as important as the
mechanics - both are part of the game. If something is desirable for
mechanics, but no non-clumsy UI is available, the author must make a
judgement call as to how important it is.

But you know that, because in your 'pickup' example, the UI *is*
deciding the mechanics! Because multi-turn moves are clumsy in the UI,
the consistent mechanics of time taken to pick up an item are
abandoned.

On the other hand 'rest X moves, or until something happens' is a bit
UI-clumsy, but often too important to abandon. (However, one could try
offering just 'rest', 'nap' or 'sleep' options, that take up to 1, 10
or 100 turns respectively, and get rid of the numeric entries. This
might be good in a mouse and numeric keypad controlled roguelike -
press 5 to rest, or press the Sleep button and select a long or a short
sleep. Might even be a shift-click option on that one.)

- Gerry Quinn

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

At Thu, 15 Sep 2005 13:15:55 +0100,
Gerry Quinn wrote:

> In article <slrndiemlt.uo0.thesheep@atos.wmid.amu.edu.pl>, Radomir 'The
> Sheep' Dopieralski <thesheep@ sheep.prv.pl> says...

>> You could for example make
>> only the first pickup action in a row take a turn -- so that subsequent
>> pickups are "free".

>> Don't let your UI change your game mechanics. It should be the other way
>> around.

> I don't agree with that. The UI is at least as important as the
> mechanics - both are part of the game. If something is desirable for
> mechanics, but no non-clumsy UI is available, the author must make a
> judgement call as to how important it is.

> But you know that, because in your 'pickup' example, the UI *is*
> deciding the mechanics! Because multi-turn moves are clumsy in the UI,
> the consistent mechanics of time taken to pick up an item are
> abandoned.

Not exactly. I mean, yes, the game mechanics is changed, in the strict
sense. But the change is made so that the effect is the same, or at least
close to the same.

Maybe I should hame said 'game rules' not 'game mechanics'.
What Imean is that you should have a clear (as much as possible) picture
of how the game should be played, and *then* design your game mechanics,
and, overlapping with it, design your UI. Both mechanics and UI can change
each other and also change with time, but it should be always withing the
borders you set with your 'vision of the game'.

Sure, there migth be even very dramatic changes in the game mechanics,
when you notice that the rules you set don't promote the behavior you
want. But you should know at least what behavior you want.



--
Radomir `The Sheep' Dopieralski @**@_
(*+) 3 Sparkle
. . . ..v.vVvVVvVvv.v.. .

 

[Edward]

Archived from groups: rec.games.roguelike.development (More info?)

SZDev - Slash <java.koder@gmail.com> wrote:
>
> Da-Breegster wrote:
> SNIP
>> I'm not even in high school yet, though it's mostly like I am.
>
> Whats your age?

I certainly wish I'd had the programming skills to begin work on a
roguelike before I hit high school. Back then I was still learning BASIC
and trying (unsuccessfully) to make a clone of Starlane. I didn't make
it as far as my first bad dungeon generator until I was 15.

--
--jude hungerford.