Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Some engine design musings  (Read 2202 times)
0 Members and 1 Guest are viewing this topic.
Offline aldacron

JGO Coder

Medals: 20
Exp: 19 years

Java games rock!

« Posted 2004-01-15 16:34:55 »

I recently posted about my new project, Simplicity. On the project home page I spout off my views regarding how I feel about generic game engines, and how I want to keep Simplicity tailored to a limited subset of games. I think I'm in the middle of a paradigm shift.

Having expanded the original project goal of supporting only LWJGL to now include support for JOGL (and thereby JOAL and JInput), I sat down to knock up some interfaces. My initial plan was to keep scene management and the rest as a core part of the engine, without support for pluggability. The biggest reason for this is that I have a non-traditional method of scene management on paper, tailored for the specific types of games I had in mind. I couldn't imagine how I could develop interfaces generic enough to support a different implementation.

Eventually, the JOGL and LWJGL support became pluggable, rather than core components of the engine. This was to keep AWT/Swing dependencies out of the core for those who don't want or need it.  After some long thought and a couple of waste baskets full of wadded up designs, I'm now thinking that making the entire engine pluggable may not be such a bad idea.

My initial reasonings against generic engines still hold - I still don't want bloated code or performance hits just because the engine supports multiple game types. However, a completely pluggable system seems to give the best of both worlds. I believe it's possible to keep the core interfaces simple enough (read small) such that no excessive bloat occurs when implementing them. Meanwhile, it will still be possible to tailor each plugin to the specific type of game required. So in this sense, the engine becomes an engine framework (dare I say container?) rather than an engine.

Certain issues arise, such as what to do about functionality required by an implementation that is not supported by the interfaces? An example of this would be the need to fetch a GLCanvas/GLJPanel Component representation when building an editor. The answer is, deal with it specifically in the app. My initial idea for the JOGL render system plugin includes a method to do just that, even though it is not present in the interface. I figure if you need it, then you won't be using LWJGL anyway (at least until SWT support gets into LWJGL core).

On the one hand, implementing special methods beyond those provided by the interfaces would be considered breaking pluggability (or breaking the contract). But on the other, the goal is not so much to allow drop in replacement for all components as it is to allow the developer an easy means of customizing the engine to fit the needs of a particular game. As long as the specified interfaces are implemented, then the default plugins will be able to interact with any replacement.  

Anyway, the more I think about it the better it sounds. Restricting the engine to certain types of games limits the usefulness to the community. Being able to expand on this while still alowing a mechanism for game-specific optimizatrions can't be a bad thing. The hard part is coming up with some of the interfaces. The audio/renderer/input/resource stuff is easy. Scenes and entities are giving me fits. And regardless, there will be some things that will be forced on the user. For example, if I make all entities Controllable, so that they can be controlled by input, ai, or network messages without difference, then the interfaces will need to account for that .

Anyway, I've been at this for hours and I'm most likely rambling. But I'm looking for opinions of the usefulness of such a design.
Pages: [1]
  ignore  |  Print  

EgonOlsen (42 views)
2018-06-10 19:43:48

EgonOlsen (22 views)
2018-06-10 19:43:44

EgonOlsen (43 views)
2018-06-10 19:43:20

DesertCoockie (197 views)
2018-05-13 18:23:11

nelsongames (124 views)
2018-04-24 18:15:36

nelsongames (123 views)
2018-04-24 18:14:32

ivj94 (863 views)
2018-03-24 14:47:39

ivj94 (124 views)
2018-03-24 14:46:31

ivj94 (768 views)
2018-03-24 14:43:53

Solater (140 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!