It looks like you're new here. If you want to get involved, click one of these buttons!
I'm going to develop a platform game with graphics and sounds in 8-bit style. I followed the official tutorials carefully but I have some doubts:
I want to create a main menu that triggers a transaction effect when the user presses start (or About, Options).
Creating layers is not a problem, I already have all the resources (graphics and sounds). The problem is organizing all the levels in the project. Orx Engine generates the project by creating a .cpp file and config.ini file to define the main features of the game. I would like to organize the project by creating new config modules related to each level. The structure of a platform game is identical for each level except for special cases (boos fight, opening, ending game, credits and more). The .ini modules related to game levels are the original ones of the project (reusable code for all levels of course). For different scenes (opening, boss fight, ending, credits), I create new .ini modules with this name and define each new module in the .cpp file inside a function, and this is easy.
If the project gets big enough, is it possible to distribute C++ code in multiple modules? theoretically yes! Orx uses a simplified form of C++ but it is still C++ standard, so it is sufficient to create a new .cpp file, import the new modules as if they were "#include new_module.cpp" libraries and write the functions to call up the modules. ini that I have created.
The replacement of the .ini modules with python modules would be very nice. Python is very simple, it has many libraries useful for managing cryptography and 2d graphics.
Keep the structure of the config.ini modules unaltered but using Python would be really interesting. Python is an interpreted language, it's not fast, it's true, but to make 2D games in 2018 with cheap computers that have more than enough computing skills to handle sprites, I do not think it's a bad idea.
Obviously it's just my personal opinion, maybe it can be a good idea to easily extend the engine and implement new features in a more simple and invasive way.
Creating a small Tiled style editor that allows you to draw layers and generate the primary code of the game template would be useful. Alternatively, I take notes on how to solve some things. I'm experimenting with some solutions, as soon as I have public news screenshots and clearer technical details on my small project. Thank you all.
Let's see if I can address your questions.
I guess you meant
transition. Well, it really all depends on what kind of transitions you want but the
orxFXsystem might help you there. Usually scenes in orx are just common objects with children and can be handled like any other object. You can apply FXs to them as well as tracks (see timelines in the wiki).
FXs are combinations of curves that you can apply to one or more object properties, such as color, position, scale, etc...
Tracks are timed sequences of command. For example you can say that your object moves to the right at Time=0.2, then gets deleted at Time=1.2 with a track that looks like:
I think we need to define more precisely what you mean by
modules. You do not need to always have one .cpp match one .ini although you're free to do it if it suits your needs.
Config files (.ini) can be organized the way you want, you can include as many or as little as you need, including taking advantage of the inheritance feature (which is very helpful in many cases). However they're just data. That data gets loaded into memory, where it can be retrieved and even modified at runtime (and even saved back to disk if need be).
Regarding the .cpp files, again you can organize your code the way you see fit. However you do not need to have one .cpp match one .ini. It's probably not going to be the case in most cases actually. Usually you'd organize your .cpp (code) files around features (like separating menu code from character code from game item code, etc...) while your .ini (config) files will just describe pieces of data, such as levels, for example.
But again, you're free to organize both the way you see fit, there's no restriction on that side.
Moduleisn't really a C++ term, so I'm not sure what you mean by distributing them. But yes, you can split your code into as many .cpp files as you want, generating separate libraries (which might be more trouble than benefits) or a single executable.
Maybe if you had an example I'd be able to have a better view of what you mean?
Well, they are two separate things: .ini are plain data while python modules are mainly code, which means your python modules would then rely on the data defined in the .ini files instead of replacing them.
You can use any language that interfaces with C, however we do not have readily available bindings at the time being for any languages. Some people like Python, others prefer Lua or AngelScript and some others, like me, don't really like any of the above.
Definitely. Quite a few years ago, there was some work to provide a generic interface for scripting languages, unfortunately that work was never completed and the contributor isn't active anymore so I retired that code about 10 years ago. There were also discussions about using SWIG to generate interface to the engine for different scripting languages but no concrete work was done on that side either.
There's actually a Tiled -> Orx map converter made by @sausage and also a built-in Tiled exporter made by @ainvar (for which I still need to provide the shaders for the shader-based map rendering method, sorry!...).
There were also a few different efforts of making level editors by the community but I do not think any of them are still actively maintained as we speak.
Thank you for your answer, you have been very clear. I apologize because my English is not the best!
To understand orx you need to experiment as much as possible, thanks to you I have some useful confirmations now!
I stay with C++. A wrapper with Lua or Python would be nice, but only if Orx receives real advantages.
I started creating my first real concept. A short public something concrete and release the sources, this can be very useful and can serve as a mini-tutorial.
Thanks so much.
No need to apologize about your English, many of us, myself included, are not native speakers and therefore write a more or less approximate English.
@iarwain thank you so much.
I found some errors in the wiki, I'm working to update the section for VS2017, fortunately I had the nice idea to experiment even under windows10, and compile with Visual Studio 2017 and mingw32 had errors.
I solved everything! now everything works perfectly, soon I update the wiki. Thank you.
Nice, thanks for the corrections!