Preloading events - ( EventManger)

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Preloading events - ( EventManger)

      Hi guys,

      Yep, another event manager question, two (2) of them in fact:

      Many games/demos load settings from some type of config file for such
      things as windows settings, sound settings, etc. for default settings, but
      would there be any reason to load "pre events" for the event manager?

      Second, would there be a reason to tie a Quake like console to
      the event manager? My thinking is that if you connect a console to the
      event manager, one could send commands to those 'thingys' (subsystems)
      listening to change their behavior. (?)

      I'm not asking how one would go about doing this, but I am asking
      for a discussion on this idea. Thoughts, comments, proposals, pros, cons.

      Sabrina - Draconian Noob
    • RE: Preloading events - ( EventManger)

      I think a console should be just another actor. I mean that it shouldn't bypass any particular system or directly connect to any particular system. I would make a console as an omnipotent actor that's able to send any message to an event queue. I think this would be easier than hard coding it into the message system.

      That's my opinion.
      .Code
      push you ; haha!
    • A scripting system would be very valuable if you were to add a console - enter script commands directly into the VM. If you have script commands that trigger events, then you could simply fire it off from the console. Even better would be to put the mouse in some sort of select mode so you could pick an entity and have that entity be the target of your script commands (where appropriate) - allowing you to cause objects to trigger events by picking them and using the appropriate script event command.

      As for pre-loading events, I'm not sure exactly what you're getting at. If you're going to use a data-driven setup for adding new events to the system then I would assume you'd need some sort of external file with the event types listed or something - and you'd have to use this list to initialize your event system. Or if you're looking to fire certain events before the game engine technically starts up (perhaps to fire a "Menu_State" event to start the GUI) then maybe some sort of light scripting system is what you're after. Game Scripting Mastery is a fairly good intro to coding your own scripting system.

      How's that for a rambling and incoherent post?!?

      Richard
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • I like both ideas.

      Preloading events sounds like it would be as simple as having a startup script that is able to make event calls.

      ...and if you implement scripting support, then you are one step away from being able to type actual script commands into a console during runtime.

      Yeshhhh... both are excellent choices.
    • RE: Preloading events - ( EventManger)

      Hi guys,

      Here's the scoop. I wrote an XML parser that will load settings from an XML file. I have a shader class loading in shading code from an XML file that can be compiled. I also have a windows class that will load in pre-defined settings, for example position, resolution, etc. If I want to have a class to load in some settings from an XML file, all I have to do is inherit the XML class and overload a function. When I started writing the event manager I started to wonder what would be the purpose of loading pre-defined settings (for the event manager class it would be called 'pre-defined events') from an XML file. (I guess I have to make a very clear distinction between 'events' and 'settings'. )


      As far as Quake like console, My thinking is that if I have a console, I could send commands to the event manager which in turn would send those commands to the appropriate sub-systems. The author (MrMike) has his event manager sending messages that dictate behavior, for example movement. I'm thinking one could expand the manager not only to dictate behavior, but also to dictate the aesthetics for a game or demo for example materials, lighting, etc. Something like "SetColor(...) is not a behavior event, and therefore would it be appropriate for the event manager ("Can I really justify SetColor(...) as an event?"). Of course I COULD get away with it and do it anyway, but would there be more of an approprate solution? Maybe write a "Blah Manager" to handle settings of this type?

      Long winded I know, sorry.

      Follow up question: What is the difference (pros/cons) of a 'data-driven' game/demo apposed to a 'state machine' (is there even such a thing in games?)



      S.
    • Oh man.... don't get me started on data-driven design....

      Okay, check this out. We're developing two games right now; Barbie & Rat Race. Get this, they use the exact same EXE file. There isn't one line of game-specific C++ code at all. All of our game-specific stuff is in Lua & XML and can be changed very easily by level designers. Pretty much everything in the game that can be tweaked is controlled with XML files or Lua data files. Everything except keyboard controls for some reason... wasd is hardcoded..... it's okay to cry, I did.....

      As for your Quake-like console, we have something similar. It's not in-engine like Quake though. We spawn a seperate cmd window that redirects STDOUT to it. That way, you can call printf() and it'll display in this window.... VERY handy for debugging. Furthermore, the STDIN is redirected to the main Lua state. Remember all that game-specific stuff that's in Lua? That's right, we can change it all at run-time!! Why is Candy (yes, there's a character named Candy) running her walk animation next to the pole while not moving? Hmmm, a quick

      Source Code

      1. =uuCandy:DumpState()
      later and we see that she's trying to path to a character that's not in this world. Oops!

      Okay... end rant... But yeah, data-driven design is the only to go when dealing with a massive and volatile project like a game. Even if you're just writing a demo that you hope lands an interview at EA, you need to show them that you can create a data-driven architecture.

      One interesting fact I learned at GDC: The Sims 2 has almost no AI code in C++. It's all scripted.

      -Rez
    • RE: Preloading events - ( EventManger)

      Ok, loading events from a file is a dumb idea! I guess it makes no sence.

      Intresting stuff Rez. I've been reading that many games developed today are scripted based being driven by an engine. I was woundering if my XML scripts would be a good approch (I'm not sure if I can say 'script', seems to be more like an ini file). Sounds like I'm on the right road. I might add Lua sometime.

      Your Barbie is named "Candy"? :D I had a Barbie when I was young, her name was........Barbie.

      S.
    • I'm gonna snicker here - "loading events from a file" is usually referred to as "scripting." lol -- and it's an EXCELLENT idea.

      Using XML as your scripting "language" is a little odd, but why not? If you know how to work in XML, just update your parser to handle the tags and parameters and run with it (document well, as always).

      For event firing from a console you might want to have it default to working on the currently selected object where that makes sense - pick a NPC or light or whatever and have the command affect the picked object. Otherwise you have to remember names or handles and it could get messy....

      Adding Lua is best done early - retrofit is always a hassle. "Game Development in Lua" is very handy.
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."
    • RE: Preloading events - ( EventManger)

      No, we have a character named Candy. Our Barbie is called Barbie. Here's a screenshot of Barbie & Candy standing next to each other:
      bleachkitty.com/images/barbie/candy.jpg

      Interestingly enough, we actually use XML in some places like a scripting language. We have a complex action system where you call actions, pass parameters, and give them dependencies. This gives you a way to easily fire off events based on other events. It can get very complicated and needlessly verbose at times, but it works very well. Most actions are really just a series of other action calls. for example, we have one called GoToLocationPrimitive which tells an entity to go somewhere. In reality, this just calls a couple of other actions which set it's animation state and paths to the destination. Then off it goes, to bring joy and sunshine to the (x,y,z) location you gave it.

      Anyway, here's an example of our Action system:

      Source Code

      1. <ActionCall actionKind="barbiewritesindiary" name="play_barbiewritesindiary">
      2. </ActionCall>
      3. <ActionCall actionKind="GoToLocationPrimitive" name="BarbieGetsOutOfBed1">
      4. <AssignmentEntity name="actor" value="Barbie" />
      5. <AssignmentVector name="destLoc" value= "80:0:-50" />
      6. <AssignmentBool name="toTeleport" value="true" />
      7. <ActionCallDependency callName="play_barbiewritesindiary"/>
      8. </ActionCall>
      9. <ActionCall actionKind="LuaCmdPR" name="DisableCameraInterpolationsAtStart">
      10. <AssignmentString name="lua" value="GetGlobalCameraMgr():DoChaseCamInterpolation(false)"/>
      11. <ActionCallDependency callName="BarbieGetsOutOfBed1"/>
      12. </ActionCall>
      13. <ActionCall actionKind="FaceDirectionPR" name="RotateBarbieBedroom1" >
      14. <AssignmentEntity name="actor" value="Barbie"/>
      15. <AssignmentVector name="destEulerAngles" value="0:20:0"/>
      16. <AssignmentBool name="IsInstantaneous" value="true"/>
      17. <ActionCallDependency callName="DisableCameraInterpolationsAtStart"/>
      18. </ActionCall>
      19. <ActionCall actionKind="SetObjectiveStatePR" name="EnableBarbieObjective" >
      20. <AssignmentString name="ObjectiveName" value="win_game"/>
      21. <AssignmentString name="State" value="Active"/>
      22. <ActionCallDependency callName="play_barbiewritesindiary" />
      23. </ActionCall>
      Display All


      This chunk plays the intro scene, then gets Barbie out of bed, faces her towards the closet, and sets the objective. The <ActionCall> tags are function calls. The <AssignmentXXX> tags are parameters. The <ActionCallDependency> tags set it up a call hierarchy so that certain actions only fire when others have completed.

      -Rez
    • See? There's the beauty of small parsers - you can do amazing things with 'em. Since the XML parser is already there make it work for its bread.

      You could as easily use the XML files to store your event types so they're not hard-coded anywhere. Then your event system loads up the event types at runtime - super flexible.

      Hmm - I'm gonna steal all of these great ideas you guys keep dropping....
      "Your job is not to die for your country. Your job is to make some other poor sod die for his."

    • Hmm - I'm gonna steal all of these great ideas you guys keep dropping....

      lol... I have to credit the authors book for jump starting my brain. :P


      Thanks for the sniplet Rez, thats what I had in mind. I did'nt know how to ask the next question without having to write an essay (with an abstract of course), but I think you nailed it for me.

      S.
    • Originally posted by Larrik
      That's improper XML, btw. You shouldn't be using attributes to store data (they are for metadata).

      Game programmers doing something improper?? Never! Seriously though, I didn't know that. I have no idea what the logic was behind choosing this scheme. It was made by people considerably more knowledgeble than I. ;)

      Thanks for the sniplet Rez, thats what I had in mind. I did'nt know how to ask the next question without having to write an essay (with an abstract of course), but I think you nailed it for me.

      No prob. :)

      -Rez