Hi everyone,
It's good to be here again. A year ago I entered a relatively new, growing a haxe community. I have learned a lot in the process, about gamedev from a different perspective and met a game jam focused community. I was particularly using HaxeFlixel, which is Haxe port of as3 flixel but many stuffs were done better than the original. Now I will share what I loved most about Haxe specially haxeflixel.
Pros:
1. Easiest to jump into. Installing and configuring HaxeFlixel was a breeze. You setup once then its easy to pull latest source or changes. It automatically compiles flixel source the first time you build the project.
2. Cross platform development is a breeze. With Haxe you need to configure once, for cpp if visual studio is installed, then its already added in the path, same with mac/ios dev, for android only first time you provide path of android SDK, ndk,jdk and ant tool. After that don't bother. Also compiling for a different platform is just changing a parameter while building. For example the command from project dir,
"Haxe run windows" builds for windows and
"Haxe run android/ios/mac/linux/html5"
Builds and run for that specific platform. It also generates project files so you can use IDE too. Of course you have to provide some config info for each platform. That's it. Even faster than unity3d.
3. Starting a new project is super easy, haxeflixel has some command tools to generate a simple bare bone hello world project, like
flixel tpl -n "HelloWorld"
creates a new project, so starting a new project is as simple as that. You can also config which IDE project files you want to generate, so that's convenient too.
4. Quick development even without a drag n drop editor, I hate dnd dev for some reason. Mainly because I am a programmer, not a good one though. There are many flixel tutorial (community driven) which covers many topics which helps rapid development.
5. Support of wide variety of tile map editors and spritesheet tool or animation tool like spine/spriter. Nowadays, it is hard to find someone who does not know about texture packing or other tools like it. Also many new devs use some sort of tile editors like ogomo, dame, mappy, tiled (my fav) or at least CSV file, also auto-tiling feature I am sure you guys are familiar with. Which lays solid foundation to make platformer, roguelike, or tile based rpg games.
6. Sprite animation is very easy to create and play, as you can load animation from image, providing framesize, and index. Also you can load from texturepacker or other tools, providing anim names. I find this method easier than even unity's way of handling animations.
7. Has web target which makes easier in game jams, so that your game gets maximum exposure. Many people can try your game. Though haxeflixels flash target is solid, but html5 target is not that powerful.
Everything has it's cons, so in short I will mention things I did not like or missed in haxeflixel
Cons:
1. Fully state/scene based object management. First you need to create a state, then add everything to that state, once you destroy the state or change the state everything gets destroyed. But there is no way to manage inter-state object, you want to keep same object between states, you are out of luck. You have to create every single object in every state you use.
2. No per object/sprite/camera shader support at all. I am a shader noob, but you can't even add simple filters to your objects in native target. Also no render to texture, you want to add some decal effect to your sprites, you have to go with set/get pixel method., which is damn slow.
3. Managing a parent child system, or a composite sprite is a PITA. Not very efficient. No object anchor or pivot point. Pivot or anchor point only works for rotation or scaling.
4. Very basic physics system, only rectangular collision response system, no circular, polygonal collision out of the box. For full physics you need to use nape, but that's not integrated deeply in the engine, also I am much more familiar and comfortable with box2d, that's why I did not bother using nape.
4. Performance, flixel is not well optimized, I could only run 6K bunnies (orx equivalent objects) in flixel where I got 14K orx object. Also no real particle system, or animated particles, and you can't use too many particles, because particles are also treated as individual object in flixel. Even a particle just extends Sprite, which makes things worse as flixel's Sprite is a bloated class, full unwanted functionalites and variables.
I could probably add some more pros/cons, but these are the things I felt important, if I recall something important later will add.
Now, what could be done to make orx more friendly and appealing to new users? I am going to present some proposals, that I gathered from my experience, to make orx user friendly. Few things I mentioned to iarwain in pm, will also state here to address the issues.
Here they are:
1. Orx is not object oriented friendly, as most of the people are familiar with some sort of OO language, including myself, we find C way of doing thing tedious. Like, if you have a sprite, then we assume, there must be, sprite.setPosition() or such sort of methods, not Object_setPostion(object).
Solution: Making scroll more powerful, useful and default way of dealing with orx.
2. Starting a new project is a pain. Right now the way orx handle projects and platforms is very hostile. We have binary for different platforms separately, which is a real turn off for multi-platform development.
Solution: Introducing a simple command based project building tools like flixel, even cocos2dx uses python script to generate new project which includes all platforms, also building for each platform could be done with python scripts. It’s project structure is something like this.
Root__
|-- Classes (Game source files)
|-- Resource (Game data files)
|-- Engine_Src/libs (which will contain libs for all platforms seperately)
|-- Proj_win32_VS (VS project files)
|-- Proj_win32_mingw (mingw project files)
|-- Proj_linux (linux project files)
|-- Proj_ios_mac (xcode project files)
|-- Proj_android (android project files)
I am not saying orx project structure should be like this, but my point is it should contain build files for all the platforms. And creating new project should be hassle free. Building a sample project should be easier.
3. Lack of proper documentation. Once we get a hello world orx project up and running easily, while building it for couple of platforms, then move onto learn about orx. But how you do that? Wiki or tutorial. Sadly, orx wiki is a mess, I am not talking about tutorials but how orx handles stuffs, and important aspects of the engine. For reference we could look into haxeflixel and cocos2d-x documents.
Haxeflixel:
http://haxeflixel.com/documentation/
Cocos2d-x:
http://www.cocos2d-x.org/wiki/Cocos2d-x
We should make wiki such that a new user could easily grasp what orx is about. I am not suggesting exact wiki format like above, but more informative, and more about what to do than how to do.
After a user has basic understanding of orx, like oh I need to define object properties in a config file, then load config from code. Then comes playing animation, or load a level files (some sort of), do some collision check, input and UI.
4. I talked with iarwain about tile map support and simpler animation loading directly from texture packer like tools, so I will be skipping this for now.
5. Another major drawback of orx is no document about UI. Or no basic UI support in orx by default like a simple button, or 9 patch sprite/button, labels, text field, slider etc. I hate doing UI, especially when there is none. Every game needs some sort of UI, and we cant ignore that. I can see there is a button tutorial in wiki but it is frightening. You have to do so much just for a button, that's a big turn off for me, and for new users. People want to create button like this, either
Button button = new Button(…) or
Button button = CreateFromConfig("MyButton")
then assign a callback method like,
button.setCallback(…)
6. Some higher level helper functions would be like icing on the sugar. Like camera follow, camera/screen shake, screen fade in/out, screen flashing, timer or callback function etc.
7. A web build would be much appreciated, it would be ok if it is just as a proof of concept, to show orx functionality interactively. This would also attract game compo guys. I hope, next year, we will see orx running in browser
So, these are the points I could come up with now. 6,7 are least important to me though. You can also add your own opinion of how to make orx friendlier and easier to new user. I hope this will just be the start of a reform revolution that orx badly needs, and as a result we hope to get a more users, developers and contributors
Some of the things I mentioned above could be just my personal opinions, feel free to correct me. Above proposals are open to discussion, nothing is absolute.
Thanks and cheers!
Comments
1.(OOP) I've been building many object-oriented layers on top of orx, and I'm planning to merge some of them back to scroll and others as a library on top of scroll. I think orxObject_SetPosition is not the worst example, and it's actually quite tolerable. Much worse are things like orxObject_CreateNeighborList. There are also other possible improvements, such as enabling for(child: children(object){...} in C++11.
2.(Starting a project) I've my own caconical initial project setup that I'm planning to extract as a bare repo. It's CMake based and targets Desktop and Android conveniently and consistently. I'll include iOS there as soon as I build for iOS. People can fork it(privately) and build on it. One bonus of this would be that people can merge any future improvements to the base setup.
7. I've also made some promises here and I'm still willing, but it's a bit lower in my TODO list.
I would like to add another item of my own to this list. I think orx is also lacking a convenient way for people to share not only assets and tutorials, but also code. It should be just as easy as sharing, say, a widget in Unity.
For this purpose, I've been evaluating bii-code for a while. I think bii-code + CMake might just be the silver bullet for jim's item 2 and my additional item.
1. (OOP) Yep, set position example is not the worst, but my point is introducing OO way. Also many C++ users are now taking advantage of C++ features like smart pointers, auto, lamda, thread in some cases which not useable in orx atm. But if you give Scroll its power, we certainly can take full benefits of OOP.
2. Whatever we use, cmake, premake or other build tool, my point is to make it user friendly, hopefully with a couple of commands or batch files, like flixel. New people are not used to directly working with a build platform, of course experience people can, but if we want to target a C++ noob, we got to go the noob way, hiding our build complications by providing few batch or script file.
Also we can have a template project, which will include all the build targets. And like flixel it would just change the project name, and a few parameter, then copy to it to new project directory, This way, new users wont have to deal with a build tool directly.
Sorry, I totally missed what you meant by that.
We have a fantastic engine, that in so many respects is heads and shoulders over many others. Trouble is, we are on the outer regions of the internet, and not many people find us. And when they do, we haven't done a great job of selling it.
That's not to say progress hasn't been made in the last 12 months.
We have two editors in progress by the guys.
We have tutorial sections in the wiki being reorganised and improved, but much much more work there needs doing.
I am working on a beginners tutorial series that covers building orx for all platforms, then beginning a project and writing a simple game from scratch.
These sorts of things will certainly improve the current uptake of orx. And I do feel many of us are chipping away at the edges. We'll meet in the middle eventually.
With the building of projects easily, thankfully things have improved tremendously since the introduction of premake, which makes it so much easier to build for any platform or IDE from the commandline.
But yes, it would be good to abstract that behind command scripts to make the process seamless.
Lastly a point to beginners reading this: sometimes those with the lesser experience are in a better position to provide good walkthroughs and tutorials to the community, because they understand the detail needed by other beginners. Experts tend to gloss over the minor (important!) details that can be vital for documentation.
In an ideal world, integrating my UI infrastructure into your game should be as easy as writing (in a project definition somewhere): And my ui stuff should be magically downloaded, added to your include path, built along with your project for all of orx's targets and packaged including the .ini files that it brings.
If we further make it easy to prepare such libraries, we could see an explosion in collaboration among orx users.
Now, as I said this is a general problem in C/C++ and biicode+CMake seems to be a solution for it. We just need to prepare a workflow for orx based on them.
But it is generally a C++ issue. What we can do is to maintain a general structure when we make a lib for others to use,
Src (Your source file)
Assets (Contains assets and ini files)
Build (Contains build info)
Libs (Other static/dynamic libs if required)
Your_Lib.ini (Not sure what it would do)
Then we can include the lib in config, this way assets and configs will be available to orx Even then we need to manually include source,libs and build config to our project. I don't know if there is a way to automate this process, just by adding in a build file where to look for additional src, libs, and build config. I am not much knowledgeable in this matter. Lets wait for iarwain, what he has to say about this.
Sorry also for my late answer!
Ok, let's try to tackle all those points in order. First regarding what you like on Haxe/Flixel.
1. There are definitely things to improve there. However, regarding the setup once then pull latest changes, it's kind of already the case. The steps are:
- clone the hg repository
- build orx (single click or command line, depending on your choice of environment)
What could be improved is that all the dependencies would be fetched/compiled automatically instead of being binaries stored inside the hg repo.
2. I guess adding orx to the path of visual studio could be something that some people would like. However, for me, as a user, I hate when things like that are done in my back. But again, I'm not the target demographic here, I guess.
Cross-compiling is a bit more touchy, but that's due to the nature of C/C++. We'd need to investigate potential options. However, it wouldn't be doable to OSX/iOS, I believe, as Apple doesn't allow it.
What is already there if the project file generation:
- premake4 vs2012
- premake4 xcode4
- premake4 codelite
etc...
3. That's definitely something we should be doing. I'm using my own template based on the tutorial, but that should be easier for newcomers I guess. The decision was to let people do their own setup though, as more advanced developer usually like to keep control over the way their project are organized, but we'd still be able to provide default templates.
4. More tutorials? That can never hurt. I can only help on advanced features though: as sausage pointed out, I'm too use with C development and orx to be able to see which points are important to mention and which ones are trivial, if any.
5. We can discuss about a different approach than the current exporters we had so far if that can help. I don't think I can be of much help here either, sorry.
6. This is coming in, pretty soon! Believe me, that hurts me as much as anyone else. The current design was made 8 years ago when an editor was supposed to be developed alongside the engine. As that never happened, we're left with extra verbose animation declaration. We already discussed improvements here a couple of months ago and I'll submit a proposal in the coming months (weeks?). That point should be addressed before orx 1.7, I'm positive about that.
7. We already discussed that earlier this year with Enobayram. It's mostly a matter of finding time to do that. It's not high on my todo list either as the game I'm currently working on is more of a steam-commercial kind of game, but I'll be happy to lend a hand if someone started to tackle this. Mostly the threading system should need to have a switch in order to be able to run mono-threaded.
Let's now talk about your proposals:
1. Orx actually is object-oriented. All the functions you use refer to a structure that is given as a first parameter. There are no function that isn't linked to a module in such a way. It's object-oriented.
What you mean is that the syntax doesn't look like C++ & co. And that's true. But there's a direct 1:1 correspondance between and
I agree that the second one is not as pretty nor as nice to type. What can be done is adding a set of wrappers, easier automatically generated or handcrafted, for C++ and co. We talked about SWIG earlier, but it can also be achieved with more simple system. One example is what Sol made for his sound library, SoLoud: http://sol.gfxile.net/soloud/
Which I'm totally going to use as a plugin at some point in the future, btw.
2. As orx is natively compiled, we'll hit some limitations on the cross-platform side of it. That being said, things can be done, as pointed out by Enobayram. We could even start as simple as templates (and make it obvious they are templates, like the iOS and Android demo that some people might not have noticed).
3. I think sausage made a nice work when he re-shaped the tutorial part of the wiki (http://orx-project.org/wiki/en/orx/tutorials/by-subject). Have you had a look at it since? Things can always be improved, but I don't feel it's such in a bad state. Maybe a bit dry, but I have such a terrible visual design sense that I wouldn't know. Again, I'm not the target demographic and I'm ok with any improvement there.
4. Yup, simple animation are nigh, I promise.
5. Well, I guess I could make some helper functions if people really want those. However my point is that a good UI is a UI that does not exist. I think UI framework are all bad and that UI shouldn't be done the way it is, at least for game development. A button isn't something that is intrinsically different from another object, it's just a concept and shouldn't have dedicated code, if you ask me. Also the way things are usually done prevents any easy rebinds, triggering actions programmatically or through other means that simply clicking the button, etc. As examples, there's no UI class or dedicated code in orx, Scroll or Little Cells. Even so, Scroll has a GUI that can fully interacted using the mouse and the keyboard, orx has an interactive console and Little Cells has text displays, animated buttons, state toggles (sound on/off, music on/off, fullscreen/window, ...) and it's all just data, not a single dedicated line of code for that.
6. Sure, why not, but those are one-liner wrappers around things that are already one liners. Again, I'm not against adding helper functions, but I feel they'd just clutter the interface without bringing any real feature. Regarding timers and callbacks, they're already there, you can find them in the Clock module.
Screen fade-ins/outs are a simple quad with an FX, all in data, camera follow -> orxObject_SetParent(camera), camera shake -> FX on an object that's parent of a camera, ... But again, some helpers could make sense and I'd be happy to add them. Like text helpers (text justification, alignment, etc...)
7. Yep, would be nice, we just need someone to work on that. It's definitely not high on my todo list as it's not useful for any of my own projects, but I'd be happy to help as mentioned earlier.
Also, I think Enobayram's point about distributing code/data is very valid and we already had a short discussion about it earlier this year. I'd love to see that addressed. We can talk about it on orx-dev if you feel like it. Automated package retrieval/installation would be a must for sharing.
So all in all, I think those are pretty good points and all need further discussions/proposals. Thanks again for starting it!
1. (Regarding setup) As flixel has no binary inside their repo, this makes the repo smaller in size, and if I mess up anything, I can do a fresh clone.
Regarding dependencies, as we already have dependency sources inside the repo, I think there is no need to store binaries instead they could be compiled automatically while building orx. They can also be fetched with a script.
2. (Building project) That's a haxe issue, as it does everything for you, and I normally don't care if in the end it does the job.
I would really like to have to build for other platform with a command, like if I am building for windows/mac I would like to add a post command to build for android/ios too. But that's a different thing I guess.
Even in flixel you have to be in linux/mac to build for that platform.
3. (Project template) As we are targeting new (C++) users providing a simple template project would do no harm imo.
5. (External tool support) Current exporters adds another layer of work, for spritesheets that may not be too much, but for tile maps, making each tile a single object is too much overkill.
Now, regarding my proposals
1. I am all for making a wrapper around C, because not all C++ devs know how C works, that's the sad truth. In my case though I started with C so, not a problem for me.
2. Yes we need a template project for sake of simplicity, other day I was looking into how oxygen http://oxygine.org/ handles stuffs and to my surprise they too maintain a similar project structure like cocos2dx and they too generate template project with a python script.
3. I saw the new wiki, but I to be honest it does not help much. It already assumes the reader has knowledge of what is orx or how in operates. Also the fact that it is listed in alphabetical order instead of order of importance, it is confusing. So, this needs more discussion.
4. Okay
5. Not needing a full scale UI, but if you have 3 days making a game, for a jam or competition you dont want to roll your own basic UI. Also a seamless input system for mouse/touch/gamepad also makes things easier.
6. Yes, actually somethings are done quite easily in orx. Instead we can have orx cheat sheet in the wiki describing how easy its to do some stuffs. Which will contain simple snippets of such things. I am not sure if clock is fit for just doing something once in a while. I see clock as always updating function. Also, I see no way of registering a class member function with clock without making it a static. I tried once but didn't make it work. As I mentioned these are not that important for now.
7. Yes, not a must have feat. But kinda cool to have
Of course, quick n easy code distribution should be discussed too. All of them need further discussion but before that we have to prioritize what should be discussed and done first.
I think this is turning out to be a very fruitful discussion.
As I've mentioned, I've been planning to release a canonical project template/base repo for a long time, but now that this topic is hot, I think I'm going to look immediately into it. For reasons, I work on game related stuff in 5-6 day bursts, and I think I'm going to dedicate the next burst (starting from tomorrow) to this.
I think the template project (which I don't like to think of it as a template) is crucial to this discussion, as most of the points are actually about sharing code. All the OOP stuff and UI stuff, they could be nicely solved with packages. For instance, a screen fade-in FX is very easy thing to do in orx, but it's not nice to tell beginners to copy/paste code, so instead, we could have sort of a utility package that comes with nice little gimmicks like that.
I've explained my intentions in detail here on orx-dev, and I don't want to hijack this topic, so please take a look and feel free (even encouraged! ) to give me some feedback.
1. We actually don't have the sources of the dependencies in the main repo anymore. They've been moved to external repositories to ease the downstream integration process. You can see them at https://bitbucket.org/orx/LiquidFun
https://bitbucket.org/orx/openal-soft
https://bitbucket.org/orx/freetype
https://bitbucket.org/orx/libgwebp
https://bitbucket.org/orx/GLFW
https://bitbucket.org/orx/premake-stable
https://bitbucket.org/orx/Box2D
Also they all have different build systems. Even worst, some need more than a single step to configure and build and some manual changes are needed between some of those steps. We'd need to write a script to cover all those, which would be great in the end but is not a trivial task, unfortunately.
2. Ah I see. Cross-compiling refers to compiling for one OS from a different one, not being able to compile on two different OSes, which is multi-platform support.
3. I'm all fine with that. I actually posted my own Scroll-based template on orx-dev.
5. Valid point, however an exporter could come bundled with a runtime part. In the best of worlds, they'd both be part of a package that one could retrieve automatically with the equivalent of "go get <package>", but orx-style.
1. I have hard time to fathom that part. C++ is a superset of C, if you know C++, you know C. There's nothing new in C compared to C++.
2. This to me looks actually more complexe than a single entry point such as "premake4 <platform". There are 5 python scripts and what their use are is unknown to me.
3. Don't hesitate to contribute to it. If you do not have write access, lemme know and I'll give them to you. Sausage has been our biggest contributor wiki-wise and I'm sure he'd be happy to have some help on this side. There's a fine line between making engine-specific tutorials and general-purpose game development ones. The second don't really belong in our wiki but are often to be found on other game engines' site.
5. My point was that one doesn't have to roll *any* UI at all. Regarding inputs, they're already there, or did I miss something?
6. Clocks are meant for doing things once in a while as much as doing things every single tick. Otherwise there wouldn't be any timer function in them. The interactive console is based on such timers, for example.
Regarding callbacks, you can't unfortunately use non-static methods as those do no exist in C. You'll need to wrap them yourself and I'm afraid there's no work around at orx-level due to language restrictions.
1. I see but binaries are still stored in the repo.
2. Technically you can cross-compile in haxeflixel by targeting neko, which runs in a VM but it isn't efficient.
3. Gotta look into it.
5. That sounds like a good idea. But not sure if it would worth it in the end.
1. Actual difference is functional vs object oriented programming, struct with functions vs class, C functions vs static functions. Also not every C++ devs started with C or C++, many comes from java/C# background would hardly know about some nuances of C Updating every object from a single functions with is not every OO programer dreams of.
2. Well I shouldn't have posted that screenshot, users only need gen_template.py which generates project template for specific platforms or all. And my point is, users dont need to know what premake is, and afaik orx needs a modified version of premake, which then needs to be in the system path or in that folder.
3. Sure, but before that we need a layout, how things should be organized.
5. Well, just tell me how many lines of config and C code is required for a button http://orx-project.org/wiki/en/orx/tutorials/community/tdomhan/mouse-over-effect I am not telling the code is huge, but for a new comer this is. We can always wrap such code in a helper class though. Also I could not find any info on wiki about multi platform input or multi-touch.
6. I see, but how many clock can there be? Can they be created and destroyed automatically when times up. I have to look into it more.
I'll do quote replies from now on, I think it should be easier to follow.
Yep, and that's what we want to remove, but for that we need to have all the dependencies setup in some sort of build system/script.
I see.
Well, that would be part of the packaging system that is being discussed as well, not a separate concept.
Well you still need to make the calls somewhere. But yes, I was only addressing C/C++ not the other languages.
I understand. Orx does need its own premake, that's true, but project games can use a vanilla one. It's only to handle some complexities of orx that I had to patch premake. That being said, premake is inside orx's hg repository. Do you think I should add it to the binary packages as well?
Sure.
Err, actually I wouldn't do it like this at all. That was Tobias way of doing it, I can't say I really agree with it.
Well, one should only create as many clocks as different frequencies are needed. If you don't need to have a specific frequency, just use the main clock (orxClock_AddGlobalTimer()). You can add as many timers as you want.