not human bits should execute in thise microturns
until you reacg turn 300 then you need to read
i coded soem roguelike game loop which gave me
a lot of logical trouble
imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0
if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again
what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}
is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo
On 20.11.2024 16:56, fir wrote:
i coded soem roguelike game loop which gave me
a lot of logical trouble
imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0
if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again
what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is
While loops are no more problematic than any other standard
control structure with as simple an operational semantics.
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}
(I recall to have seem exactly such a code pattern (i.e. the
'if <', 'while <', 'if =') about 40 years ago in an university
exercise, so I suppose that structure is an effect of a valid
algorithm structure property. - But that just aside. It may
soothe you.)
What I really suggest - and sorry for not literally answering
your question - is to implement (for your roguelike) an event
queue where you schedule not only your human player's actions,
but also the monsters, and other timed events in the game. I'm
aware that this might mess up your plans but I think it will
pay to have a cleaner "simulation structure", also with better
decoupling properties.[*]
is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo
It looks not nice, indeed. But code structure follows demands.
And, at first glance, I see no better structural variant with
loops and conditionals.
Janis
[*] A friend of mine just recently implemented the code frame
for a roguelike and followed the suggestion of an event based
object-oriented implementation; it worked well, he told me.
Janis Papanagnou pisze:
On 20.11.2024 16:56, fir wrote:
i coded soem roguelike game loop which gave me
a lot of logical trouble
imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0
if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again
what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is
While loops are no more problematic than any other standard
control structure with as simple an operational semantics.
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}
(I recall to have seem exactly such a code pattern (i.e. the
'if <', 'while <', 'if =') about 40 years ago in an university
exercise, so I suppose that structure is an effect of a valid
algorithm structure property. - But that just aside. It may
soothe you.)
this solo looks weird imo
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
DispatchActions();
the fact that you need add a thing outside the while loop which is
logically part of this loop.. i eman game_time after that must be character[HUM].action_end and the DispatchActions(); need to be called
for that value too
this looks sorta unnatural and my game not worked correctly until i find
i must add that final DispatchActions();
it means imo that this while loop is here not natural and being not
natural it makes you probles when you need to debug (and even debug
sorta hard) why this logic dont work
also i must also add the previous if
it is if( game_time < character[HUM].action_end) {}
to not allow all this code to re-enter when it finally
reaches game_time == character[HUM].action_end
its all weird and unnatural..but is logically not easy to find better
way (though i not thinked on this too much only noticed this is kinda
weird imo, and i thing its baddly writen here)
What I really suggest - and sorry for not literally answering
your question - is to implement (for your roguelike) an event
queue where you schedule not only your human player's actions,
but also the monsters, and other timed events in the game. I'm
aware that this might mess up your plans but I think it will
pay to have a cleaner "simulation structure", also with better
decoupling properties.[*]
is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo
It looks not nice, indeed. But code structure follows demands.
And, at first glance, I see no better structural variant with
loops and conditionals.
Janis
[*] A friend of mine just recently implemented the code frame
for a roguelike and followed the suggestion of an event based
object-oriented implementation; it worked well, he told me.
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}
[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented implementation; it worked well, he told me.
On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.
The next step would be to use coroutines so the logic of a longer-running task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into multiple callbacks.
On 21.11.2024 00:53, Lawrence D'Oliveiro wrote:
On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.
The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.
Yes, indeed.
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
Janis
[*] It was the language who invented Object Orientation - quite
naturally a concept from the simulation perspective -, but they
neither invented nor used the term "OO"; probably because it was
much more than that what they provided.
Janis Papanagnou pisze:
On 21.11.2024 00:53, Lawrence D'Oliveiro wrote:well i code things myself - no queue just a fileds
On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented >>>> implementation; it worked well, he told me.
The next step would be to use coroutines so the logic of a
longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.
Yes, indeed.
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
Janis
[*] It was the language who invented Object Orientation - quite
naturally a concept from the simulation perspective -, but they
neither invented nor used the term "OO"; probably because it was
much more than that what they provided.
long action, action_start, action_end;
(where action is pseudoenum describing the action is
doin by bot in a span of action_start to action_end)
in simply if time raches action_end the action is finalized and new
action is set up.. the arguments to pass i will probably try to be none
i mean tch bot fields would store them)
i will se how it will be going - thsoe are game design decisions and its sometimes hard to really know what is best before really coding this..so experuiance will show
though im old and tired and i not quite devoted to coding
anyway..only sometimes i try something to kill some time
fir pisze:
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}
so the loop code in simplification look like
if( game_time < 300) //this is only to not alllow re-enter the loop if you reach turn 300
{
while(game_time < 300) //game time starts form 0
{
DispatchActions();
game_time++;
}
DispatchActions(); //this runs for turn 300
}
im not sure if there is no bug here as when i press space and 300
turns into 600 then the dispatch on turn 300 would be executed
second time (?) (though in present state of things it wouldnt spoil
probably the things as dispatch if called on turn 300 starters would
change the values and they woil not fiore twice
but it all show trubles in what should be 'simple' loop
there is a question qhat would be more logical (prone, suitable) here
for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably
better
more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too
i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is
some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code
On 21.11.2024 12:01, fir wrote:
there is a question qhat would be more logical (prone, suitable) here
for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably
better
more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too
i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is
some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code
My opinion on that...
For a roguelike, don't model it too detailed or too "realistic"; it
happens too often that you're getting lost in unnecessary complexity.
Keep it time-discrete (as you indicated above), define an integer of sufficient length, don't use numeric types with fractions, define a
sensible base unit (that conforms probably to your 1/200 unit).
The start of action is the primary point in time. With "elementary"
actions (place a hit, quaff, read, loot, etc.) it's not worth to
complicate things; just consider the actual environmental situation
of the dungeon installations or individuals that affect your action
in any way.
It is an issue when _long lasting actions_ (like learning spells,
eating, etc.) will get "interrupted". Here I suggest to inspect the
Nethack code (obviously being still the "standard" roguelike), or
have a look into GnollHack (which IMO may have a more sophisticated
way to handle such interrupts). - I've not looked into the code so
I cannot give you concrete information; it's just from observation.
Practically I'd have, for example, an eating character put into a
queue at the time when its eating is supposed to get finished. In
case another actor or event pops in to affect the player (or the [user-perceivable] environment) the player object will be taken
from the queue, its status (e.g. unfinished food consumption)
updated, and rescheduled. The actual activation-time for that may
be immediately (after) the triggering event source, or delayed
(e.g. after gotten hit by sleep or paralysis) to the time it is
required for the effect to wear off.
I think such event-queues on a time-scale makes things more easier
and more consistent to implement.
(I also think that using C for such a task is not the best choice.
C++ at least provides classes to keep things together. - But that
just aside, to not angering the audience too much.)
Janis
REACTIVATE this.player DELAY meal_time (food_item.nutrition)
well im somewhat experienced in writing roguelike (never make some
finished but i wrote them i dont know in sum maybe about 3-4 months day
bay dey
previously i used thsi simpler approach and the conclusion from
experiecne was i need something that stores the action..
bothering bots i dont see as a problem but it is just needed to eb able
to bother them - not for being unable for bother them... i just need a
lot of cases when i could combine warious states for good efects
spells in turn if casted just live on their own loop so they not block
a caster if are casted
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented model
on these. I find it amazing what Simula provided (in 1967!) to support
such things. Object orientation[*], coroutines, etc., all fit together, powerful, and in a neat syntactical form.
On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented model
on these. I find it amazing what Simula provided (in 1967!) to support
such things. Object orientation[*], coroutines, etc., all fit together,
powerful, and in a neat syntactical form.
Wirth did include coroutines in Modula-2. And a kind of object orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a control
transfer to another coroutine can happen at any routine call, each
coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that they have no stack, but they need less of it, since a control transfer to
another coroutine context can only happen at the point of an “await” construct, and these are only allowed in coroutine functions, which are declared “async”. I think Microsoft pioneered this in C♯, but it has since
been copied into JavaScript, Python and other languages.
Yes, Simula pioneered OO. But the concept has gone in different directions since then. For example, multiple inheritance, metaclasses and classes as objects -- all things that Python supports.
On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:
Actually, if you know Simula, coroutines are inherent part of that language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.
Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.
Yes, Simula pioneered OO. But the concept has gone in differentWhat I read seems to suggest that Smalltalk had bigger influence on
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.
On 21.11.2024 14:05, fir wrote:
well im somewhat experienced in writing roguelike (never make some
finished but i wrote them i dont know in sum maybe about 3-4 months day
bay dey
Yeah, I suspected so; that's why I initially wrote about my suggestion
that "this might mess up your plans".
previously i used thsi simpler approach and the conclusion from
experiecne was i need something that stores the action..
bothering bots i dont see as a problem but it is just needed to eb able
to bother them - not for being unable for bother them... i just need a
lot of cases when i could combine warious states for good efects
I was tempted to suggest, for the implementation details, to (also or
better) try a post in rec.games.roguelike.development but that group
appears to be dead.
spells in turn if casted just live on their own loop so they not block
a caster if are casted
I would have seen a spell-cast (as opposed to learning a spell) as a single-turn action, but that is of course a design decision.
Janis
On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.
Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a
control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.
By chance, few days ago I was writing a small GUI panel to present a
status from the hardware board we just finished building. In C#,
because despite me knowing C++ (at least "old" C++) 10 times better
than I know C#, building simple GUI in C# still takes me less time and
the result tends to look better. It was the first time I was doing UDP
in .Net and going through docs I encountered UdpClient.ReceiveAsync
method. Got excited thinking that's exactly what I need to wait for
response from my board while still keeping GUI responsive. But it was
not obvious what exactly this async/await business is about.
Read several articles, including one quite long. https://devblogs.microsoft.com/dotnet/how-async-await-really-works
More I read, less I understood how it helps me and what's the point.
In particular, handling timeout scenario looked especially ugly.
5-10 hours of reading were 5-12 hours wasted most unproductively.
At the end, just did it good old way by ThreadPool.QueueUserWorkItem()
with everything done synchronously by separate thread. Took me, may be,
two hours, including wrapping my head around Control.BeginInvoke and Control.Invoke.
So much for innovations.
Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.
What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.
Michael S pisze:
On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.
Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a
control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.
By chance, few days ago I was writing a small GUI panel to present a
status from the hardware board we just finished building. In C#,
because despite me knowing C++ (at least "old" C++) 10 times better
than I know C#, building simple GUI in C# still takes me less time and
the result tends to look better. It was the first time I was doing UDP
in .Net and going through docs I encountered UdpClient.ReceiveAsync
method. Got excited thinking that's exactly what I need to wait for
response from my board while still keeping GUI responsive. But it was
not obvious what exactly this async/await business is about.
Read several articles, including one quite long.
https://devblogs.microsoft.com/dotnet/how-async-await-really-works
More I read, less I understood how it helps me and what's the point.
In particular, handling timeout scenario looked especially ugly.
5-10 hours of reading were 5-12 hours wasted most unproductively.
At the end, just did it good old way by ThreadPool.QueueUserWorkItem()
with everything done synchronously by separate thread. Took me, may be,
two hours, including wrapping my head around Control.BeginInvoke and
Control.Invoke.
So much for innovations.
if yopu pity for 5-10 hours being unproductive tell you boss something
is wrong with him.. maybe start be pity after reading for 2 weeks or
month (where you more soob be bored by this reading) but not 10 hours
such time presure kills work.. its a fact ime the more slow you code the more faster you code and the more faster you code the more slow you code
Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.
What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.
On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.
The next step would be to use coroutines so the logic of a longer-running task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into multiple callbacks.
Lawrence D'Oliveiro pisze:
On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:i dont know to much on coroutines (what i knew i forgot as even my
[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.
The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.
memory this year is terribly bad) or simule bot from some other
reasoning i know thet "call queue" is veru good thing
possibly it may be better or at least equal in thiat coroutines or
what was in simula
in basic call queue it gioes klike this afai
for(int i=0; i<all; i++)
add_queue foo(i);
foo() are storred in queue so then can be run i pseudo parralel
mode at some point
add_queue stores function adress and argument on stack like queue
here in rogualike it would use this time variable also
DoAction(int i)
{
if(character[i].action_end > current_time) return;
// do nothing until time comes
// time has come do something
character[i],action_end += 300;
add_queue DoAction(i); //put yourself on queue
}
StartUp()
{
for(int i=0; i<all; i++) add_queue DoAction(i);
}
// in some code
run_queue // queue may add soem alelemnts but also executed things are taken out of queue
i guess it should be something like that
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 120:12:12 |
| Calls: | 12,958 |
| Files: | 186,574 |
| Messages: | 3,265,650 |