Re: developing a kind of radar?

2015-01-13 Thread AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector


  


Re: developing a kind of radar?

The wait function in BGT was pretty novel for me, on the grounds that Id been working primarily in Java and _javascript_ up to that point._javascript_ first. This was way before HTML5. Timers with callbacks were the only way to go.Javas Thread.sleep() is just not worth it. AWT and Swing were the only real options when I started, and they are designed to be event-based rather than loop-based. Throwing a Thread.sleep in there is always painful, even if theres an actual use for it.Someone *could* write a similar event-based architecture for BGT, assuming anyone would use it.

URL: http://forum.audiogames.net/viewtopic.php?pid=200981#p200981




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-12 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

You can use a constant value, and this is likely to be fine.Or (Python again, sorry):while True:
 start =time.time()
 do_stuff()
 end = time.time()
 took = end-start
 if took = wanted_time:
  continue #we dont wait because we took too long.
 time.sleep(wanted_time-took) #wait for the remaining part of this tick.To figure out wanted_time, do 1 over the desired frame rate. I suggest just passing the frame rate to all your functions, at least for now. Some advanced games will compute the actual frame rate in realtime and make up for slowing down by actually modifying the physics formulas, but you are very unlikely to need this functionality. At least in my opinion. If you do, we can talk.

URL: http://forum.audiogames.net/viewtopic.php?pid=200839#p200839




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-12 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Hi, so, I think Im, incredibly close to figuring this out. I do have one question, though. Whats the best way to regulate the time that passes between ticks? I know thats the entire point of the thing, and I looked at that frame clock for bgt, but Im not sure how much it helped me. On the bright side, I can practically feel my brain repeatedly shattering and rebuilding itself, better than before! So thats always a pluss.Thanks for all the great suggestions!

URL: http://forum.audiogames.net/viewtopic.php?pid=200834#p200834




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-12 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

Good. We really, really need more people around here advocating for it. It is frustrating to keep watching people use blocking architectures and throwing all their stuff right in the main loop. Sighted people solved these problems for us like 20 years ago, and yet here we are with what few tutorials exist advocating not using any of these techniques. I kind of understand why, but still-everyone who is actually serious about it hits this point, and thats a ton of code that has to be ported or thrown out.

URL: http://forum.audiogames.net/viewtopic.php?pid=200855#p200855




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-12 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Thanks! I think I am beginning to understand this.

URL: http://forum.audiogames.net/viewtopic.php?pid=200853#p200853




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-10 Thread AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector


  


Re: developing a kind of radar?

The difference betweenwhile(true) {functions(5);wait(5);}andwhile(true) {functions(fps.delay);fps.tick();}Is minor when youre doing something simple. You can go ahead and do it the first way, if you want. The only real advantage to the second way is that it attempts to keep frame duration consistent.But in the end, your game objects will need to know how much time has passed since they last did anything. It can be done with timers, but the more it looks like what Camlorn described, the easier it will be in the long run.

URL: http://forum.audiogames.net/viewtopic.php?pid=200559#p200559




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-09 Thread AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector


  


Re: developing a kind of radar?

For BGT, I wrote a clock class that takes care of the timer shenanigans. All you need to specify is how much time should pass between the start of each frame.A main function might look like this:void main() {
clock fps(50); // The constructor takes frames/second as a parameter and determines the delay for you.
double frametime=fps.delay; // This is the target time that passes between frames.

show_game_window(Game with frames);
while(true) {
keycheck();
step_game(frametime);
update_other_things(frametime);

fps.tick();
}
}In practice, Id include a method (I usually call it step) that takes the amount of time that passes as a parameter, for each class that needs time-sensitive updating. Enemies and radars both fall into this category. You could use an interface for tickable objects, but I dont see the need for it most of the time.

URL: http://forum.audiogames.net/viewtopic.php?pid=200476#p200476




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-09 Thread AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector


  


Re: developing a kind of radar?

For BGT, I wrote a clock class that takes care of the timer shenanigans. All you need to specify is how much time should pass between the start of each frame.A main function might look like this:void main() {
clock fps(50); // The constructor takes frames/second as a parameter and determines the delay for you.
double frametime=fps.delay; // This is the target time that passes between frames.

show_game_window(Game with frames);
while(true) {
keycheck();
step_game(frametime);
update_other_things(frametime);

fps.tick();
}
}In practice, Id include a method (I usually call it step) that takes the amount of time that passes as a parameter, for each class that needs time-sensitive updating. Enemies and radars both fall into this category. You could use an interface for tickable objects, but I dont see the need for it most of the time.If the step/tick/update method is the part thats throwing you off, odds are that most classes like this will include this sort of thing:class TimedObject {
double counter=0.0;

/* [...] */

void step(double dt) {
counter-=dt;
if(counter=0.0) {
// Times up: do whatever needs doing. Update your radar angle, for example.

// Reset the counter. As an example:
this.counter=1000.0; // Assuming milliseconds.
}
}
}

URL: http://forum.audiogames.net/viewtopic.php?pid=200476#p200476




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-09 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Hi, I think what confuses me is how ticking is different from something like, while (true) {keyboard_function();wait(5);}and how to know when to call something like tick, and how calling tick methods will effect the game. Im really sorry Im having so much trouble grasping this concept. Its something that Ive never heard about before, but I see how it could be very useful so I really want to understand it.

URL: http://forum.audiogames.net/viewtopic.php?pid=200481#p200481




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-09 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Hi, Im still struggling with the concept of frames and ticks. I understand how it can be helpful, and I understand your code in post 2, Im just not sure how for example, youd tell the game how to tick everything properly, given a certain amount of time per tick. Ive looked at some game programming tutorials, but have been having a bit of trouble finding a good one. Do you have and recommendations?Thanks very much!

URL: http://forum.audiogames.net/viewtopic.php?pid=200464#p200464




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-09 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

Im afraid not. Ive gone through like 2 computers since I last looked at it. im now at the point where I can tell you all about DSP, and you probably do not want to see the articles I read at this point (Ive been having huge mileage with an entity component system, but thats not going to help you now in any way).What is the difficulty?If its just getting things to tick, see my code in post 7. Youll need to use polymorphism. Make a ticker base class with a single method called tick, have everything inherit from that, and then create all the different subsystems of your game somewhere and put them in a list that your main loop knows about. Not much more to it than that. You move the chunk of code that checks for input into one of the ticker subclasses, and tell it about all the other things it might want to touch--i.e. turning the radar off and on means youre passing it a radar instance.It can be made much cleaner than this implies, but Im trying not to go too far ahead.

URL: http://forum.audiogames.net/viewtopic.php?pid=200468#p200468




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-09 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

This might be a little much for one post. I apologize in advance if it is.To keep using my invented word...Keyboard_function is a ticker. Whatever keyboard_function normally does goes inside one. In reality, you usually end up breaking keyboard handling up too, but thats neither here nor there for the time being (but well get there if this conversation goes on much longer).Your radar is a ticker.your physics system is a ticker: add velocity to all objects with one, tell the objects theyve collided by calling a.collides_with(b) and b.collides_with(a), etc.Enemy AI is a ticker. When it ticks, it figures out what the enemy should be doing, typically (for the stuff being discussed here) setting the velocity on the enemy. Enemy AI is the first example of a ticker which may not always finish the tick, as pathfinding can be expensive. I normally put enemy AI in the enemy class and register it as a ticker-
 -this allows different enemies to have different AI.Here comes the key insight: none of these are special. Each of these is a game object just like all others. What you do is register them in a list; weve covered that before. But if you make sure that all the objects in your game can access that list, you can suddenly have one-of-a-kind enemies and stuff. The main loop doesnt care what needs ticking, it just cares that its got the tick method on the objects therein. So everything can inherit from the base class if you want, and everything can have its own little slice of time whether or not its used. Its like being able to run bunches of really simple games instead of one big one: everything has its own main loop, its just that they all start with a function declaration instead of a while statement. Since youre not using threads (which make learning this particular pattern look like
  cake), you can be assured that only one ticker is touching the world at a time--no need for typically complex concurrency stuff that gives basically all programmers headaches.Instead of waiting, you use what is called a finite state machine. The idea is that you might be in one of various states right now, so you set a flag and use if statements. This is the equivalent to blocking without actually blocking. Your radar is the simplest example. It can be either on (in which case it is doing something) or off (in which case it is not). Youve almost certainly built finite state machines already; whether or not you know the words, its a super common game design pattern. To apply limiters and lag, you replace them with more counters, i.e. the gun cant fire again for .3 seconds.Global variables are bad. The particular pattern I like to use to deal with the fact that tickers need to know about each other and other stuf
 f outside themselves is called dependency injection (I mention this so you can have a googlable term). If your radar needs to know about whatever object is responsible for holding the level map, it either gets a reference to it passed in via the constructor or looks it up on your game object--also passed in via the constructor. I personally prefer the latter. When I set something up like this, I usually put the main loop of the game inside of a game class and then hang things like the current level off of it. Tickers can then access important game state through that avenue.To make two tickers representing important things know about each other, I suggest either the use of instance variables on your game object or the use of a dictionary (BGT might call this something else) mapping names of important things to tickers. The latter is probably a bit advanced for what youre doing, but youll probably end up using something like it down the 
 road (mapping things to unique ids like that is great for saving to disk and doing network stuff). But in truth, I find that tickers dont often talk to each other. They can, and theres nothing wrong with it-just, if you do this right, each ticker is completely responsible for exactly one concern, and there isnt that much mixing.To make tickers know about important things like the level map being changed, I typically add more empty methods to the base class that act as events: level_changed, for example. And then you just call them all without caring if anything happens (which can be faster than most naive lookup schemes and avoids a lot of bugs--do not worry about performance).You might try looking into XNA tutorials. I dont have specific ones as its been like 6 years at this point. XNA is big on this particular pattern, aimed at new game programmers, and was pretty popular for a few years. Its also 
 the earliest thing I can recall seeing this pattern in, and you can find some other useful stuff floating around that talks about saner ways to handle input (even if they dont seem so at first).And finally, some motivation for you, as i know the proceeding is possibly like hitting your brain with a brick. If you want a game which is both complex

Re: developing a kind of radar?

2015-01-08 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Hi, thanks for the suggestions. I dont completely understand, but Ill definitely take a look at some game programming tutorials for information. Im now trying to figure out though, how I can update the angles the radar is scanning based on actions the player performs? For example, turning or walking. Ive now got scanning working, but it doesnt update properly based on the angle of the player. If they walk forwards it still works fine, but Im not sure how I can make the radar continue through ts sweep as the player turns, without just restarting it frm the left.Thanks again for all the help. Im the kind of person who mostly learns by trying stuff and seeing what works and such, which is why some of these questios of mine are still pretty basic compared to others.

URL: http://forum.audiogames.net/viewtopic.php?pid=200245#p200245




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-08 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Hi, thanks for the suggestions. I dont completely understand, but Ill definitely take a look at some game programming tutorials for information. Im now trying to figure out though, how I can update the angles the radar is scanning based on actions the player performs? For example, turning or walking. Ive now got scanning working, but it doesnt update properly based on the angle of the player. If they walk forwards it still works fine, but Im not sure how I can make the radar continue through its sweep as the player turns, without just restarting it from the left.Thanks again for all the help. Im the kind of person who mostly learns by trying stuff and seeing what works and such, which is why some of these questios of mine are still pretty basic compared to others.

URL: http://forum.audiogames.net/viewtopic.php?pid=200245#p200245




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-08 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

You dont need timers. You do exactly what I did in post 2. And then:while playing:
 for i in all_tickers:
  i.tick(frame_rate)
 wait(however long)Determining the time to wait can take just a little math if you want it to catch up, but this is your entire main loop and you certainly dont need to do so. You do not put anything else here. Anything else belongs in one of the all_ticker objects.If BGT timers allow you to tick them instead of using your system clock, you can do that. But Id suggest just using the counter and/or writing your own base class that uses the counter and having your tickers inherit from it. The former certainly isnt hard, and the latter is like 20 lines tops. What I am saying about timers is that you can turn that loop into a function that reschedules itself instead of waiting if you want, not that you should use them for everything.You can stick keyboard here. You can stick enemy AI here. You can and should stick everything in what Im calling a ticker--its the simplest non-blo
 cking architecture and its how even the big sighted games do this kind of thing.And on that note, Im now wondering how close BGT would be to being able to implement something like Twisted in it.

URL: http://forum.audiogames.net/viewtopic.php?pid=200209#p200209




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-08 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

Youre going to have to record the angle on the radar as an offset, say that it always goes from -45 to 45 for example. You then compute the actual angle by adding this offset. Because of the pattern I am describing--that you have tickers as a class--you can just store the offset on the class and re-read the players facing direction and position every tick. You dont want to build the whole sweep ahead of time, you want to build it as you go across.

URL: http://forum.audiogames.net/viewtopic.php?pid=200252#p200252




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-07 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


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. Youll 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 youre 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. Im obviously leaving out a lot, but this should get it across. Id make all the tick methods take the delta and just ignore it if you dont 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.

URL: http://forum.audiogames.net/viewtopic.php?pid=200057#p200057




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-07 Thread AudioGames . net Forum — Developers room : Ian Reed via Audiogames-reflector


  


Re: developing a kind of radar?

+1 for post 2.An important architectural concept for game programming, and explained very well.

URL: http://forum.audiogames.net/viewtopic.php?pid=200106#p200106




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-07 Thread AudioGames . net Forum — Developers room : Dranelement via Audiogames-reflector


  


Re: developing a kind of radar?

Ah, okay. So just make a timer then, and call the update method every time its elapsed? Or I could put the timercheck in the update function itself. I do that with a couple of my classes, doing that for this didnt even cross my mind, hough. Thanks very much! 

URL: http://forum.audiogames.net/viewtopic.php?pid=200150#p200150




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-07 Thread AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector


  


Re: developing a kind of radar?

Camlorn is right on track. The loop-and-wait thing works if you never have multiple things happening simultaneously (or as close to simultaneously as possible, anyway).In BGT, you _could_ use timers to keep track of these various independent mechanisms, but can you imagine how messy that could get if you pause the game for any reason? (Sengoku Jidai was programmed rather carelessly, to be honest, because I wanted to make something and my more careful projects were stalling. And, lo and behold, I keep finding an instance where I failed to pause a timer for one of the numerous game-stopping menus, and people wind up starving for it. And Sengoku Jidai doesnt have anywhere near as many timers as it could, because I still tried to do it more frame-and-counter-style, menus aside.)

URL: http://forum.audiogames.net/viewtopic.php?pid=200088#p200088




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector

Re: developing a kind of radar?

2015-01-07 Thread AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector


  


Re: developing a kind of radar?

You can use timers in any language. There is only one good reason to even consider it: a fully online game that never pauses. But probably not even then. Being able to work with time in strange ways is an amazingly helpful thing.That said, you can replace the wait with a timer that calls the global tick method which in turn calls tick on everything else; this may be advantageous. You still have a main loop, it just doenst look like one. Im not sure what facilities the BGT timer provides, but when I write my own (I do on occasion) I make them such that theyll catch up if a tick takes too long because of CPU or similar.

URL: http://forum.audiogames.net/viewtopic.php?pid=200095#p200095




___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector