Hi Everyone,
The IwGame Engine has been in development for around 6 months now and although we’ve received lots of feedback regarding bug reports and feature requests we would like to know your opinions on the current state of the engine. Here are a few questions to consider:
- Is IwGame difficult to use, if so can you suggest any improvements that we could make to make it easier to use?
- How are you finding the current feature set? Is anything particularly buggy, hard to use or simply missing something?
- What’s the next BIG feature for you, what would you really like to see come next?
- How are you finding using XOML? Do you prefer the declarative approach or do you prefer to code things up in C++ instead. Can you suggest any improvements you would like to see?
- If you have recently stopped using IwGame, what made you leave? Was there a better option and if so, what was the deal making features?
This is the opportunity to have your say, any feedback that you can provide is greatly appreciated and will help steer the direction of the IwGame engine.
Mat
Hi,
1-Is IwGame difficult to use, if so can you suggest any improvements that we could make to make it easier to use?
Yes it is for me as i come from corona. I like this engine but i (and others like me) need a step by step tutorial where you start from scratch and build a game and then publish it to all the supported platforms.
Also recommend some books as people like me have no real experience in C++ (just in uni course)
2- How are you finding using XOML? Do you prefer the declarative approach or do you prefer to code things up in C++ instead. Can you suggest any improvements you would like to see?
XOML is great, so continue working on it.
Your step by step game tutorial is a very good idea, I will make that a priority
Mat… I have a lot a experience in enterprise development, but really new into game development. I actually decided to start using IwGame engine after reading your Marmalade tutorial. For me the XOML made the difference in my decision to start using it.
My comments about about your questions:
* It is easy to use, but current start example make is hard to know what is happeing (if you haven’t read tutorials or documentation). Simple examples with especific features could be good.
* It would be good to have a way to define a sprite animation definition automatically. Some actor (or animation) that could be initialized with image, x,y spriteWith, spriteHeight, rows and columns. It would create internally the animation frames
* To make things a little
* UI could be the next BIG feature. Simple ways to create Buttons, Dialogss, Grids
* XOML is great! And the mix of declarative and coding directy in c++ is a good aproach as you can easly split graphic/animation from what game logic. Templates are very nice and it would be good to have an easer way to pass the parameters, something like template->addParameter(“name”,”value”), with some overload for different value types (int, vec2, vec4, etc)
As you know I launched my first game early this month (https://play.google.com/store/apps/details?id=com.ar.balloonchallenge). It was easy to implement thanks to IwGame engine.
Great work
We currently have CIwGameAnim::GenerateAtlasFrames() but that’s only accessible from code. Just added this feature to XOML
Been thinking about UI a lot lately because of a game I’m currently working on that requires a fair bit of UI. Still not decided to go with IwNUI, IwUI or our own IwGame solution yet. Will post more soon when we’ve made a decision.
Will add your template suggestion to my to do list
Will grab a copy of Balloon Challenge and leave you a review.
hi mat,
1, Is IwGame difficult to use, if so can you suggest any improvements that we could make to make it easier to use?
Yes its difficult to use , it does good thing but really hard to use . Step by step approach just like your marmalade tutorial series . You don’t need explain like it in tutorial series but make source code easily readable . Please make XOML for advanced user and separate it . make more examples and explanations in coding .
2. How are you finding the current feature set? Is anything particularly buggy, hard to use or simply missing something?
XOML crashing a lot and hard to find out why its crashing .
3.i like to see good documentation
4.XOML approach is good for peoples who understand it and for people who understand iwgame engine but not for new peoples it crashes a lot when parameters are not set properly .I like to see XOML as a second alternative use rather than pushing it head over Coding .
5. yes i was leaving the iwgame engine as of now . Just because i first came here to learn marmalade tutorial series to make me understand more about marmalade . Iwgame engine is feeling too much for me now. I am not targeting multiple platforms right now . Also many things for me about iwgame engine is good but its not needed for my game . I have to learn many things like level designing , physics engine etc so i want to spend time on that instead learning XOML systems and Actors where little documentation available . Still i am here trying to figure out box2D implementation and working but again very little documentation and more on XOML implementation making me hard to understand :((
gamer
Regarding XOML crashes and incorrect parameters. You need to keep an eye on the debug output, IwGame will display any XOML errors / warnings in the debug output. We are looking at the possibility of creating a XOML editor to make putting XOML together much easier.
There is a 177 page manual in the Docs folder, can you tell us what’s missing from the manual? What you would like to see more of in there?
If you are quite fresh to game development then you should probably get used to level design and general game coding techniques firstly. I will look at putting a Box2D tutorial together in the near future, if you have suggestions for other tutorials then let me know.
Mat
1)Is IwGame difficult to use, if so can you suggest any improvements that we could make to make it easier to use?
I come from an embedded systems background using C++ for modeling avionics & systems for navy aircraft platforms, So I am very familiar with C++, but new to game programming. I find IwGame very easy use and follows a lot of good programming practices. You have to read the documentation and sometimes need to experiment. As I have stated in other post, I have a Love/Hate relationship with XOML. Finding bugs can be hard to find and goes against finding problems at compile time. But I think I would also make a lot of mistakes if I had to code it all by hand what can be put into XOML. I lost 4 hours chasing down a XOML timeline bug where I used Name=”” for the animation instead of Anim=””. Stared at it for hours comparing what worked and what didn’t until I saw the difference. Your documentation is excellent. The only part I see missing is a description of the of the parameters for Actions, Looking at the source code & examples I can usually figure them out.
2)How are you finding the current feature set? Is anything particularly buggy, hard to use or simply missing something?
The current feature set is currently a lot more than I need. The only part I find buggy is some of XOML errors for missing parameters is not always caught and printed to debug output, which can result in some strange behavior and be hard to find. I am currently having a problem where tapping an actor sets off a bunch of timelines. on some random occasions it sets off a completely separate bunch of timelines for other actors. I have not figured out what is going on there yet. Dont know if it is a bug yet or not.
3)What’s the next BIG feature for you, what would you really like to see come next?
A big feature that I require is a network multiplayer connectivity with lobbiing and game matching. I am looking at Raknet and Photon Network Engine. I not sure if this is something that you would want to include in you engine. I have many small ideas/features that I will continue to add in the feature request forum. A possible feature that may be useful is language localizing feature to support multiple languages. I am still working on the best way to implement this, I know there are alot of standard practices out there.
4)How are you finding using XOML? Do you prefer the declarative approach or do you prefer to code things up in C++ instead. Can you suggest any improvements you would like to see?
I am learning to like XOML. What I find works for me is to declare all my Actors and timelines in XOML. I then create a lot of bindings from variables to to actor attributes that I want to change during the game. During the first frame of a scene I get and store all a Proxy to required XOML actors, variables and timelines in scene member variables. so I can update these by code in my Scene class. It may be a little inefficient but appears to be working. I was having a hard time getting the functionality I wanted until you added the bindings capability.
5)If you have recently stopped using IwGame, what made you leave? Was there a better option and if so, what was the deal making features?
Will never leave IwGame, Your knowledge and implementation of Scenes and Actors has made my project doable. The other deal making feature is the virtual canvas to allow easy support of all the different device types and resolutions. Keep up the good work. If my project is successful, I plan to make a sizable donation to show my appreciation to your efforts and dedication.
I plan on taking a closer look at the XOML system this coming week, to see if I can add more informative messages in there. For example, I am considering implementing sanity checking into all XOML loaders, so if something is missing then it will let you know. Hopefully this will help. We also have plans for creating a XOML editor in the neat future which should hopefully make XOML more manageable.
One thing to watch out for is having more than one resource with the same name in the same scene scope. This has caused problems for me in the past. If you send me across your XOML file I can take a quick look to see if I can find the timeline problem.
We have an HTTP based multi-player engine on the roadmap (not really designed for fast arcade response though) that supports users and data sharing between opponents / friends etc.. This is however some way off. I’ve heard lots of good things about RakNet, but not taken a close look at it yet.
Usually we handle localisation using a string ID / named string system. We have a list of strings for each language and use the string ID / name to index into the list. Its a very quick and easy system to use. The only downside is that you have to print text by ID instead of text strings. We can incorporate something like this directly into XOML quite easily. Will add that to my to do list
Bindings are great, they save a lot of time. We added them in up-front ready for when the UI system goes in. Hopefully we should have a nice UI system within a month or so. We want to do this like Silverlight though, where you can bind a complete array of data to the UI and the UI just displays it and allows the user to interact with it (much like a data grid control). We want to make IwGame viable for apps and games alike
Glad to hear that you’re sticking with IwGame, makes the hard work worth it when we see developers using it. If you manage to create the next Angry Birds then a small donation would be more than welcome 🙂
5) We evaluated 0.32 version and dropped it, because we felt it seems to have “all or nothing” policy. It was hard for us to adopt features one by one (for example sprites) without following all the workflow intended for the engine – in case of sprites this implies using managers, actors and xml too. In other words, we felt the features are too much coupled with other and there is no easy possibility to start using them incrementally. When we tried, it usually led to various crashers and side effects.
Much of IwGame is provided as a one stop solution game engine. The idea is to provide all of the functionality needed to develop games barring the logic. Its a system that once learnt can provide an incredible speed boost in development.
FYI sprites can be created and rendered manually without any need for a sprite manager, scene etc.. Many of the low level components operate independently if needed.
Hello,
I’ve already written a comment in an old post congratulating you for your awesome work. As I said before I’m a “veteran” in the industry so I don’t find IwGame hard at all. Also I want to add that (and I don’t mean to offend the previous commenters) Marmalade isn’t a SDK for “beginners”, like Corona or even Unity (an amazing SDK but for a c++ programmer is like to be sentenced to death). The main reason because I’ve chosen marmalade for my team is that we can re-use most of the thousands of lines of code that we have written for our previous titles. A beginner shouldn’t even look at Marmalade in my opinion, since its learning curve is too steep (even the deployment process is complex compared to other SDKs). So, back to IwGame…I’ve started to use it because just after switching to Marmalade I had to complete a prototype of a game in 3 weeks for a client (a pretty complex prototype by the way). Since I was new to Marmalade I searched on the internet for something that could help me setting up the environment and that could give me some basic functionalities from the start and thus giving me some more time to concentrate on the game itself instead of having to re-write all the basic classes to work with marmalade. I’ve tested IwGame for a couple of days and found it to be very well written and very well documented. In the three weeks of development of the prototype I’ve changed and rewritten almost the 30% of IwGame to suit my needs (completely rewritten the IwSprite and IwRender2d classes that are the weakest point of IwGame engine in my opinion) but the “core” architecture of IwGame is still there and it’s very well done. I’m also using Xoml a lot (only for the interfaces/dialogs etc. but still very useful). I suggest you to change the xml parser and use tinyxml instead, because your implementation eats an awful lot of memory. Since I’ve changed IwGame so much I can’t even update to future releases (for this project) but it saved me an incredible amount of time (I couldn’t have done the prototype without IwGame).
A part from bugfixing I would like to see improvements in the graphics classes, like adding basic 3d models support, shaders support, blending/mipmapping/filtering setting per object, internal use of floating point instead of fixed point (fixed point leads to a lot of problems at least if you are workinf on something more complex than tetris), speed optimizations (visibility checks of what it’s rendered for example) etc. I did al this stuff in “my” implementation but sadly I can’t share the code because it’s very very hardcoded (and also because I’m working for a company so what I code is their property…)
Also some UI classes could be very useful (I use Xoml templates/bindings etc. to do all the UI stuff, very powerful but time consuming, some ready to use classes would be a lot better).
In the end my only “real” advice is to keep IwGame aimed for “professionals”. If you try to render it “amateurs friendly” you will be disappointed because 1) Marmalade is all but for amateurs (even the license cost is higher than most SDKs) 2) beginners could start to use IwGame but they will abandon it at the first difficulties 3) Beginners don’t usually finish their projects so your engine won’t basically appear in any game 🙂
Just my two cents obviously!
I agree that Marmalade is not for beginners. C++ is probably one of the hardest programming languages to master. The aim of IwGame is to take much of the grunt work out of putting systems together to create a game using the Marmalade SDK. Hopefully when we get our XOML editor together in the near future, using IwGame will be much easier for less experienced developers to use. We hope that one day designers will be producing interactive content via the editor with no need for coding. The recent modifier additions should go a long way towards making that happen. This is not to say that we wont be continually improving the engine with more advanced features which we will, we just want to give easy access to them via XOML.
Great to hear that you used IwGame as a basis for your own project, its a pity that the updates wont integrate easily.
Our next major feature is UI functionality. We are still in the process of deciding how to implement this, but its most likely going to be a custom solution. We have lots of features planned on the graphics department including shaders, 3D models, skeletal animations. Marmalade 6.1 will provide low level floating point rendering support, so we will switch over the internal rendering system to floats once that’s released.
We avoided TinyXML because we read that it doesn’t use memory pooling.
1-Is IwGame difficult to use, if so can you suggest any improvements that we could make to make it easier to use?
NO, NOT AT ALL. I FIND IT VERY EASY TO USE MAYBE BECAUSE I HAVE BEEN AROUND IT SINCE THE EARLY DAYS WHEN IT WAS ONLY A TUTORIAL FOR MARMALADE. HOWEVER, ONCE YOU GET THE CONCEPT, EVERYTHING WILL START TO MAKE SENSE. I CAN PROTOTYPE A GAME IN HOURS INSTEAD OF DAYS 😉
2-How are you finding the current feature set? Is anything particularly buggy, hard to use or simply missing
I AM SURE THAT NEW FEATURES ARE GREAT, BUT I AM NOT FINDING THE TIME TO USE THEM BUT I AM SURE THEY ARE ALL USEFUL FOR LATER PROJECTS. I JUST NEED TO FIND A FASTER WAY TO DEAL WITH THE NEW FEATURES THAT KEEPS ROLLING IN.
3-What’s the next BIG feature for you, what would you really like to see come next?
-UI
-3D
-TITLE BASED GAMES
4-How are you finding using XOML? Do you prefer the declarative approach or do you prefer to code things up in C++ instead. Can you suggest any improvements you would like to see?
XOML IS GREAT, ITS ALLOWING ME TO RE-USE LOTS OF THE FEATURES THAT I DEVELOP. I USE XOML AND C++ IN PARALLEL, I EVEN FIND MYSELF ADDING THE CLASS IN C++ OF A SCENE EVEN THOUGH THAT I WILL NEVER GONNA USE IT. THE ONLY IMPROVEMENT THAT I LOOK FOR IS THE EDITOR THAT YOU MENTIONED. I AM LOOKING FORWARD FOR IT. IF SUGGEST THAT YOU LOOK AT THE EDITOR OF TORQUE2D FROM GARAGEGAMES, I THINK THEY HAVE A GREAT APPROACH TO DEAL WITH THIS KIND OF PROBLEMS 😉 THEY CAN EVEN DEAL WITH THE PHYSICS OF AN ACTOR
5-If you have recently stopped using IwGame, what made you leave? Was there a better option and if so, what was the deal making features?
I BELIEVE IN IwGAME AND THE MARMALADE BEHIND IT MAKES IT A PERFECT COMBINATION IN ORDER TO DEVELOP CROSS PLATFORM GAMES.
LAST BUT NOT LEAST, I WOULD LIKE TO KNOW THE BEST APPROACH TO TAKE IN ORDER TO EXTEND IwGAME WHILE AT THE SAME TIME COPING WITH THE AMAZING UPDATES THAT YOU KEEP ADDING. I FIND MYSELF SPENDING HOURS TRYING TO PORT MY MODIFICATIONS FROM ONE VERSION TO ANOTHER. I AM SURE THAT MANY DEVELOPERS WOULD WANT TO ADD PLUG-INS FOR THE ENGINE OR JUST MODIFY SOME INTERNAL FEATURES.
FINALY, I WOULD LIKE TO THANK YOU A LOT FOR THE AMAZING JOB THAT YOU’VE BEEN DOING. IwGAME IS GREAT, IF I SURVIVED 6 MONTH OF IT, I THINK I WILL SURVIVE ONWARDS. 🙂
I’m hoping that once we have the examples collection together we can release examples showing the latest additional features with a release, this will provide working code for people to re-use straight away.
We’re working on UI right now. We started by adding a docking system to actors so they can be docked around the edges of the screen. We’re now in the process of adding a variety of different panel types such as stack panels, grids etc.. Hopefully we can have our first version of a UI ready soon. We decided to create our own custom UI system to keep the engine free from platform specifics and more easily portable.
The editor is still very much in the design stages, but for now we have released the XML schema for XOML to make editing much easier.
Do you use a good diff program to merge in the latest changes, such as DiffMerge or Araxis Merge? Merging in the future should get a lot easier as we hope to release most of the new engine updates via the extensions system.
Thanks Matt for your reply,
I think having some examples for the latest features is a great asset and a faster learning pace for all of us.
Also, having custom UI is an awesome idea since it adds access to more platforms than Marmalade’s IwUI
which only supports iOS and Android.
I do use UltraCompare for merging my code, but some features proved to take lots of time to re-implement since the code base of IwGame has undergone some huge changes since 0.28. I still have features that I have implemented in 0.29 that I haven’t ported forward yet.
have a great Sunday
Criss
We’re more or less happy IwGame core so hopefully there wont be many changes in that department, so integration should be easier in the future. That said we do want to rework the 2D rendering system as well as the brush system to allow the use of solid colour and gradient fills as well as arbitrary shaped sprites. We also want to look at the possibility of incorporating shaders.
The UI is on its way to being built although I’m going to be busy most of this week so progress will be slow. We have dockable stack panel and grid controls done for the moment, more to come over the next few weeks. Hopefully we will have a nice solid UI finished within the next 2-3 weeks.
I’m brand-new to both IwGame and Marmalade, although I do have a fair amount of C/C++ indie game experience (but it has quite some years ago…). So there isn’t a lot I can comment on just yet, but these are my notes so far:
XOML seems to be a great way to go, primarily because it allows a lot of things in a game to be added/changed/etc without recompiling any C++. This is good because 1. C++ is notoriously slow to compile. 2. It should make extra levels/expansion packs/etc much, much easier to create and distribute.
However, I find XML – and therefore XOML – to be excessively verbose. It would be fantastic to have something cleaner like SDL ( http://sdl.ikayzo.org/display/SDL/Language+Guide ) as an alternative. Of course, I can just make/use a tool to convert to XML, but true native support for a more succinct data language would be nice.
Also, the process of binding new classes to XOML by manually subclassing IIwGameXomlClassCreator strikes me as being more boilerplate than should really be necessary. Maybe I’m just spoiled from having spent the last few years with D, but can’t a simple macro or something be created to help automate the process? Something like:
REGISTER_XOML(MyCustomActor) // Basic “new MyCustomActor()” stuff
REGISTER_XOML_SPECIAL(ComplicatedActor, createComplicatedActor)
ComplicatedActor createComplicatedActor()
{
SomeObj o = new SomeObj();
actor = new ComplicatedActor(4, 17.32, o);
actor.foo();
return actor;
}
SDL looks great, I will add support for this onto our roadmap. Although there wont be a schema like we currently have for XML.
I like your macros idea, will begin adding macros to simplify many areas of IwGame.