I’ve been very busy with life since my last blog entry but stilll a lot happened since then regarding IGF development so I decided to sum them up and make a quick post.
Open Source & Contributors
As I shared with you a couple of months ago, after I called for contributors to help me move IGF forward, I received a few emails asking to participate. So far, I have 3 contributors that would be likely helping building IGF v1.0. They’ll shortly be able to work on the project as I put the team workspace in place.
This workspace will be composed of a source control repository and a set of project management & communication tools. I’m still talking with John from SynapseGaming to prepare that environment and making sure we don’t break any SunBurn EULA rules. I hope to get that working with IGF v0.7 release.
IGF v0.7 was mainly targeting the Project Mercury particle system implementation and I’m quite satisfied with current status which will probably be on the next release as is. However I also made some R&D on some other aspects and surprisingly I get most of them in a shape that conforts me to expand IGF v0.7 scope.
- Local Session system: IGF v0.7 will let you create local only sessions so that you don’t require Xbox Live to get the Logic domain & features being processed in a single player game.
- WP7 Support: I made IGF v0.7 work on Windows Phone 7 with a few changes. The sole point I didn’t made it through is how to handle WP7 input inside the InputManager: I need to make some more research here to implement best practices. I’m unsure to finalize the WP7 touch input integration within InputManager but I’ll for sure release an Alpha preview of WP7 support as part of IGF v0.7.
I also worked on a few optimizations but didn’t yet get them to work properly so they may not be part of the next release:
- Multithreaded AI execution: as of IGF v0.6, all AI using the Logic domain is executed in the main thread. While this is enough for simple behaviors and/or few agents, with a world composed of a great number of agents or if AI behaviors require more than the 16ms limit per frame (to get 60 fps) this execution pattern may become a problem. I’m therefore working on the Logic & Session domains to process it in a second thread. Almost there but I must ensure that all the Logic is thread safe which isn’t trivial
- Performance control on Logic processing: I’m also implementing some properties in Steering Behaviors, Finite State Machine and Goal Driven AI to provide you with a better control how often their logic gets processed to let you optimize how many times they get called. This will let you optimize their usage depending on your game needs.
- BEPUPhysics Manager: One of the contributors is working on a BEPUPhysics manager implementation that will replace the standard SunBurn CollisionManager instance and respect the ICollisionMove contract set in the SceneObject class. This should let you switch from CollisionManager to BEPUPhysicsManager without making any changes to your code still getting all the features from BEPUPhysics. I didn’t see the code yet as we don’t have the workspace environment setup yet but I’m eager to have a look
Well, since I’m going on vacation the 22nd August until the 3rd September, I don’t want to flew far from any internet connection without pushing v0.7 up for you to play with.
You should therefore expect a release before the 22nd August
If you followed my previous blog entry as well as my tweets, you may have noticed that I got Mercury particle system integrated quite quickly to IGF v0.7 and SunBurn. Therefore, I decided to implement a small additional feature as part as the v0.7 release: Local sesion system.
Up to now, the sole way to get the Logic system coming with IGF was to use the LiveSessionManager which wraps Xbox Live networking. But what if you are developing a Windows title? What if you don’t care about multiplayer but still want to use the IGF Logic system?
I had that in mind from the beginning when I conceived the level of abstraction surrounding the Logic and Network namespace in IGF and it was time to get a proper session system.
I have now a fully working local only session system for you to play with the Logic code. From my early tests, I already plugged the system with my own game (Cosmos Conflict) as well as the Pong sample accompanying IGF releases so far with just a single line change in the code. In the Application.InitiallizeSunBurn() method, instead of using:
I simply replace it with:
With this single line changed, all the logic code I used including the AI code coming with v0.6 (Goals, States, Steering Behaviors), all works like a charm.
I’m really pleased to see that working as I expected. If you want to develop your game, you’ll now be able to develop the single player game logic using the LocalSessionManager and if you want to port your game to Xbox, simply change it to LiveSessionManager and done!
Windows Phone 7 support
This session system was also the sole feature in IGF that couldn’t be ported to WP7 impeding me to release such build. Now that I have a local session system ready, I’ll experiment porting the whole framework to WP7. If I get it close to work before the end of the week, I’ll consider WP7 support as part of v0.7 release
I’ll try to keep you updated with my progress.read more
Finally, I’m pleased to announce the official availability of the Indiefreaks Game Framework v0.6.0.0. It asked me a bit more time to complete because I had to make a high number of tests so that the new features would fit properly with the Logic & Networking system.
For those who may have not followed the framework development, this version is primarly focused on Artificial Intelligence and I’m therefore introducing 3 new features for this unique huge topic:
Steering Behaviors are a set of behaviors (inheriting from the Behavior class and therefore totally compatible with the IGF network abstracted Logic system) and an Autonomous Agent (implemented as a SunBurn Component) that you can configure and add to any SceneEntity or SceneObject instance in your game providing therefore natural movement behaviors to your game entities without the hassle of implementing a lot of game logic to handle all possible cases.
Finite State Machines
Finite State Machines are the first AI system I added to IGF that allow you to define a set of states for your game entities and change them following some unique game logic rules you’ll implement in your code.
Goal Driven AI
Goal Driven AI is the second AI system I implemented in IGF which is slightly more complex but very practical and powerful when you need some advanced AI behaviors. To sum it up, it allows you to define general goals (i.e.: attack ennemy) and add sub goals that will be more explicit and define the tasks that need to be made to achieve the goal higher in the hierarchy (i.e.: find nearest enemy, find most threatning enemy, turn game entity to aim enemy, fire at enemy, …).
For the first time, I’m not including a dedicated sample because, as I explained earlier, each sample is really time consuming and since they’ll be replaced for v1.0 by a unique sample and a set of tutorials to teach developers how to use IGF, I decided to move as fast as possible towards v1.0 release and work on this final sample at the real end.
I’ll still be available in the forums if you need any help using these AI features in your game correctly.
And the v0.6.0.0 Release Notes:
- Feature: Implements SunBurn engine 126.96.36.199
- Feature: Added Steering Behaviors for Aunotomous Agents that work on both 2D & 3D worlds: Alignment, Arrive, Cohesion, Evade, Flee, Hide, Interpose, Obstacle Avoidance, Offset Pursuit, , Pursuit, Seek, Separation, Wander.
- Feature: Added Finite State Machine AI structure for you to easily add intelligence to your game entities
- Feature: Added Goal Driven AI structure for you to add complex AI behaviors to your game entities
- Misc: Added new signatures to Application.FadeIn and Application.FadeOut static methods to let you define how long it should wait before actually fading in or fading out. Useful when you need to fade in or out when the loading gamestate ends loading.
- Misc: Changed IRenderEntity.Visible property to IRenderEntity.Show to avoid confusion with SceneEntity.Visible property
- Fix: v0.5.0.0 introduced a structural bug on the Agent class with the static CreateBehavior method: replaced it back with the Add static method.
- Misc: moved Microsoft.Xna.Framework.Game.Draw() base call inside Application.Draw() at the end of the method for better control on rendering.
- Misc: moved all collections to dedicated namespace: Indiefreaks.Xna.Collections.
- Misc: Network Session now automatically registers and synchronize SceneEntity and SceneObject instances over the network so that Commands and Behaviors get processed correclty
- Misc: Moved PlayerAgent and NonPlayerAgent networking processing code from Session class to these classes directly since they are network independent.
- Misc: Added a default OnInitialize() implementation to Behavior class so that each behavior registers automatically its ParentObject (SceneEntity) on the current network Session if not registered.
- Misc: Behavior class now implements IDisposable to ensure they get disposed properly.
- Misc: Command class now implements IDisposable to ensure they get disposed properly.
- Misc: Replaced all Func<> and Action<> generic delegates in Command class to specialized Condition, ClientCommand, ServerCommand and ApplyServerCommand delegates to ease understanding
- Misc: Added an abstract Clone method to Gui Control class as well as all inherited classes to create controls from an existing one.
- Misc: Added a RemoveAll method to Screen class to allow direct removal of all Controls added to it.
- Misc: Changed InstancingFactory to support new SunBurn 188.8.131.52 RenderableMesh.Build() method
- Misc: Changed all samples to reflect corrections
I spent the entire week end talking with really helpful and talented .net developers that know very well how the .Net framework works behind the hood to sort out my issue with the code injection on the “to be” profiled assemblies relying on the Xna Xbox 360 Compact Framework. They really helped me a lot understanding what was going wrong and what were the options for me to solve the issue. I’ll therefore make a small tribute to them and their work:
So, to sum up the current situation, the current beta builds of the Indiefreaks Game Profiler work perfectly on Windows & WP7 (at least, I didn’t receive any bug/issue/feedback from the current beta testers).
However, as I pointed out on my previous blog entry, I’m meeting a very annoying issue with the Xbox 360 build. It compiles fine but it doesn’t work at all when applied to an Xbox 360 Xna project.
The reason is on the code injection and AOP approach: I’m using PostSharp to inject the profiling code before and after each method in the profiled assembly and the framework cannot process it because the Xbox 360 Compact Framework Runtime dlls are just stub assemblies used only to verify .net framework calls when building on Visual Studio.
I first tried to by pass the System.BadImageException I received on my tests, but it couldn’t be done unless Gael Fraiteur would add support for the Xbox 360 Compact Framework in PostSharp but their isn’t enough value (our potential customers) for him to go down this road which I totally understand.
The discussions during the week end lead me then to use Mono.Cecil to perform the code injection and I must admit than, even if I’ll have to play directly with IL byte cote, it is first very interesting to learn how it works behind the hood (for potential later optimizations on my own games and the Indiefreaks Game Framework) as well as extremelly porwerful.
I have moreover high hopes that it’ll make the Indiefreaks Game Profiler setup on your Xna assemblies even easier than it currently is as I’d be able to put it all in a simple console application that you’d execute on a Post Build event in your project properties or even potentially on a MSBuild custom task which would be even easier.
IGF v0.6.0.0 status
On a side note, while I was waiting for the great advices from the above mentioned .Net players, I opened up the Indiefreaks Game Framework code and documenting the new namespaces and classes for v0.6.0.0 release. I documented around 1/3rd of the new classes and as soon as I get that done, I’ll spend some time building a dedicated sample for the Steering Behaviors, Finite State Machine and Goal Driven AI. Once finalized, I’ll have v0.6.0.0 ready for release which I expect to happen in the first or second week of July.
Until then, be sure to check out the impressive work made by Indie Studios using the SunBurn engine for their Dream, Build, Play 2011 entries: they made a wonderful job demonstrating the engine capabilitesread more
Now that I have almost all Steering Behaviors in IGF for the next release, I still needed a way for the developer to define how their game entities (SceneEntity or SceneObject instances) would decide which of them to enable and when: I needed a way to give them the ability to make decisions, to give them a brain
When you’re working on AI for your game, there are multiple ways to let your game entities make decisions. They are all arbitrary as they should follow the rules the developer or game designer decides to apply.
The simplest and most used pattern is the Finite State Machine and I’ll go through the implementation and how to use it in this blog entry.read more