jtianling wrote:
I think I could help to write the shell script,But because I just came from Windows/VS platform,I have no idea about the project template and file template in MacOS/XCode.
Thanks for the proposal, but if you don't have time to look into this I'll have a look into Cocos2D a in couple of weeks. I'm pretty new to MacOS/XCode and XCode really doesn't like me much (and it's reciprocal
).
BTW:post some thought here after I learned orx and cocos2d for IPhone.
Cocos2D for IPhone is the best 2D engine for IPhone I found.It have many useful game concept.Like Layer,Scene,menu,tile map.It's action design is great.
It more like a tradition game engine with sprite,animation than orx.It supports some 3rd animation editors like Zwoptex to make the animation support easier.It supports 3rd map editor too.But when you should make thing with box2d,you should straight use the box2d library and code for the
relation between the abstract physics world with the sprite you made.
I heard very good things about Cocos2D and I only have looked at it on surface so far.
To me, it didn't appear as a game engine but more as a high level game library, which isn't a bad thing, but not what I'm trying to do with orx.
I usually see 4 different kinds of game creation tools:
- Low level game libraries: Allegro, SDL, ClanLib, ...
- High level game libraries: IndieLib, Cocos2D, STK, ...
- Game engines: they're usually 3D ones: Panda3D, Irrlicht, Delta3D, ...
- Fully integrated game engines: Construct, Unreal, Unity, GameMaker, ...
I think orx is (or trying to be) part of the third list. You don't manage sprites, sound resources etc, in orx, you just have objects with properties and rules in a 3D world.
What it means in the end is that, as you said, there's a higher level of abstraction which usually leads to less low level control.
As everything is public in orx, and due to the plugin architecture, you could take control of the low level parts, even rendering if you needed 3D support.
Of course, it's not the philosophy of the engine and I'm trying hard to make things so that you wouldn't feel the need too much to do so.
Orx is the way it is because I don't like having to initialize in code a whole bunch of things and write 10 lines everytime I want to add a new sprite with a visual effect.
I'd rather just change some parameters in config and restart the program without changing a line of code, or even just reload the config file on-the-fly depending on the cases.
Of course, nothing's perfect and this aim isn't totally reached, but that's my current goal: having the least amount of code to write as possible.
I'm a low-level programmer with an history in the demo scene so I love doing low-level code for optimization or some visual effects for example.
However, when I want to write a high level applications, such as games, I'm very lazy and want all the repetitive tasks to be hidden from me and done automatically.
ORX's abstract level is high....because everything is a object with physics and sprite/animation.I could create a object with one line code and everything is fixed in setting.But the problem is That I didn't know every setting really means and what setting I can set.The only thing I can do is to try and try again,But after that,If I still have problem,It too hard to step into code to found what I did wrong.(Though iarwain is very kind,but I shouldn't bear to fix every problem after a day....)
orx is too radical for setting(setting can't be equal to data) without a useful editor.........
I totally understand your frustration.
There isn't much documentation so far but there are some interesting tutorials made by Grey in addition to the basics ones I wrote. It's something we should work on in the future.
Also you can find all the internal properties in CreationTemplate.ini and SettingsTemplate.ini files which are both part of orx's distribution. I trust most of the parameter names to be self explanatory, but if you find some obscure ones I'd be happy to give more explanations.
A couple of months ago, a new comer named Blarg discovered orx and mastered all of its aspects very fast, even without being a programmer at the beginning. So I thought the tutorials were extensive enough, but I was wrong and we'll still work on a better doc/communication.
But without much feedback it's hard to know which parts are hard to learn.
As for an editor, since the beginning it's something we'd like to have. Unfortunately, it's something I'll never do myself (I *hate* writing GUI code) and I hope, one day, to see one made by the community.
Eyecreate's Pey editor might even be the base for a more complete editor and I'm looking forward to see the next improvements to it.
As a programmer,I am more familiar with getting everything done with code than setting.
I perfectly understand this point of view. However, as a programmer too, I'd rather have things that can be automated made by a program/engine than having to write it myself. I'm lazy that way.
If we take the example of Cocos2D, I found these tutorials:
monoclestudios.com/cocos2d_whitepaper.html
Maybe they aren't as tight as they could have been but I find all the steps to setup and handle resources very tedious.
Again it's only a personal feeling and I know a lot of programmers who like writing verbose code and stay in control of everything, line by line. It's just not the philosophy we wanted to have behind orx.
That being said, I like the scene feature in Cocos2D, but even this feature can be done very easily in orx with one object for the scene (and children) + a orxFX for transitions. Setting a lifetime on your root object will then free all the resources used by all its children (physics, sound, sprites, ...).
As for tile maps, Scroll adds a map concept on top of orx. It's also written in C++ and allows very easy callback notifications for all your game objects (Scroll is written in templated C++).
In addition to that, the level editor can be embedded in your game application and allows you to run your game directly from the editing view. It's still in early stage and lacks features, but I think it'll help people with a need for tile-based or object-based levels.
Getting the program into device/simulator is a very time wasting process.It make things worse.Even I change a little setting,I have to wait too mush time to watch the result.....Not like in Windows.
Why not running orx on your windows then? Instead than the iPhone version? Orx runs on windows, linux and Mac OS X. Your result will be the same than running your program in your simulator and would be more faster. But if I read correctly further in your post, that's probably what you think of doing.
Just out of curiosity, how would you have a faster code/test loop using Cocos2D?
The only thing preventing you from recompiling/restarting your app would be scripting support, I presume that's what you lack in orx and you like on Cocos2D?
In addition,ini setting is antediluvian，even orx make so many expand for it.
But the base funtion,Setting a value with some operation on another key's value,is impossible.
like We can do something like below:
[Camera]
FrustumWidth = @Display.ScreenWidth
FrustumHeight = @Display.ScreenHeight
but we can't do something like below:
[Camera]
FrustumWidth = @Display.ScreenWidth / 2
FrustumHeight = @Display.ScreenHeight / 2
Actually, this issue isn't a INI issue. It's more the way data are interpreted inside of orx. If you get the raw value in orx, using orxConfig_GetRawValue, you'll get the exact string: @Display.ScreenWidth / 2. You could then interpret it the way you want. It's just that orx doesn't know how to process arithmetic expression so far, but it's something I've been thinking of adding in the future as I too would like to use things like this.
However, it's not tied to the INI format, the same issue would arise with XML or JSON files.
What I personnally like with the INI format is that it's very simple and not verbose at all. I dislike XML because of its verbosity. Of course, using XML editors hide this issue. Hopefully so will do Pey for orx's config files.
That make the setting is less useful......
Less useful, that's true, but still more useful than nothing. If you have to do it in code, when you want to change it, you have to recompile, and when you want to refer to it for another part of your code, you either use a shared static const/define or an extra variable, and again it has to be maintained in code in opposition to a single line in a text file.
If someone is very fimilar with orx,orx could be great,especial for it's portable.One can develop in windows and run it on IPhone.I am in the way to that.
But Portability is also the weak point of orx.It can't be special design for IPhone like cocos2d for Iphone does.Like the DeviceOrientationPortrait and DeviceOrientationLandscape things.......
You're definitely right. Orx can't be too specific as it has to maintain most of the features across all supported platforms.
However, some platform-specific features, such as the accelerometer, are supported, even in config files (like the update frequency of the accelerometer that will only be used on iPhone). If you want to use the device orientation, it's not something specific to Cocos2D, it's something part of Apple's iPhone SDK and you can also use it with orx if you feel like it.
You have access to the ApplicationDelegate in orx, and you can write code as you would do with having to go through orx.
I didn't do this bridge (for the device orientation) as I'd rather use the camera concept + rotation, this way my world simulation doesn't care about how I plan to use the device + my UI can be adapted to a different aspect ratio very easily (no lines of code required).
I recently did that for an iPhone port of the Drops prototype where I didn't change a single line of code in the program, but by playing with the config files, I could easily have the whole UI adapt to a landscape or a portrait setting. And to do that, I didn't have either to update all the buttons, simply change the UICamera setting (rotation + frustum): all the buttons were scaled and positionned to fit the new orientation.
Just the view point from me,who just be interested in IPhone.
Even if things aren't perfect yet, even for developping for only one platform, such as the iPhone, I think orx is worth it.
But again, it's because I like the way things are handled and that I don't need much code to manage resources.
We'll continue to improve orx so as to support new features for our users, and make it more and more user friendly, but that's a long process and we need feedback for it.
