2
\$\begingroup\$

Should I develop a basic messaging/event system for a generic game engine or should I leave it up to the individual case-by-case basis of the end-users to create systems specific to the game being developed?

This question raises some valid points: (I am currently using the per-frame function call system mentioned)

Per-frame-function-calls-versus-event-driven-messaging-in-game-design

\$\endgroup\$
4
  • \$\begingroup\$ What kind of game engine are you developing and why? (Not trying to dissuade you like I'm sure some people will suggest (use an existing engine!), just think it'll help the question) \$\endgroup\$
    – Jeff
    Commented Dec 1, 2012 at 1:50
  • \$\begingroup\$ @Jeff Extremely generic. Audio, Graphics, Input, Math, Physics, Timing and depending on this question, Messaging capabilities. The original intent was to wrap the Allegro 4.2 graphics library and fix some of its shortcomings and just grew from there. \$\endgroup\$
    – Casey
    Commented Dec 1, 2012 at 1:56
  • 2
    \$\begingroup\$ Yes. (Not much else to say on it. Not worth a full answer I feel since its not a question that necessarily fits the GDSE format.) \$\endgroup\$
    – Sean Middleditch
    Commented Dec 1, 2012 at 2:45
  • \$\begingroup\$ Agree with Sean, this is really just a personal decision for you. Since you can go either way, and there's no strong reasons either way. \$\endgroup\$
    – House
    Commented Dec 1, 2012 at 5:00

1 Answer 1

Reset to default
4
\$\begingroup\$

You need to ask yourself this question:

Will this messaging/events system be used by the engine? (including for the purposes of communicating to/from game code)

If so, then yes, you have to build it as part of the engine (since the engine needs to know about it).

But if you're intending for it to only be used within game code, then don't make it part of the engine; any such system which is unrelated to the engine should be designed by and for the game that's going to be using it.

Simple.

\$\endgroup\$
6
  • \$\begingroup\$ I'm not in agreement here. By that logic, the entire engine shouldn't exist - every last piece of the engine serves to implement a game. Given that just about every game can make use if messaging, and the lack of a messaging system in engines like Unity is one of the biggest usability problems with said engines, I'd lean toward providing "common services" like messaging that games can use. Especially as writing an efficient, flexible messaging system with UI-friendly metadata is non-trivial and hardly game-specific. \$\endgroup\$
    – Sean Middleditch
    Commented Dec 1, 2012 at 22:53
  • 2
    \$\begingroup\$ Look. An engine serves to connect game code to hardware. And often, to a data pipeline as well. A rendering system does that. A sound system does that. A file-handling system does that. A network system does that. A memory system does that. An event system? If it's not connected to anything in the rest of the engine, then all it does is connect game code to other game code. It's this weird disconnected system that's just sitting randomly in the middle of an unrelated library. It's sloppy library architecture. \$\endgroup\$
    – Trevor Powell
    Commented Dec 2, 2012 at 8:05
  • 1
    \$\begingroup\$ You seem to have a surprisingly narrow and arbitrary definition of what an engine is. Engines are usually not "a library", but rather a collection of libraries. Hardware abstraction is handled largely by the OS and development platform. Engines can include AI, GUI support, debugging features, and various other services, and their implementations thereof are the key differences between engines. What you're talking about is something like XNA, which is not generally called a game engine in its own right. An engine's job is to help game devs get quality work done efficiently, not to be pure. :) \$\endgroup\$
    – Sean Middleditch
    Commented Dec 2, 2012 at 9:41
  • 1
    \$\begingroup\$ @Sean Middleditch I've been a senior engine team programmer at three different major studios, and was lead developer and architect at one of them. My opinions are not 'arbitrary' or 'narrow', but come from many years of real-world industry experience. If you have a different opinion from mine, that's fine. But post it in your own answer. There's no need to get abusive in comments on mine. Thanks. \$\endgroup\$
    – Trevor Powell
    Commented Dec 2, 2012 at 11:55
  • 1
    \$\begingroup\$ @Sean Middleditch Again, please feel free to post your own answer. \$\endgroup\$
    – Trevor Powell
    Commented Dec 2, 2012 at 20:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .