Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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 7960 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #30 - Posted 2004-03-16 14:53:25 »

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

So many engines, so few games.


And I work in MMOG's, where every tom, dick and harry game-developer with little or no networking experience reckons he can write a new cluster-based MMOG engine.

But that hasn't reduced my appreciation for the value of a good architecture (seeing as my day-job is largely system-architecture work that's rather a good thing Wink) - which, let's be honest, is a lot less than an engine (and much cheaper to produce and maintain!).

I merely say "leave the engines to the pro's".

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #31 - Posted 2004-03-16 15:33:47 »

Quote
I merely say "leave the engines to the pro's".


Why can't we be the pros Smiley ?

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #32 - Posted 2004-03-16 16:05:48 »

Quote

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.

Not trying to be overly critical, but I think this is a waste of time. If you're trying to use OpenGL then LWJGL gives you all the same platforms supported and with better compatability. And if you suddenly plug in a J2D renderer into code that uses OpenGL-like features (vertex colours, image warping, neat blending modes) you're not going to get acceptable results.

And if you've got a really good reason to use J2D then you're much better writing code specifically for it to make sure you actually get good performance. Pick one API and stick with it, you're only getting unnessisary complexity for no real advantage.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
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 #33 - Posted 2004-03-16 16:24:31 »

I have no doubt you are right, but this is an excercise in design for me.

I could easily just hack something together and have another mess like I did with the Planetation code. Having portions of the system be replacable forces me to abstract things, thus making the design more difficult and the entire thing more fun. Cheesy

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #34 - Posted 2004-03-16 17:14:46 »

New diagram up here.

Current javadocs are here.

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #35 - Posted 2004-03-16 18:40:23 »

A good portion of the collision system is now in the class diagram.

GameCoreCollisionArea - Defines a rectangle of a arbitraty size located relative to a sprite. May have an application assigned ID. If a sprite is set to allow collisions and it doesn't have a defined set of collision areas then its position and size are used in the collision detection.

GameCoreCollisionPair - Defines two GameCoreCollisionArea objects that were detected to have collided with eachother.

GameCoreCollisionEvent - An event generated when a collision between two sprites has been detected. The two sprites are available in the event as well as the list of GameCoreCollisionPair objects related to the collision.

All sprites can now be set to detect collisions or not. Each sprite may have 0 or more GameCoreCollisionArea objects assigned to it. You could cover your sprites with a grid of collision areas and thus be able to detect from which direction the collision occured. This should also be good for boss type sprites where you want to be able to blow off the left wing or something.

Wondering how to implement the collision scanning. should there be collision groups (much like the GAGE library) and we detect collsions between groups?

Also new sprite types have been added and the members / methods filled out.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #36 - Posted 2004-03-16 19:20:43 »

Quote

Wondering how to implement the collision scanning. should there be collision groups (much like the GAGE library) and we detect collsions between groups?


AABB trees Smiley.

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

Senior Devvie




Thick As A Brick


« Reply #37 - Posted 2004-03-16 19:39:15 »

Okay looked into that, looks interesting. I was talking at a bit hgher level though. Specifically, how do we tell the system what objects should be tested against what other objects in as simple and effcient way as possible. Possibly giving up some efficiency to make it easier on the programmer.

So if if have 500 sprites and 250 of those are particle effects from explosions I don't want to test those for collisions. Of the remaining 250, 100 are my bullets and 70 are objects they can collide with. How do we tell the system to detect collisions between the 100 bullets and the 70 enemies.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #38 - Posted 2004-03-16 20:05:20 »

Quote
So if if have 500 sprites and 250 of those are particle effects from explosions I don't want to test those for collisions. Of the remaining 250, 100 are my bullets and 70 are objects they can collide with. How do we tell the system to detect collisions between the 100 bullets and the 70 enemies.

I'd suggest that you leave this to the application to manage, nothing you could come up with is going to be flexible enough to cover all the demands (and even simple game types have widely different demands).

Just stick some kind of spatial tree in (which is really easy to abstract out so you can switch them depending on scene) and let objects query for intersections etc. (much like Java3D allows you to 'pick' with various shapes. Easier, simpler, more flexible.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #39 - Posted 2004-03-16 20:24:38 »

Quote
I have no doubt you are right, but this is an excercise in design for me.

I could easily just hack something together and have another mess like I did with the Planetation code. Having portions of the system be replacable forces me to abstract things, thus making the design more difficult and the entire thing more fun. Cheesy


Ahh, now this makes sense, I didn't realize your were the planetation guy...
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 #40 - Posted 2004-03-16 23:55:34 »

I'm feeling a bit out-of-sorts so take this post with a truck load of salt...

So what is it exactly about someone wanting to improve his brain that some of you find so confusing?  Huh

I'm mean this isn't hurting you in anyway, or am I about to end the world by trying to think through something? At the worst my head might explode and leave a stain on the wall.  Cool At best I end up with something that I like to use and God forbid someone else might find it useful.  Tongue

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #41 - Posted 2004-03-16 23:57:14 »

Quote

I'd suggest that you leave this to the application to manage, nothing you could come up with is going to be flexible enough to cover all the demands (and even simple game types have widely different demands).

Just stick some kind of spatial tree in (which is really easy to abstract out so you can switch them depending on scene) and let objects query for intersections etc. (much like Java3D allows you to 'pick' with various shapes. Easier, simpler, more flexible.


Not a bad idea, thanks for the suggestion.

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2004-03-17 07:14:51 »

Here's another 2p! Now you have 4p:

I suggest you divorce the sprites from the entities. An entity can be represented by multiple sprites or even be a compound entity made up of smaller entities (boss gidrah). A particle is not an entity as it cannot collide with other particles or entities, and it can be represented by a single sprite.

An entity can have a simple fixed radius or it can have several radii which it can determine from the animation frames of the sprites it is composed from.

Cas Smiley

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #43 - Posted 2004-03-17 14:53:58 »

Quote

I suggest you divorce the sprites from the entities. An entity can be represented by multiple sprites or even be a compound entity made up of smaller entities (boss gidrah). A particle is not an entity as it cannot collide with other particles or entities, and it can be represented by a single sprite.


Could you elaborate a bit more an this idea. I see the advantage of being able to tie several objects into a compound object so you could do things like "move this hole group of sprites together". Like a boss that has ten sprites in his tail moving back and forth across the screen. What I'm having difficultly understnading is: what is an entity? Since it has to represented on screen via a spirte why and how would separating them make a difference? I'm interested in the idea, I just don't understand it.

Quote

An entity can have a simple fixed radius or it can have several radii which it can determine from the animation frames of the sprites it is composed from.


So this would be for collision detection of somesort I assume, or did you have some other idea in mind?

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #44 - Posted 2004-03-17 16:05:17 »

Quote
What I'm having difficultly understnading is: what is an entity? Since it has to represented on screen via a spirte why and how would separating them make a difference?

Typically an entity is a single 'thing' which you interact with in a game. So for something like space invaders you'd have a different entity type for each alien, probably one for the player and maybe even for the projectiles as well. Something like a boss monster is only a single entity, but its visual display is composed out of multiple sprites.

Side note: everything in S-Type is an entity. That includes the player, enemies, projectiles, lights, level geometry, switches and triggers. They all get treated in the same generic way. Although after trying this I can say that this does complicate things somewhat, it does mean you can write lots of general purpose code and use it all over the place.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #45 - Posted 2004-03-17 17:04:21 »

Quote

Typically an entity is a single 'thing' which you interact with in a game. So for something like space invaders you'd have a different entity type for each alien, probably one for the player and maybe even for the projectiles as well. Something like a boss monster is only a single entity, but its visual display is composed out of multiple sprites.


Hmm, maybe I'm starting to get it. So really an entity is a totally custom thing per program. There really wouldn't be any good way for me to create a default set of entity classes. You might, for instance, use them to implement automatic behavior like bouncing back and forth across the screen or something.

So what I have is fine and if a person needs these entities they can simply write them and assign my sprite types to them internal to the entity classes.  

I think I will add a "super-sprite" to the diagram that is a collection of GameCoreSprite objects that all function relative to the super-spirtes location.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #46 - Posted 2004-03-17 17:35:04 »

Quote

So really an entity is a totally custom thing per program. There really wouldn't be any good way for me to create a default set of entity classes.
...
So what I have is fine and if a person needs these entities they can simply write them and assign my sprite types to them internal to the entity classes.  


This is what I'd been assuming would happen all along Grin.

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

Senior Devvie




Thick As A Brick


« Reply #47 - Posted 2004-03-19 13:40:50 »

I'm considering getting rid of the GameCoreRenderer interface which currently would be called from the rendering loop to put the sprites on the screen.

The replacement for it would be the ability to assign a rendering class directly to each sprite and this would get called instead. So there would be a default set of rendering classes that don't anything special, they just get the sprites on the screen. If you had special rendering needs for a particular class (not the keyword) of sprites you could write it yourself and plug it in.

RenderOpaque, RenderAlphaPercent, RenderRedChannel, etc...

Basically I have acheived my original goal of understanding how to abstract out the rendering layer. This has shown me that I will loose a lot of functionality from OGL because the code has to pick a single way in which to render something. I still don't want to have to be tied to a specific implementation like JOGL, J2D and LWJGL.

So my modified goal is to have a framework that allows the programmer to choose to be tied to a rendering implementation. We would end up with a "generic" framework for the programmer to start with and then they can add to it in order to the advantages of a specific rendering library.

I'm also considering removing the ability to change the coordinate system and the programmer just has to know what system the renderer they choose uses.

What do you all think of this new approach?

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #48 - Posted 2004-04-02 12:17:48 »

Cas,

did you use quads to render the sprites in AF or just the GL drawPixels method? I'm wonder what would be a better approach. It seems simple to do the drawPixels thing bu then you can't rotate and other things.

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #49 - Posted 2004-04-03 12:49:59 »

Quads. Much quicker and more flexible.

Cas Smiley

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.

rwatson462 (35 views)
2014-12-15 09:26:44

Mr.CodeIt (26 views)
2014-12-14 19:50:38

BurntPizza (53 views)
2014-12-09 22:41:13

BurntPizza (86 views)
2014-12-08 04:46:31

JscottyBieshaar (48 views)
2014-12-05 12:39:02

SHC (63 views)
2014-12-03 16:27:13

CopyableCougar4 (65 views)
2014-11-29 21:32:03

toopeicgaming1999 (126 views)
2014-11-26 15:22:04

toopeicgaming1999 (117 views)
2014-11-26 15:20:36

toopeicgaming1999 (34 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!