GameCore: An exercise in design

Game Play & Game Design
#21

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 :slight_smile:

#22

[quote]I smell the smell of an API being designed without a problem to solve.
[/quote]
Um. I thought that was fairly clear? (in as far as middleware can ever have particular problems to solve…)

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).

#23

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 :slight_smile:

#24

[quote]There is only one true goal here, and that’s writing a game,
Cas :slight_smile:
[/quote]
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.

#25

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 :frowning:

Cas :slight_smile:

#26

That’s cause we all suck at the art :).

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.

#27

Art is as easy to find as programmers :slight_smile: 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 :slight_smile:

#28

[quote]Art is as easy to find as programmers :slight_smile:
[/quote]
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

#29

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

#30

[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
[/quote]
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

#31

[quote]I am probably the most anti-engine person you’ll ever find in the world.

So many engines, so few games.
[/quote]
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 ;)) - 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”.

#32

[quote]I merely say “leave the engines to the pro’s”.
[/quote]
Why can’t we be the pros :slight_smile: ?

#33

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.

#34

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. :smiley:

#35

New diagram up here.

Current javadocs are here.

#36

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.

#37

AABB trees :).

#38

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.

#39

[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.
[/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.

#40

[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. :smiley:
[/quote]
Ahh, now this makes sense, I didn’t realize your were the planetation guy…