Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  GameCore: An exercise in design  (Read 7851 times)
0 Members and 1 Guest are viewing this topic.
Offline zparticle

Senior Devvie




Thick As A Brick


« Posted 2004-03-10 14:57:58 »

As a kind of mental exercise I have started working out a design for a 2D game engine. I have choosen three primary goals for the design:

1> The system must be able to have the rendering code layer completely replaced without any code changes. For instance I would like to be able to have LWJGL, JOGL and Java2D versions of the rendering layer.

2> The code (related to the library) for a game should be very easy to read and understand.

3> A java programmer just starting to get into game programming should be able to get something on screen in under an hour.

The current class diagram, such as it is, can be viewed here.

I'm interested in hearing opinions/advice on the design. A little background should help (an example program provided below):

GameCore - This abstract class is the center of the world for the library. Each rendering layer will have to implement a version of this class. Some methods common to every rendering layer are provided. The factory methods for creating different kinds of game objects will be filled in by each implementation. This object hides the specifics for any given type of rendering, OGL, Java2D.

GameCoreProgram - This interface must be implemented by the game.

DisplayObject - All classes that place something on the screen must subclass this class.

RenderList - A list of DisplayObject objects. Can use Z sorting to order the items drawn to the screen.

RenderSet - A list of RenderList objects.  RenderSets are the only objects allowed to be passed into the GameCore rendering method.

org.gamecore.event.* - The classes in this package are used to avoid the AWT/Rendering thread issues. The rendering layer GameCore implementation must handle all events and place them into the GameCoreEventQueue. The programmer then deals with the events inside of the rendering thread.

Currently I'm having trouble trying to figure out how to abstract out the canvas that will be drawn to. Any help here would greatly appretiated.

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #1 - Posted 2004-03-10 14:59:28 »

An evolving example of a game for GameCore.

The code is too hard to read with this forum software so here it is all pretty, thanks Dennis.

http://showsrc.com/$http://www.scottshaver2000.com/temp/MyGame.java

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2004-03-10 15:26:55 »

Not very helpful, but...this is a worthwhile exercise Smiley. There was some interest a while back in trying something like this collaboritvely, and several aborted early attempts (personally I ran out of time). I think it would have helped if something had happened from the GTG about publishing developer articles (on JGO), because there was a lot of interest in developing it as an example throughout articles.

If/when you get around to the networking side, I'll help there (just too busy at the moment to do anything myself).

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2004-03-10 15:29:29 »

PS this kind of architectural design is very hard to get right (hence I ran out of time trying to make a good one before). I suggest implementing two dissimilar simple games ASAP, and that will tell you pretty quickly where your design is iffy.

I had a scan over the class diagram, and it looked OK, although I think you'd need to modularise some more - e.g. your classes look a bit too monolithic at the moment.

malloc will be first against the wall when the revolution comes...
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #4 - Posted 2004-03-10 18:21:09 »

Okay thanks for the notes, there is an updated class diagram up. I have taken your advice and I'm writing a couple programs to see how things would work. The first one is a simple Tic-Tac-Toe game. The code is here.

http://showsrc.com/$http://www.scottshaver2000.com/temp/GCTicTacToe.java

I'm finding I like this process, write the program how you want it to be and then see how that affects the library design.

Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #5 - Posted 2004-03-10 21:19:40 »

Quote

2> The code (related to the library) for a game should be very easy to read and understand.

3> A java programmer just starting to get into game programming should be able to get something on screen in under an hour.


Bravo for the effort + good intentions but I think 2) would be lost on a "new" game programmer and 3) is irrelavent; the real difficulty/complexity in gamedev is not gfx (imho).

But when/if you get to scripting/networking I will be very interested in your ideas.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-03-11 06:44:08 »

Quote


Bravo for the effort + good intentions but I think 2) would be lost on a "new" game programmer and 3) is irrelavent; the real difficulty/complexity in gamedev is not gfx (imho).


I think I kind of see what you're getting at, but...these are things that entirely control (prevent):
 - RAD: trying out new game ideas; giving people like me who are v.busy a chance to write new games in their v. limited free time; etc
 - Tutorials: basis for teaching people how to program java games, assuming they are naive java programmers (a lot of people who come here have done v. little java programming before...)

And, of course, given how many games people start but never finish, anything that reduces the hurdles and saves time is a massive boon.

malloc will be first against the wall when the revolution comes...
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #7 - Posted 2004-03-11 14:17:02 »

Okay a few questions:

1> The DisplayObject class is the root for all things that can go on the screen. I'm thinking that I'll create a set of objects such as ImageSprite, AnimImageSprite, TextSprite, etc. These would simply be data containers with concrete implementations having a render() method that accepts an Interface type of GameCoreRenderer. The render layer has to implement the GameCoreRenderer interface so that it knows how to render the different types of sprites.  The other option is to make the sprite classes abstract and the render layer would have to implement the render() method for each sprite type. What do you think?

2> For networking would it make since to have a thread that handles ripping the data from the network card and turns that into a set of events that end up in the GameCoreEventQueue?

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2004-03-11 14:41:51 »

Suggestion off the top of my head.

The last java 2D game I did I found that having an object for every thing in the game was a PITA.

Instead I sliced it aspect-ly, and I got a lot of mileage out of having:
 -  "Object positioner"s
 -  "Object mover"s
 -  "Object collider"s
 -  "object renderer"s
 - ...etc
where one instance of each of those was responsible for a class (not the keyword!) of objects. E.g. one positioner for all "alien_type_1" that are on the screen, a separate positioner for all "alien_type_2" that are on the screen, etc.

One advantage was that getting classes (not java) of objects to behave as a group was a doddle. Which especially applies to getting aliens to collaborate, etc.

The main advantage was that it was easy to "share" different aspects of game-entities - like their movement, their solidity, whether they were lethal, etc. e.g. I had a collider implementation that ignored collisions, another that caused things to bounce away, and another that caused things to be removed from the game.

So I could easily experiment with making different objects destructible/indestructible/etc. RAD was easy.

It's just a pity that I screwed up the mouse input layer, which was so ugh! that it wasn't worth continuing with Sad.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2004-03-11 14:53:18 »

Quote
Okay a few questions:

1> The DisplayObject class is the root for all things that can go on the screen. I'm thinking that I'll create a set of objects such as ImageSprite, AnimImageSprite, TextSprite, etc. These would simply be data containers with concrete implementations having a render() method that accepts an Interface type of GameCoreRenderer. The render layer has to implement the GameCoreRenderer interface so that it knows how to render the different types of sprites.  The other option is to make the sprite classes abstract and the render layer would have to implement the render() method for each sprite type. What do you think?


Not entirely sure what you're asking, but...AFAICS you're asking whether to have each of your XXXSprite classes implement a method that either:
 a. renders to a surface
 b. provides an image of known format (RGBA etc)
?

In which case, it doesn't really matter, it's the same amount of code either way - with a) you have all the sprites extend a base class that contains basic rendering capability, with b) you have them extend a base class that negotiates with the GCR to get the img format. a) seems slightly cleaner?

Quote

2> For networking would it make sense to have a thread that handles ripping the data from the network card and turns that into a set of events that end up in the GameCoreEventQueue?


Well, with NIO that's unnecessary...you can just allocate X ms to the networking at a point of your chosing. Although:

Quote

This method does not offer real-time guarantees: It schedules the timeout as if by invoking the Object.wait(long) method.


...so you might prefer just to poll periodically. Either way, it'll be non-blocking, so there's no need for an extra thread.

You *are* going to only use NIO, aren't you? Smiley. Not worth the effort of old I/O, IMHO.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #10 - Posted 2004-03-11 15:15:28 »

As for the rendering of different sprite types I was trying to figure if it would be better to have the rendering layers have to implement a single interface, GameCoreRenderer such as:

1  
2  
3  
4  
5  
6  
public interface GameCoreRenderer
{
   public renderImageSprite(ImageSprite);
   public renderAnimImageSprite(AnimImageSprite);
   etc...
}


This would mean that I could write all of the looping through the GameCoreRenderSets and the layer only has to know about the rendering specifics. I would have a method in the GameCore class that returns an instance of the GCR provided by the rendering layer and then call it on each object in the GCRenderSets based on the object types with instanceof. This means you can create the sprite objects using new ImageSprite() instead of a factory method. This is how I'm thinking of going.

or they have to implement a different class for each of the different types of sprites. This would mean then that the GameCore object would become a factory for all of the different sprite types and the render layer would have to provide an method implmentation for each of the type like:

1  
2  
public ImageSprite newImageSprite();
etc...



On the networking side basically what I'm asking is should ALL things in the engine be driven by the event queue?

I would use NIO, of course. So when data arrived from a client it would be packaged into a GameCoreNetworkEvent and added to the event queue for handling in the the handleEvent() method. I see that I wouldn't need another thread for this it would simply happen behind the scenes automatically in the render loop.


Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-03-11 15:32:21 »

Quote
On the networking side basically what I'm asking is should ALL things in the engine be driven by the event queue?


Well, you'd need to add several more event types AFAICS if you did that. So long as you had one for "game-logic-event" that should handle them all I think.

I mean, how do you handle network-sourced commands that are nothing to do with player-inserted commands, such as:

- "change_level_to 3" (e.g. quake servers that rotate the level every X minutes)
- "new_player_appears_at 405,340"
- "chat_message_from_player wibble Hello there!"

etc.

malloc will be first against the wall when the revolution comes...
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #12 - Posted 2004-03-11 18:25:33 »

Okay there is a new class diagram up (check the link above). The way it is right now only one class has to be created to completely replace the rendering layer. The GameCoreRenerer interface has to have an implementation.

I'm still not quite sure how to abstract out the drawing canvas so there might be an additional class to implement as well.

Question: Currently I have the handleEvents method in the GameCoreProgram interface. You have to implement it and the system assumes you will handle the events in that method. I was thinking about calling it automatically. Would it be better to have the system call it or let the programmer place it were they want it. For instance at the beginning of a frame render or after.

Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2004-03-12 08:38:39 »

I've pretty much sorted out this framework design in Alien Flux hehe Smiley I'm not so sure that it's a particularly worthwhile gesture trying to allow the "rendering layer" to get abstracted out as you end up with bloat, complexity, and satisfying no-one. Technically my sprite engine can be replaced by a drop in Java2D renderer but then its performance characteristics would be radically different. Likewise the realtime GUI interface could be done in Java2D but it would run at 5fps. Just my 2p.

The sprite engine in SPGL might well be worth you taking a look at as it does, well, everything pretty much that you need it to, and you can replace the rendering part with something else if you really really want. What it doesn't have is nice IDE tools to make it easier to actually get sprite resources into it.

Cas Smiley

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #14 - Posted 2004-03-15 16:29:22 »

Another new class diagram up (check the link in the first post).

The way it is right now:

Two classes have to be created to completely replace the rendering layer.

1> GameCoreRenderer interface has to have an implementation.
2> CanavsPeer interface has to have an implementation.

Two classes have to be created to completely replace the audio layer.

1>  GameCoreSoundStore abstract class has to have an implementation.
2> GameCoreSound interface has to have at least one implementation.


Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2004-03-15 17:33:48 »

WTF is a "MeterSprite" Huh Smiley

malloc will be first against the wall when the revolution comes...
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #16 - Posted 2004-03-15 17:39:13 »

The idea was to give a class that could display a health meter like sheild strength or something. Just throwing out ideas Tongue.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #17 - Posted 2004-03-15 17:39:31 »

Typo: you have in GameCoreRenderer:
renderAnimeImageSprite

But the argument is:
GameCoreAnimImageSprite

Also, could you possibly do a slightly larger (+20% ?) version of the image? It's really hard to read at 1400x1050 Sad

What do you plan to do about the game-logic network-sourced events? Will they be part of the gameCoreEventQ, or handled separately? (I suspectly separately is easier to keep clean, because it will likely evolve separately from the others, BUT it makes lock-step games and replays much harder because you can't simply "record every event in the GameCoreEventQ and play them back in order at correct times").

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2004-03-15 17:43:49 »

Quote
The idea was to give a class that could display a health meter like sheild strength or something. Just throwing out ideas Tongue.


I can't see the animSprite API in the diagram, but your anim sprite should handle that OK. A meter is just an anim sprite that uses a different algorithm to decide which frame to display next Smiley.

Shouldn't require ANY extra code - assuming your anim sprites have their frame updated independently of the render call? (i.e. internally they keep track of whether they need to advance the frame; they do -of course- need the renderer to tell them the delta since the last render call).

malloc will be first against the wall when the revolution comes...
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #19 - Posted 2004-03-15 18:00:52 »

Quote
Typo: you have in GameCoreRenderer:


Fixed the typo, thanks.

Quote
Also, could you possibly do a slightly larger (+20% ?) version of the image? It's really hard to read at 1400x1050


Poseidon doesn't let me set the image size, unfortunately. It just creates one that everything will fit in apparently at a hard coded zoom level.

If you have a UML tool that will import XMI I can export the diagram in that format and put it on the web. Also I could post up the code that is getting generated. I have filled in a number of the methods and have been trying to make sure the javadocs are there as well.

Quote
What do you plan to do about the game-logic network-sourced events? Will they be part of the gameCoreEventQ, or handled separately?


I'm still thinking I want to have the network events in some sort of queue. It might not be in the same queue as the other events though. For scripting demos it would be really nice to place them in the same queue.

Quote
A meter is just an anim sprite


Good thinking on the meter sprite I'll kill it.

Quote
assuming your anim sprites have their frame updated independently of the render call


I'm thinking of adding a specific interface to the sprite types that need frame updates. Something like:

1  
2  
3  
4  
5  
6  
7  
public interface Updatable
{
public void setUpdateInterval(long interval);
public long getUpdateInterval(long interval);
public void shouldUpdate(long interval);
public void update();
}

Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2004-03-15 20:33:23 »

I smell the smell of an API being designed without a problem to solve. How about starting with a specific problem and designing the bare minimum of classes to solve it? Like:

Need to do 2D games in Java
So I need entities that can wiz around in some game loop
And they need to interact when they hit each other
And each entity might be represented by one or more independent animations
So we've got entities controlling a number of sprites, and each sprite can be controlled by some animation
It would be nice if animations could feed back to entities so that graphics can affect entity state, and then we could simply make animations take care of themselves
It would be nice if sprites could be used for absolutely all rendering such as text and HUDs, so we need to be able to layer sprites
This means we can draw the entire screen with one call which renders all the sprites

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #21 - Posted 2004-03-15 20:55:15 »

Quote
I smell the smell of an API being designed without a problem to solve.


Um. I thought *that* was fairly clear? (in as far as middleware can *ever* have particular problems to solve...)

Quote

It would be nice if animations could feed back to entities so that graphics can affect entity state, and then we could simply make animations take care of themselves


The present class diagram allows that effortlessly, no? (assuming anim sprites are allowed to pick their own moment to advance to the next frame) without hard-coding it in any way. Using a rendering layer as the FSM to control game logic is also something I find quite disturbing despite the obvious advantages (including code simplicity).

malloc will be first against the wall when the revolution comes...
Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2004-03-16 06:21:46 »

There is only one true goal here, and that's writing a game, not designing the software for the next interplanetary space vehicle's nav systems! So I'd say that it absolutely has to be kept as utterly simple as possible to solve 95% of the situations it finds itself in, and then if anyone needs to make it do something far out and crazy - edit it!

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #23 - Posted 2004-03-16 07:28:20 »

Quote
There is only one true goal here, and that's writing a game,
Cas Smiley


No: "a design for a 2D game engine" (first line of first post).

Come on! You know an engine and a game are completely different things with completely different requirements. You are suggesting things that would fundamentally undermine the ability of this thing to be an engine.

malloc will be first against the wall when the revolution comes...
Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2004-03-16 08:12:12 »

I am probably the most anti-engine person you'll ever find in the world.

So many engines, so few games.

I get really saddened by all the effort put into engines when no-one ever writes any games Sad

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #25 - Posted 2004-03-16 10:14:04 »

That's cause we all suck at the art Smiley.

Polishing off a decent game means graphics and sound effects, music etc.  We're all a bunch of nerds here... our talent is in the logic.

Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2004-03-16 10:40:38 »

Art is as easy to find as programmers Smiley You write the game, and I'll get you an artist.

Case study: I've set Orangy Tang to work on a game in LWJGL using SPGL. He's done absolutely tons of stuff, and it's playing fantastically and feeling like it'll be a really fun game - and the only graphics he's got are coloured rectangles. When it's all done I'll get Chaz to do the sprites, and then I'll plonk the regcode/purchase stuff in, and we'll sell it.

So don't write an engine without a game! Write a game, and extract the engine later!

Cas Smiley

Offline Seekely

Senior Newbie




I am java


« Reply #27 - Posted 2004-03-16 14:00:23 »

Quote
Art is as easy to find as programmers Smiley


Hm....either I disagree with that, or I know the wrong people.  Whenever I find an artist willing to work for free on one of my projects, I consider it a god send

http://www.untoldevils.com  
An RPG like every other, except this one is made by me
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #28 - Posted 2004-03-16 14:06:13 »

No offense Cas but:

1> this is what I find fun to do
2> it is my choice to do it
3> If you don't want to help out, or give usefull suggestions, fine
4> please don't try to sabotage other projects, if you don't like them, go write a game
4> this may never turn into anything "real" I simply wanted to see how hard it would be to DESIGN it

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #29 - Posted 2004-03-16 14:49:14 »

Quote
No offense Cas but:

4> this may never turn into anything "real" I simply wanted to see how hard it would be to DESIGN it


Actually I'm intending to really do something with it.

I want a good design / framework for a game without getting something that wants to be an all-singing all-dancing "engine". I want something like the "game-loop design" that many have provided on these forums but generalized across the whole game. It has to be vague enough that I don't feel it's pushing me down any design choices I wouldn't definitely have made myself anyway.

I didn't have time to complete such a design myself, but if I've got such a design already, I probably have enough time to make a game on top of it.

For me:

  • the coding is easy
  • I'll be coding in such small stints that it's very easy to lose sight of the bigger picture...
  • ...so I have especial need of a good overall design. This, incidentally, is why Crystals stagnated: I made just two or three mistakes in the high-level design that now would take more time in a single session to undo and fix than I ever have available these days.
  • I spend up to 100 hours a week working on systems architecture and I'd rather shoot myself in the head than have to do it when I get home...but contributing to someone else's arch is much easier

malloc will be first against the wall when the revolution comes...
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (29 views)
2014-11-22 12:13:56

xFryIx (71 views)
2014-11-13 12:34:49

digdugdiggy (50 views)
2014-11-12 21:11:50

digdugdiggy (44 views)
2014-11-12 21:10:15

digdugdiggy (38 views)
2014-11-12 21:09:33

kovacsa (62 views)
2014-11-07 19:57:14

TehJavaDev (67 views)
2014-11-03 22:04:50

BurntPizza (65 views)
2014-11-03 18:54:52

moogie (80 views)
2014-11-03 06:22:04

CopyableCougar4 (80 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org 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‑gaming.org
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!