I lost the afternoon with OrientedBoundingBox collisions that don’t work for me :x. I also took a couple of screenshots of the sample projects for the game framework I’m working in:
I would be happy if someone wants to code the AI for the enemy tanks in the tank game. This project is in a very early stage, though…
Hopefully I will be able to share this some day :).
So it is a framework more than just a game? I see pics from 2 different games here… unless its a crazy 'transformer volleyball playing tanks' game.
What features are you trying to put in the framework… what will it be aimed for?
Cool. I love that tank game on the Wii 
I am glad you ask about it :D… I was actually creating this for my IndoorBattles project but I divided to separate everything that I will be reusing.
GGF is a services and configuration framework, and also aims to impose some structure on how to design your game. I'd say it aims to:
- Provide a common structure and simplify game development. This is the main purpose and in theory (and so far this is working pretty well), you only need to extend View States, Logic States and Loaders.
- Serve as a very quick start for new developments and help to make garage games more complete. Also provide ready to use game development aids (debugger view, screenshot view, Nymon's scene monitor integration, system reporting tools…).
- Main configuration is done in a configuration file. Here you can see your complete ViewStateand LogicState hierarchy, your loaders and loader chains, your settings and defaults… You can easily switch between components for a quick test, or add some introduction screens (or disable them during development ;))…
- Be non-intrusive. Allow the developers a complete control over the final look and feel. You still have to code your complete game (JME is not hidden by GGF), but you get extra features for free from the beginning.
The components that I am implementing are: settings, settings storage, console, debugging and dev. tools, entity management, configuration, packaging, introduction/graphic screens, menu system, entity and model pools, entity and mode modular loading, command line processing, headless mode console… All this is configurable and can be dropped, so putting everything together for a new project is a cut&paste matter ;).
Development-wise, it is showings some really cool things ;), and also has several flaws :|, all of which I'm finding along the way. Anyway it is difficult to describe it completely here :D. It is now 190 classes long.
By the way, I could use some help, but if one person is willing to learn and use this thing, I will be glad to answer questions here or by IM and help back us much as I can with your project, by providing fixes and explanations quickly.
And, yeah!, that tanks game is (very) based on Wii Tanks! game. It's a great game. This one is also meant to be cooperative like the original. But again, I'll be happy if it only works :D.
looks like robocode. i could port my ai.
The components that I am implementing are: settings, settings storage, console, debugging and dev. tools, entity management, configuration, packaging, introduction/graphic screens, menu system, entity and model pools, entity and mode modular loading, command line processing, headless mode console... All this is configurable and can be dropped, so putting everything together for a new project is a cut&paste matte
Entity management - so it has some built in entity management - I was sort of impressed by the ideas put forward in the data driven game engine threads where it was proposed to compose entities out of smaller components. Any quick description of how you have done it?
menu system - does this mean that you are linked to some GUI library? FengGUI or GBUI? Or have you made your own or is it just interfaces and more general code?
Do you make any assumptions on the type of games that can be developed using this engine? Real time/Turn based, how is the client server separation done if at all?
- There is an EntityManager service, and Entities are a core part of the framework. Base entities and entity groups are provided, and users are supposed to create their own entities (base clases are provided).
The loading subsystem greatly supports entity creation, as different mini-loaders can be chained to postprocess entities during loading. For example I use a chain that "reads the entity configuration from a file, creates an entity of the appropriate class, loads the model, sets up some stuff", but for some simpler examples I also have simpler customized ones that "just creates an entity, attaches a sphere to it, and returns it"… Another loader is a wrapper that pools entities loaded through it. For example, I added a pool for my bullets today in just 5 minutes, and I just needed to reconfigure the entity loader chain and add a call in my code to return bullets to the pool. Loading bullets is now so much faster…
- As with the console system, "menu" and "console" have separated functional and UI components. The menu system is not there yet, but the console is and the default implementation is pure JME (no FengGUI or BUI forced by default). I intend to use FengGUI for a related project so I will likely be providing a FengGUI implementation of a ConsoleViewState. The menu system is not working yet but it but the default initial visual implementation will be pure JME too.
- It doesn't make any assumption about the type of games users could create. I believe (and I have tried to ensure) it can be equally used for any kind of game as the framework doesn't get into the actual game logic. That's what user are supposed to code.
The whole framework is network-centric and that has been one of the main considerations during design. The structure should allow for an easy development of "client mode applications", "dual server/client mode applications" (without unnecessary data duplication) and "server-only (headless) applications". The game loop is divided between Logic and View, which is a subtle change over GameStates but still very similar. Communication between server and client modes is done through messages, which is quite an abstract concept so it could in theory fit any kind of communication (session-based, disconnected…). The framework helps a bit with networking in general.
Network is the only core part of the design that is still a work in progress, but I spent a good time with it and I think things are quite clear now. I have implemented networked games before. My current implementation of networking is custom, but I am planning to switch to JGN. Again, network could be changed (though unlike other features this would have a more serious impact on your existing code).
It is yet a very immature project, but the fact is that it is already working in many different aspects, so I wanted to share some pics.
If you or anyone else is interested in such a thing, I will be happy to send this and even more happy to get feedback. It definitely could use some reviewing.
It sounds very interesting for me and I would really like to take a look. How much useful feedback I can actually offer is probably a different thing, depending on a number of things starting from how clearly are things packaged to how much I actually understand the reasoning behind the different bits of code… I have a feeling you know quite a bit more than me about game design Perhaps you could send a PM if you do not want to post some SVN link here…?
Edit: If I can figure it out, I would probably also be interested in using GGF with my own project (should you choose to share it) as anything that would speed up the otherwise slow progress is welcome.
Nice to hear that.
I am waiting to see if Google /Sourceforge proves the name of the project. But anyway I’d like to wait to finish some heavy refactoring before making a first commit to svn.
If anyone is interested in a very early release, I have made the current code available here: http://rapidshare.com/files/158826955/20081029-ggf.rar.html. It will allow for only 10 downloads (please let me know of a better file sharing site). If anyone wants this and the download doesn’t work PM me and I will be glad to send it through email.
About it:
- Needs JME2 and JmePhysics on the build path. Other libraries are included, add them from directory /src/main/lib and source from /src/*/java:
- Please completely ignore all code under /src/apart/*.
- This is licenced under BSD
- The best place to start are the example configurations: /src/example/resources/tanks/tanks.xml and /src/example/resources/mudvolley/mudvolley1.xml and mudvolley3.xml. Read the XML and check what the classes do. I will be glad to discuss here or by IM.
- Several packages are documented, others aren't.
- Code has compile errors. You need to build with those.
- It is very early to use this for a serious development, unless you really want to.
I added a ViewState to show a grid, copying code from owaye, and I added with the following configuration:
<view id="view/root/level/axis" class="net.ggf.jme.view.AxisGridRenderView" context="debug">
<autoLoad>true</autoLoad>
<autoActivate>true</autoActivate>
<camera ref="scene/camera/test" />
<drawBehind>false</drawBehind>
<gridCenter>0.0 0.5 0.0</gridCenter>
</view>
And the result:
So far I like this system. It's really interesting in that it makes things simpler so hopefully it could make it easier for newbies to start out.
I like how you can define your game with XML, you can add a grid and configure it just like that, is it possible to do it with everything else too?
What exactly is jME-physics used for right now?
On a side note, it seems imageshack started adding ads to hosted images, "Do fish get thirsty? Take the dumb test now". Guess it's time to move to another image host…
Thank you! It really cheers me up especially coming from someone like you.
Yes, pretty much everything is defined from the main config file. For instance the Stats view, or the loading system, or the entity manager and groups. But sometimes you will want to create and add some components from code (mostly entities). The idea is that some components can even serve as a placeholder which you can replace afterwards, without modifying anything else.
Have a look at the tanks.xml configuration file :).
JmePhysics is a dependency because a couple of plugins for GGF are the PhysicsScene and the PhysicsEntity, which simply contain a DynamicNode or a StaticNode. But I will add a few other components like the physics debugger view and some other physics related stuff. Its easier when you see an example! ;).
Also, I don't know if this kind of things (frameworks) are good for beginners, but ideally it would be something that beginners can jump onto soon.
I have commited the initial version to http://code.google.com/p/jgf/.
I also put together a couple of diagrams. The first is the state lifecycle (this affects to logic, view/input and also entities):
And this is a very loose overview of the system. Each colored box is a service:
I have made some additions. Some of them may help explaining what JGF is about:
- In a game framework, we want a quick way of putting stuff on screen. I have added a DisplayItemsView that allows the user to put some images (I’ll add text) on screen:
Artistic abilities aside :D, this could be useful for introduction screens, loaders, and simple HUDs or in-game messages, and avoids coding for simple stuff like that.
In JGF, we add this ViewState and configure it like this:
<view id="view/root/intro/logo" class="net.jgf.jme.view.display.DisplayItemsView"
autoLoad="true" autoActivate="true">
<item id="view/root/intro/tech/1" class="net.jgf.jme.view.display.ImageItem">
<center>-0.66 0.5 0.0</center>
<textureUrl>tanks/texture/logo/tech-jme.png</textureUrl>
</item>
<item id="view/root/intro/tech/2" class="net.jgf.jme.view.display.ImageItem">
<center>0.0 0.5 0.0</center>
<textureUrl>tanks/texture/logo/tech-jme.png</textureUrl>
<size>0.8</size>
</item>
<item id="view/root/intro/tech/3" class="net.jgf.jme.view.display.ImageItem">
<center>0.66 0.5 0.0</center>
<textureUrl>tanks/texture/logo/tech-jme.png</textureUrl>
</item>
</view>
2) We want those states to fade in and out, so let's wrap them with the new FaderViewNode:
<view id="view/root/intro/fader2" class="net.jgf.jme.view.FaderViewNode"
autoLoad="true" autoActivate="false" >
<fadeInTime>1.5</fadeInTime>
<fadeOutTime>0.8</fadeOutTime>
<autoFadeOutTime>4.0</autoFadeOutTime>
<allowKeyToSkip>true</allowKeyToSkip>
<color>0.0 0.0 0.0</color>
<view>
...
</view>
</view>
And we have a nice fade in on each of the introduction states.
3) We can wrap all that in a SequencerState, so the introduction screens are activated and deactivated (and unloaded) sequentially. As configuration has a context, we can turn all of those introduction states off during development, just switching a parameter in configuration.
4) The pipelined loading system is proving quite efficient (for models, entities and scenes). It is easy to add on-demand model conversion, or entity pooling.
Wow nice diagrams. Just wondering, are you using any form of dependency injection to tie the different services together?
Very interesting. Did you consider the OSGi framework?
yunspace said:
Just wondering, are you using any form of dependency injection to tie the different services together?
I am facing some challengues with this. Basically, components get references to other components using the Directory, which is the only global:
ViewState levelView = System.getDirectory().getObjectAs("view/root/level", ViewState.class);
StateUtil.loadAndActivate(levelView);
Dependencies are not automatically injected or resolved at any point, probably because I haven't yet resolved the design of lifecycles and object creation so I am not really sure if I could provide an automatic, working mechanism to resolve references.
Different components need to resolve dependencies at different points: for example the SceneRenderView needs to get a fresh reference to the scene everytime its loaded (or activated?), but many components just need to resolve references during startup, and other components need to resolve references often during gameplay. Should I have an observer pattern to see when the referenced object changes? I am allowing users to set named references or direct references, and now I have the problem that at resolution time I don't always really know which one to use.
I did provide an alternate mechanism to resolve a bunch of references: you can annotate reference setters and call DirectoryInjector.inject(this) when you want references resolved, but this is not making things clearer, and of course it would be slower if someone happens to call that often. I think I will remove it because it doesn't add clarity and forces all references to have public setters and getters.
My experience designing this kind of systems is quite reduced and that doesn't help. My only experience is with EJB and references there don't change after Bean creation.
I could definitely use a mentor (if someone is happy to do that), but also I am learning while I move the example games forward. It is, however, really fun. When the whole "reference / lifecycle / execution flow / network" thing is clean, I'll be able to tag the code as 1.0 :). I expect three or four months will pass before that.
I added a features page: http://code.google.com/p/jgf/wiki/Features.
Nymon's amazing SceneMonitor has been integrated.
It's added as a View using something like:
<view id="view/root/level/ui/scenemonitor/switch" class="net.jgf.jme.view.ToggleInputView" context="debug"
autoLoad="true" autoActivate="true" >
<key>KEY_F12</key>
<view id="view/root/level/ui/scenemonitor" class="net.jgf.jme.view.devel.SceneMonitorView"
autoLoad="true" autoActivate="false" context="debug">
<scene ref="scene" />
<updateInterval>5</updateInterval>
</view>
</view>
I can't wait for SceneWorker... are there distributables already?
Slowly improving tanks…
