Re: developing a kind of radar?

This is where the typical architecture breaks down and is also why I advocate reading sighted game programming tutorials.  You'll need to architect your whole game to not use wait statements save in exactly one place.  The typical approach to this is to define objects with a tick method, put them in a list, and call all the tick methods every time through your main loop.  The only thing allowed to call wait, ever, is the last line of your main loop.  This allows the radar to have a function called at a known time.  You then replace the for loop and wait statements for the radar with two counters: the first being the angle at which you're currently pointing and the second being how many ticks to wait before incrementing again.  Something like this (Python):

def tick(delta):
 if wait_counter != 0:
  wait_counter -= 1
  return
 radar_angle+= 1
 if radar_angle >= max_radar_angle:
  radar_angle = min_radar_angle
 sound=compute_radar_sound(player_position, radar_angle)
 sound.play()
 wait_count = 5 #or whatever.\

The delta parameter is the time between ticks.  This is useful because you can replace the integer count of ticks with a floating point count in seconds and then subtract delta instead.  This lets this particular bit of code be completely independent of how fast the game ticks.  I'm obviously leaving out a lot, but this should get it across.  I'd make all the tick methods take the delta and just ignore it if you don't need it: the end result is that you have the information and your new main loop can be like 10 lines.
You can abstract the waiting functionality into a base class, as well as other behaviors.  Using this architecture, you can implement bases that call a function every x seconds, call a list of functions at given times in a loop, etc. Perhaps most useful is a base class that calls a function exactly once after a given wait, but which has a method on it to schedule the next on e.  This particular configuration can represent almost anything: a call rescheduling yourself is the above logic, a call rescheduling the next function in a list of events is a timeline, and a call which conditionally schedules the next function is a pretty easy to read finite state machine.



_______________________________________________
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ian Reed via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector

Reply via email to