Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #388992 > unrolled thread

logically weird loop

Back to article view | Back to comp.lang.c

Contents

  logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 16:56 +0100
    Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 17:09 +0100
    Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-20 17:34 +0100
      Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 18:18 +0100
        Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 18:30 +0100
          Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 18:38 +0100
            Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 12:12 +0100
      Re: logically weird loop Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-20 23:53 +0000
        Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-21 07:06 +0100
          Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 11:41 +0100
            Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 12:01 +0100
              Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-21 13:26 +0100
                Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 14:05 +0100
                  Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-21 21:45 +0100
                    Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:19 +0100
          Re: logically weird loop Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-22 00:04 +0000
            Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-22 06:09 +0100
            Re: logically weird loop Michael S <already5chosen@yahoo.com> - 2024-11-22 16:05 +0200
              Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:23 +0100
                Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:27 +0100
              Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 19:53 -0800
                Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 12:21 +0100
                  Re: logically weird loop David Brown <david.brown@hesbynett.no> - 2024-12-05 16:06 +0100
                    Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 17:14 +0100
          Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 17:07 -0800
            Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 12:41 +0100
              Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 10:18 -0800
                Re: logically weird loop Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-07 13:53 -0800
                  Re: logically weird loop Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 03:52 +0000
                  Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-18 18:43 -0800
        Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:48 +0100
          Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 19:14 +0100
            Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-24 11:20 +0100

Page 1 of 2  [1] 2  Next page →

#388992 — logically weird loop

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

[toc] | [next] | [standalone]

#388994

fir pisze:
> not human bits should execute in thise microturns
> until you reacg turn 300 then you need to read

*bots

im not sure if i not overcomplicate this rogualike base
as i diviede each action as a command like 'move' 'wait'
'cut tree' and mark the time in future where it will be ended
- then on the second part i finalize this action (like replace
the bot on map)

it makes things noticably more complex but when one character meets 
other character it can reaad in what state of 'doing' something
the first one is ant it gives possibility of better interactions

my older experiences should tell me it is needed though im not sure
as i dont touched roguelike koding ofr long years

[toc] | [prev] | [next] | [standalone]

#388996

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.

[toc] | [prev] | [next] | [standalone]

#388997

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.
> 

[toc] | [prev] | [next] | [standalone]

#388998

fir pisze:
> 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)
> 
> 

if someone has a trouble understandong that loop it may substitute
character[HUM].action_end by 300

the loop need to go thru all micro turns/tures from 0 to 300
inclusded and fire the bot 'starters' (where bts have timers on
warious random microturns to act and than put those starters
on some microturns in future)

then imaginee each pressing space turns that 300 up by another 300
and another portion of micro turns is fired/dispatched (im not sure if 
the word dispatch is fully proper here (weak english) but maybe)

> 
>> 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.
>>
> 

[toc] | [prev] | [next] | [standalone]

#388999

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

[toc] | [prev] | [next] | [standalone]

#389007

fir pisze:
> 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
> 

after considering that bug it seem that the game_time should always be 
increased after this dispatch to disallow making this dispatch twice co
i could maybe just

	 while(game_time <= character[HUM].action_end)
	 {
		 DispatchActions();
	 	 game_time++;
	 }

and on key handler

void ProcessKeyDown(int key)
{
	if(game_time>character[HUM].action_end )
	{
	if(key==VK_LEFT) AddAction(HUM, 'movl', rand2(300,300));
         }
}

this roughly seem to work so probbaly this is simply more proper though 
i must rethink it yet	


> but it all show trubles in what should be 'simple' loop

[toc] | [prev] | [next] | [standalone]

#389003

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.

[toc] | [prev] | [next] | [standalone]

#389004

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.

[toc] | [prev] | [next] | [standalone]

#389005

Janis Papanagnou pisze:
> 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.
> 
well i code things myself - no queue just a fileds

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

[toc] | [prev] | [next] | [standalone]

#389006

fir pisze:
> Janis Papanagnou pisze:
>> 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.
>>
> well i code things myself - no queue just a fileds
> 
> 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
> 
> 
> 

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

[toc] | [prev] | [next] | [standalone]

#389008

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)

[toc] | [prev] | [next] | [standalone]

#389010

Janis Papanagnou pisze:
> 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

[toc] | [prev] | [next] | [standalone]

#389017

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

[toc] | [prev] | [next] | [standalone]

#389030

Janis Papanagnou pisze:
> 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".
> 

in fact i coded roguelikes maybe more (maybe up to 6- months day bay day 
in sum... its not so little.. as yoiu then got some experience with that

now im fuking out of energy and my whole body makes pain (some health 
problems) s i dont even try to finish some but simply toy with some thoughts

>>
>> 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
> 

design is especially important as to program like rogualike..becouse the 
game is not "fluid" but lives on tiles and also time interactions need 
to be designed its maybe not primarely important if it is simpler 
scenario or more complex but the very important is the design to be 
"inherently coherent"

[toc] | [prev] | [next] | [standalone]

#389018

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.

[toc] | [prev] | [next] | [standalone]

#389020

On 22.11.2024 01:04, Lawrence D'Oliveiro 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.

Simula has also in objects own PCs (Program Counters) to enable each
object to be interrupted and resumed. Can't tell about Modula-2 and
Oberon, but I suppose they adopted quite some things from Simula, as
C++ and other languages adopted Simula concepts.

> 
> 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.

Not surprising that good concepts were adopted in other languages,
and expanded by own ideas. Rather it surprised me that some basic
IMO necessities were not; e.g. that C++ had no garbage collection
but Simula (and other languages) already had it long ago.

> 
> 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.

Of course evolution will influence development of future languages,
and they may deviate or may also take new directions. Individual
language design decisions were arguable, though; I recall disputes
concerning, e.g., multiple inheritance (which is not necessary but
significantly complicates an OO language) or that "everything must
be an object" to qualify as "real" OOL, and so on. I don't want to
start or continue these discussions here. Personally I found e.g.
C++'s multiple inheritance useful; that was a language I actually
used professionally. I also find it not very surprising if Python,
a quarter centenary after Simula, supports concepts (sensible or
not) that Simula didn't have. What I find impressive [in Simula]
is not only the new "OO" modeling concept but also how all their
software patterns fit together (the already mentioned coroutines,
or the prefix blocks; just for example to make clear what I mean).
As a pioneering language, as you rightly classify it, Simula had
no paragon for many things that it invented in an impressive way.

Janis

[toc] | [prev] | [next] | [standalone]

#389024

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.

[toc] | [prev] | [next] | [standalone]

#389031

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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#389032

fir pisze:
> 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
> 

i wrotee the half of my furia compiler i got now by a month - and i 
consider it fast, only becouse i was doing it slow with no 
pressure..with pressure i could do that 2 years probably ;c (honestly i 
dont know)

hovever the health problems are worst issue.. becouse now i totally dont 
feel like being on month so concentrated to write the second (and easier 
i think) part

>>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web