Posted: Wed Jan 18, 2017 10:09 pm Post subject:
Questions and Answers
Questions and Answers
If you have any questions about RedAlert++, you are in the right place. There is a good chance that a similar question was previously asked and answered. If not, post your question, and we will answer it as soon as possible. QUICK_EDIT
OmniBlade deserves just as much credit, tomsons26 has also been a valuable asset to us, he is pretty much our only QA.
Deformat wrote:
What are the platforms you are willing to do this project for? (I guess Win/Mac/Linux, but is FreeBSD, for example, supported?)
We are currently building the project on Windows (32 and 64bit), Mac OSX and a few Linux distros, so far so good!
Deformat wrote:
Is RA++ going to support other sprite/image formats besides the ones already used in RA1?
It is very likely in the future that we will add support for other formats, but we have not discussed this yet.
Deformat wrote:
Are there any features from other CnC games that will be present?
We will be able to add any feature we wish once fully understand how a logic/feature works, but to ensure that we keep the core Red Alert machanics, anything added that affects gameplay will be disabled by default.
One feature I have taken from Tiberian Sun already is the mappable hotkeys! QUICK_EDIT
One thing I find strange about ORA's development is their insistence on adding all C&C/RA features simultaneously, but in doing so prevent choosing the particular game's style of mechanics. To me this seems very silly, since in my view, every function should have the option to customize similar to the game it came from, even if you added better/newer mechanics to it.
Like say you like RA1's homing projectile behaviour better than RA2's, there's no reason to omit control/customization options that would allow you to tailor it to whichever game you liked it from.
Rather than the cop-out "well it's better than the original!" or arguing about authenticity, it just needs more options.
So if you do add support across games, I'd recommend making all the low-level aspects configurable, not just the standard C&C/RA options like ROF but the mechanical character like:
LaggyTargeting=X to aim for where a unit was X frames ago
SpinDie=yes flitter off into space before exploding for Ranged weapons
CruiseHeight=X fly level like DredMissile at X height
Parabolic=yes attempt to mimic a guided ballistic shell
Ricochet=X allow shells that miss to bounce X cells random direction
And many other possible options for the core mechanics, which would please any modder, while allowing the original behaviour.
To make this stuff more centralized, you could even do it like XML/CSS where you define the specifics of a property, so rather than using the above explicit options within the weapon/projectile, you could have a generic FlightMechanic=Parabola and then a section where you can customize what Parabola's features are. This could save time coding, and you could pre-filter for any irrelevant/incompatible options? _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
One thing I find strange about ORA's development is their insistence on adding all C&C/RA features simultaneously, but in doing so prevent choosing the particular game's style of mechanics. To me this seems very silly, since in my view, every function should have the option to customize similar to the game it came from, even if you added better/newer mechanics to it.
I can not speak for OpenRA and its developers, so I won't. Any questions you have regarding OpenRA you can ask the developers directly on their IRC channel on Freenode, #openra
G-E wrote:
Like say you like RA1's homing projectile behaviour better than RA2's, there's no reason to omit control/customization options that would allow you to tailor it to whichever game you liked it from. Rather than the cop-out "well it's better than the original!" or arguing about authenticity, it just needs more options.
So if you do add support across games, I'd recommend making all the low-level aspects configurable, not just the standard C&C/RA options like ROF but the mechanical character like:
LaggyTargeting=X to aim for where a unit was X frames ago
SpinDie=yes flitter off into space before exploding for Ranged weapons
CruiseHeight=X fly level like DredMissile at X height
Parabolic=yes attempt to mimic a guided ballistic shell
Ricochet=X allow shells that miss to bounce X cells random direction
And many other possible options for the core mechanics, which would please any modder, while allowing the original behaviour.
To make this stuff more centralized, you could even do it like XML/CSS where you define the specifics of a property, so rather than using the above explicit options within the weapon/projectile, you could have a generic FlightMechanic=Parabola and then a section where you can customize what Parabola's features are. This could save time coding, and you could pre-filter for any irrelevant/incompatible options?
To be brief, we will not be concentrating on extending the core mechanics of the engine until quite some time after RA++ is a fully working engine. But once we are open source, you are free to fork the project add any new feature you wish.
In regards to changing the control system to XML or CSS like language; We are quite happy with how the game currently works using INI files, we are trying to make sure RA++ works exactly how Red Alert works, without any changes required. QUICK_EDIT
I understand, I didn't mean literally adopting a CSS format, merely the ability to customize tag behaviours which are then used normally, within the same ini structure.
Rather than having the mechanics invisible to the modder, a modder could tweak and customize the mechanics until they find what they feel is the closest approximation to the goal. This might also help you as a developer figure out what the ideal mechanics are for each movement or projectile by essentially crowd-sourcing it.
I understand, I didn't mean literally adopting a CSS format, merely the ability to customize tag behaviours which are then used normally, within the same ini structure.
Rather than having the mechanics invisible to the modder, a modder could tweak and customize the mechanics until they find what they feel is the closest approximation to the goal. This might also help you as a developer figure out what the ideal mechanics are for each movement or projectile by essentially crowd-sourcing it.
Un-hardcoding features, similar to how Tiberian Sun did? Then we are in the process of isolating and added these in. QUICK_EDIT
Why did you choose to not go the quick progress with playable version from day 1 by disassembling and replacing key functions one by one like https://openrct2.org/ and why did you decide to keep all source code secret. QUICK_EDIT
Why did you choose to not go the quick progress with playable version from day 1 by disassembling and replacing key functions one by one like https://openrct2.org/ and why did you decide to keep all source code secret.
1) The key reason why we can not do what OpenRCT2 and even OmniBlade's Thyme project does, is that the original Red Alert was compiled with the Watcom C++ compiler, and with some very early tests, it would be such a waste of time creating workarounds just to be able to hook in new functions. This is why we choice to start from scratch and then rewrite functions based on the research I have done over the past 7+ years and reimplement them directly.
2) My Obsessive compulsive disorder, to put it simply. The early codebase was very messy and full of temporary hacks. And as much as I support open source as a key foundation for projects like RA++, I also have pride in what I work on, and I wish to make sure the project I spring upon the public is clean, professional and easy to follow. QUICK_EDIT
When the time does come to open source the code, how do you plan on managing contributions? Will you allow the engine to evolve away from the internal structure of the original RA so that new features (incompatible with the original design) can be built on top of it, or would you prefer to restrict new features to things that can be implemented on top of the original design? QUICK_EDIT
When the time does come to open source the code, how do you plan on managing contributions?
For RA++, we will not be allowing contributions to the project, unless you are a designated developer.
We, as a team, have a very specific goal in mind, and we wish the project to fit this expectation. Now, I can not stop anyone from forking the project and extending the codebase/engine how they see fit, but the official RA++ repository will be locked to only the developers.
pchote wrote:
Will you allow the engine to evolve away from the internal structure of the original RA so that new features (incompatible with the original design) can be built on top of it, or would you prefer to restrict new features to things that can be implemented on top of the original design?
Our goal is to stick to our original design for the engine, for now. Like aforementioned, if someone wishes to add a new feature to the project, then they are freely available to fork the project and add what they wish.
There is a plan in the future to create some type of system where people can request a new system or interface to be implemented, but these additions will be at the modders discretion to enable. We want RA++ to work like Red Alert, mechanically, a complete binary replacement. QUICK_EDIT
Do you have a rough development timeline for RA++
Key features and release dates etc?
There are been no timeline internally, but I am working towards 3 main checkpoints:
1) Finish the game GUI system, ensure all gadgets work as intended. (about 50% done)
2) Game object communication and path finding. (about 75% done, we are mostly debugging, fixing bugs etc. now.)
3) Iron out out remaining bugs before we go fully public with the codebase and enter a state of alpha.)
Matthias M. wrote:
CCHyper wrote:
based on the research I have done over the past 7+ years
Have you published your research somewhere?
Most of the "understanding of the flow of the engine" is stored my head, of which I spent a good year explaining to OmniBlade while we worked on the core engine. The rest, of which are data structures and enumerations are mapped out in binary databases that are shared between myself and OmniBlade. RA++ will serve to be a final destination for all this information. Anything we discover will extensively be documented within our code, I won't be leaving anything out. QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
Questions and Answers
