We know that just over 100 developers have now downloaded IwGame, but we don’t know who is using it and for what, so making the decision to big changes to improve the engine can be a tough choice, for example the recent animation system changes will have meant a fair bit of code re-writing for some.
We have a new big change that we would like to make to allow the engine and XOML in particular to support many more resource types. At the moment we have specific managers that manage separate types of resources such as images, resource groups, animations and time lines. The global resource system and scenes both have these managers. The change we would like to make its to remove all of those managers and have a single unified resource system that encompasses all resources and all resource types. A quick example can better explain this:
If you want to add a marmalade resource gruop to the scene so that it gets managed by the global resource system you would use code like this:
// Create a resource group for our level1 and add it to the resource group manager CIwGameResourceGroup* level1_group = new CIwGameResourceGroup(); level1_group->setGroupName("Level1"); level1_group->setGroupFilename("Level1.group"); level1_group->Load(); IW_GAME_GLOBAL_RESOURCES->getResourceGroupManager()->addGroup(level1_group);
At the moment you need to get the resource group manager and add the resources. The problem being that you have to request the resource group manager. We would like to change this so that you only ever have to request a single manager, so the code would look more like this:
// Create a resource group for our level1 and add it to the resource group manager CIwGameResourceGroup* level1_group = new CIwGameResourceGroup(); level1_group->setGroupName("Level1"); level1_group->setGroupFilename("Level1.group"); level1_group->Load(); IW_GAME_GLOBAL_RESOURCES->getResourceManager()->addResource(level1_group, "ResourceGroup");
You would call the same method no matter what type of resource you add, the only thing that would change would be the resource name type. So for example, if you pass an image you would pass “Image” or an animation you would pass “Animation” etc.
The major advantage of this system is that we and yourself included can add custom resource types to the scene and global resource managers, which means you can also include them inside XOML files.
If you strongly object to this change then please let us know quickly before we make a final decision.
Hi Mat,
I would highly welcome this change that you are thinking of implementing.
Will we be able to add Sound and Audio resources as well using this new method?
Best,
Criss
Hi Criss,
Thanks for the feedback, good to hear that you would welcome the change.
We wanted to make the change mainly for the Box2D integration. To attach physics to an actor you create a shape (for collision) and a physical material and attach them. The actor is then put under control of the Box2D physics.
We want to extend the system to handle all sorts of other things.
At the moment you can use attach a Marmalade resource group file that contains the sound effects then attach this to the audio system. In the future we will make it so that an audio resource can be created in XOML and then played at some point in an animation.
Mat
Mat,
Great job adding all those features. I am excited and looking forward to see Box2D integrated and I am sure that many others who are using the IwGame engine are looking forward to see it integrated as well.
Currently, I am porting my code of my app (the bedtime story) to start using the XOML system, with the hope that it will solve the issue that I was facing once I integrate those big image backgrounds and sound files. I suspect some memory fragmentation issue. Will let you know how it goes.
have a great day,
Criss
Hi Mat,
The biggest issue that I can see is in terms of concurrent access, but careful coding should alleviate any issues with resource locking, or thread unsafety.
Also with the game editor in place all that should be secondary since you can take care of any issues internally.
Flexibility is always a welcomed addition, also it would be nice to have case insensitivity for instance “ResourceGroup” and “resourcegroup”; or “Audio” and “audio” would be properly handled.
also it might be worth qualifying the method name from getResourceManager() to getGlobalResourceManager()
Looking froward to the next release. I have hold off from doing any further work until you say otherwise.
Hey, Mat,
Sounds good to me. The XOML system is very nice; any enhancement of that is welcome. I’m particularly looking forward to the Box2D addition.
Frankly, your game engine and the tutorials may have saved my project. My original programming sort of/kind of emulated many of the IwGame features, although in a custom form, but I’ve come into C++ from Eclipse and Java and my memory management skills ain’t what they oughta be!
Many thanks,
Keith
Hi Criss,
Box2D is now integrated, I’m just clearing up a resource leak issue and updating the documentation then I will upload 0.28 of IwGame. Here’s a quick example of how to use it in XOML:
You define physics materials:
<Box2DMaterial Name=”Floor” Type=”static” Density=”1.0″ Friction=”1.0″ Restitution=”0.5″ />
<Box2DMaterial Name=”BounceyBall” Type=”dynamic” Density=”1.0″ Friction=”0.9″ Restitution=”0.1″ />
And collision shapes:
<Shape Name=”Floor” Type=”box” width=”320″ height=”20″ />
<Shape Name=”Alien” Type=”circle” radius=”100″ />
<Shape Name=”Platform1″ Type=”polygon”>
<Point Value=”-100, -100″ />
<Point Value=”-100, -200″ />
<Point Value=”100, -100″ />
<Point Value=”100, 100″ />
<Point Value=”-100, 100″ />
</Shape>
And finally attach the material and shape to the actor:
<Scene Name=”GameScene” CanvasSize=”320, 480″ FixAspect=”true” LockWidth=”false” Colour=”255, 255, 255, 255″ AllowSuspend=”false” Gravity=”0, 10″>
<TestActor Name=”Floor” Position=”0, 200″ Size=”320, 20″ Angle=”0″ SrcRect=”0, 0, 36, 40″ Image=”Sprites” Shape=”Floor” Box2dMaterial=”Floor” />
<TestActor Name=”Player1″ Position=”0, 0″ Size=”100, 100″ Angle=”0″ SrcRect=”0, 0, 36, 40″ Image=”Sprites” Timeline=”Player1Intro2″ Shape=”Player1″ Box2dMaterial=”BounceyBall” />
</Scene>
By attaching a shape and material to the actor it is automatically put under the physics engines control. This new system allows you to create full physical and visual worlds that come under control of Box2D physics
If your resources are quite large then memory fragmentation shouldn’t be too much of an issue. We’re also looking to add memory buckets into the resource system, not sure how thats going to be implemented just yet though.
Mat
Hi Dan,
We have been considering case insensitivity in tag names, but wasn’t 100% sure whether or not to make the change. It is incredibly easy to forget about case when creating XOML so typos can easily creep in. I will take a look at adding case insensitivity for 0.28.
At some point we will look at adding none blocking resource and general file loading to the file and resource systems. We want to get the engine to a point where absolutely everything can be streamed from the file system and the web, allowing the game to move on whilst the resources are being loaded. We are part way there with none blocking http image loading.
We are due to start the game / media editor next week, hopefully we will have something usable within a month or so. Its likely that we will be creating the editor in Silverlight / WPF or even HTML 5. Not sure which just yet.
Mat
Hi Keith,
Glad to hear that IwGame is proving useful to you.
I love Java / C# memory management, part of the reason I like those languages so much. C++ memory management can be a pain. I often spend hours tracking down memory leaks. I tend to use managed objects a lot so I can let some system somewhere deal with cleaning them up for me and then memory pools to cut down memory fragmentation of small objects.
Our hopes are to see some great games using the IwGame engine to raise public awareness amongst the development community. We are going to be producing a number of games ourself with the engine once the editor is up and running (possibly making some of them open source)
Mat
Hi Mat,
I fully support the new XOML and resource manager approach.
I’m sure you do consider this, but it would be nice if IwGame features are kept as loosely coupled as possible. I say this because we are porting a 2.5D game and really like many IwGame features (ad provider support, audio system, XOML etc). I want to be able to use them without being tied to the standard IwGameScene. It would be especially nice if IwGameScene was refactored to have a common base that could be shared by 3D and 2D scenes, with multiple scenes being active at once (think 2D HuD on top of 3D game). It follows that IwGameActor would have a common base class or interface allowing non-sprite based actors.
I understand if you’d prefer not to make these sort of changes, but I think the added flexibility may bring more developers on board.
I also hope that the Box2D XOML is not coupled to the standard concrete sprite actor. From what you’ve shown so far it appears it is not, which is great. I hope to use it to define the collision objects in our 2.5D world.
To be clear, while my comments are due to the fact that our current project is porting a 2.5D game, I do plan to use IwGame for pure 2D projects too.
Keep up the good work!
PS the game we are porting can be seen here: http://www.youtube.com/watch?v=zPcxf0oDBpw
Hi Aranda,
I think you are correct with regards to linkage between sprites and actors. We plan on extending IwGame into the 3rd dimension at some point, probably after our editor is finished. In the meantime we could implement a IIwGameVisual and derive CIwGameSprite from that which allows other types of visuals to be handled.
With regards to scenes, again you are correct, we could do with creating a more generic base class and moving the generic functionality out into that class, maybe a IIwGameVisualContainer or something.
At the moment you can have multiple scenes active at the same time by adding AllowSuspend=”false” to the scene definition in XOML. This prevents scenes from slipping into a suspended state.
Square Off looks great by the way, nice work. how are you finding the WP7 market, are sales good?
Hoping to get the Box2D integration online today
Mat
Hey Mat, thanks for the answer, it’s nice to hear we’re on the same page about refactoring for 3D support.
The WP7 market is an interesting beast.
Paid games have to compete with all the Xbox Live branded games being very dominant and it’s therefore really hard to break into the top downloads list. Square Off made it to the #27 spot with 150 downloads per day, and there was only one other non-Xbox Live game above us at that point. We also found that the conversion rate wasn’t wonderful – our Xbox Indie version converts at 50% consistently, but on WP7 it is more like 5-10%. I put this down to people not having payment systems set up by default and there has only recently been an equivalent of the iTunes gift card for WP7 which doesn’t help. Might also be the fact that Square Off was really designed as a (local) multiplayer game, which doesn’t translate especially well to a phone.
Free games seem to fare better, and our free version has had 160K downloads now. It was released in October and peaked in the top 5 free games in the US with 2500 downloads per day. It’s now down to <1000 per day at spot 40 – 45.
Overall I feel the game has done quite well. It's able to stand out a bit as the vast majority of games (and apps) are terrible. While it's not earning a mint, it has been very well received which makes it worth while regardless. I'm hoping the WP7 market's numbers will improve with time and Nokia. From a pure business perspective, we probably would have been better to port straight from Xbox to iPhone / Android.
Our first released smart phone game was BattleBallz for WP7. We we’re using Silverlight quite heavily at the time so we gave creating a complete arcade game in Silverlight a crack. The first version had performance issues so we went back and optimised it to the max. It now runs at an acceptable frame rate. It flopped on WP7 however, but then again its the wrong kind of game for the average mobile user. Its not done particularly well on any of the other platforms. I think we may wait a while before we venture back into WP7 (because of the Xbox live issue). We have plans in the engine roadmap to produce a C#/XNA version of IwGame, so some time after that’s finished.
Glad to hear that you are doing pretty well on WP7, its definitely a tough nut to crack.
I do think that for the time being at least that you stand to make much more money by concentrating on iOS / Bada and Android / Playbook to a lesser degree.
Our best earning performing platforms for paid apps are in this order:
Bada
Java ME
iOS
Playbook
Android
WP7
Whilst free seems to be different:
Android
Bada
iOS
WP7
We can’t include Playbook as we don’t have a free product on that platform yet.
That said, every app / game is different so other developers may see a completely different picture to us.