RF is getting older fast and the frame rates will start to become a big issue when adding more complex physics etc... I'm therefor also considereing if we should not better swap to a newer engine, like ORGE and build a new RF-like shell around it.
ohhhhh yeah!
this is an RF2 announcement, Nout!
Yes, I think that the dev team is close enough to excercise the effort needed by a challenge so big.
Which are the steps? wrapping another render in the top of genesis (like ogre or illricht)? and the a new collision system? .. and then from scratch? or the way is the opposite? I'm with you, my captain!
Do you like my scripted player? Have you see the movies? I'm beginnig to put my hands in the code but some things are obscure for me. I thought that the best way was to change the player code instead of scripting a new one, but my script has an order for each action so I can easily change from an action to anther have a correct animation behaviour and having only an action active at time. I this kind of code transformable in source code for the player? how c++ can handle the orders? really I'm a c++ super novice, but I learn fast... sometimes probably you will have to help me...
I have a question about the new engine, if we switch to a new engine which parts of our old game libraries will still be compatible, scripts? Models? Levels? ECT...
Or will we have to start our games completely over again from scratch?
If we are going to switch engines I suggest that we try to follow something that will improve our graphic capabilities AND provide us with a well organized and easily managed workspace.
I have seen a few good engines out there and highly recommend the Unreal engine for its immense flexibility, I owned the original unreal tournament and have seen great potential in what could be done with its source, I however am not a very good programmer so I moved on to an engine that I could easily use.
I know that what we are working with now is a Quake based system which I never really understood why Quake was what was chosen, but now that we are talking about possibly changing that I would suggest anything closer to Half-life, counter strike, unreal tournament, secrete service, or Command and Conquer Renegade.
Half-life had support for surprisingly good graphics, good physics, cool weapons, good AI, moving mouths on talking characters, alt fire, weapon responsive environments(bullet holes in glass), and some awesome effects.
Half-life was also pretty easy to modify in any aspect of the game.
Counterstrike is basically a massive modification of Half-life.
Unreal tournament offers good graphics, Impressive AI, COMPLETE PAWN TO ATTRIBUTE INTERACTION, unlimited weapon slots, alt fire, respawning, COMPLETE SCRIPED WEAPON SYSTEMS, and I’ve seen some awesome modifications for it such as a grappling hook and players spawning friendly pawns.
Secrete service had good graphics, great physics including rag dolls, good AI, AI teammates, the ability to give orders to AI teammates, limited weapons carried, gear setup screen, and good multiplayer.
Command and Conquer Renegade had great graphics, tons of weapons, great AI, interactive 3D character information screens (pickup data disks), huge destroyable buildings with interactive + massive interiors, massive map size/detail support, moving mouths on talking characters, communication between pawns, great use of path point systems, pawns use cover to hide from sight of enemies, great multiplayer, money/resource based weapon purchase systems, the best vehicles in any game that will run on my computer (and there damn good vehicles to start with), vehicle physics, the ability to spawn vehicles at a "weapons factory or airstrip" that are purchased at the purchase screen, flying vehicles such as helicopters, reinforcements parachute in off of jets or repel down zip lines out of windows or off of transport helicopters, practice mode for botmatches at main menu, ect...
The list of features that could be added to reality factory goes on for just about forever doesn’t it. If we could at least find a way to incorporate the best parts of these games into the new engine we would have just about the best engine ever even heard of.
Nout wrote:RF is getting older fast and the frame rates will start to become a big issue when adding more complex physics etc... I'm therefor also considereing if we should not better swap to a newer engine, like ORGE and build a new RF-like shell around it.
I was holding off on this due to people getting their hopes up and then being disapointed if I didn't finish it, but you just described Artisan Studio. I have, for about 6 months, been planning, thinking, and designing a new version of reality factory, which I have called Reality Factory 080 Build Artisan. The name Artisan Studio came from the opposite of reality factory; originally it was Virtual Reality Studio, which would be the opposite of Reality Factory. However, Artisan Studio simply sounded better. Either way, I would gladly get together with Nout and anyone else who would like to help, compare notes, share code, etc. I will admit I did not get as far as you might think; I only solidly finished everything about the INI Editor except for file output (file input made it in). Let me say that I envision it as being as close to the original RF as possible, close enough to be known as simply a new version of RF. I believe we should discuss things such as language (C++ would be my guess), windowing api's(either win32, .net 2, or wxwidgets would be my guess), and 3d engine(irrlicht or ogre would be my guess). Keep in mind due to school and work, I may not be able to commit as much time as I would like, and it may be an on-again, off-again fashion. On a positive note, I am currently doing game tool programming professionally, so doing the tools for "RF 2" would be right up my alley. I say let's get started!
Are you saying that by changing engines we could get most of those things i wrote above working, or are you saying we should change engines because it would improve the graphic capibilities of Realit Factory.
What is the Torque Engine exactly, could you use it?
I would really like to help you with the development of the next RF but since I can't programm all I can really do is make sudjestions. and you probably don't need much more of that.
But if theres anything I can do to help, i will definitly give it a try.
thats ok,
take your time, I tend to be a little long winded in my posts because i try not to leave out details that may be helpfull to sombody who might know the solution to my problem or the answr to my question.
I have in the last few weeks learned a lot of the irrlicht engine, and all together a lot of c++.
Question your going to implant multiplayer correct?
I hope so.
Jonas
Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better. - John Carmack
im planning on it, and im considering working on prelimenary multiplayer testing soon on a simple test game. i plan on using raknet, at least until i discover something in it that frowns on rf development, at which point ill probably switch (if such a thing happens).
keep in mind itll be much easier if you know C++ the language before learning irrlicht, if you dont already. also, due to limitations in irrlicht (no moving normal-mapped actors, not very good skeletal animation, difficult ragdoll integration...), its my guess that rf will use ogre.
EDIT: By the way, that mapping comparison I posted a little while back was running on irrlicht using visual c++ 8(2005).
Theoretically I think it's possible to go in 2 ways and stay RF compatible:
1) Or we build a new RF around an existing engine
2) Or we keep RF and replace all calls to Genesis by calls to another engine
The first option sounds like the cleanest option that enables to optimal integrate all features, but it will cost quite some time and code to make a new RF shell
The second option is reusing parts of the RF shell, but for example the player and all related to collision detection have to be rewritten in RF.
Personaly I'm more in favour of option 1, but to keep full backward compatibility to RF will become a challenge + it will sacriface some speed and potential features
Some things will have to be done "the old way", while DX9 offers new methods to do some things faster but also in a different way
A third option is to take the best of RF and newer engins and group it, but keep maintaining to use .ACT files and re-create the scripting commands. This partly might conflict with physics, as also actor animation will need extensions to physiscs
A forth option is to wait till somebody else writes and easy to use shell around a new engine
What do you think?
Also important will be to define what engine to go for
OGRE is general seen as a good engine, but not that easy to code
IRRLICHT is general seen as a good engine, maybe not so complete as OGRE, but much easier to understand and code in
I was considering option 2 also, and decided against it and to go for option 1. I was thinking a complete re-write, but if we can get the old code to at least partly work ill be more than happy to keep it.
I don;t know whether I'm in favor of backwards compatibility - dont get me wrong, it would be great, but we would likely due to still using some of the file formats still be ion the shadow of the Genesis3D license. I'm not that good at legalities, so maybe someone can enlighten me? I'm thinking if we make a tool that can convert .3dt to the new format, then we would still technically be using something from Genesis3D and thus still have to show the logo and such. I could be wrong.
On the other hand, what would we gain from backwards-compatiobility? Sure, some games could be ported, but in the end, would it slow down development to the point where iot's not worth it, or would it save someone out there a year of work? It's a very hard decision. What do you think?
EDIT: I agree with Irrlicht being easier to use, but it lacks some features that even the current DX7 RF has (normal mapping on moving models, complete skeleton support, etc.). Do we really want to gamble on a faster development time with a -possibility- that these features may be added before we're done? Irrlicht does progress quite quickly. On the other hand, we COULD add the features ourselves - I'm not good enough at engine programming, I don't believe, to do it myself, buit I'm sure you are (the normal mapping problem lies within Irrlicht not re-calculating the tangents for each frame of animation).
We also have to discuss the windowing api (for the tools). I'll break it down:
WxWidgets: I don't know diddly about this, so I'll leave that for someone else to compare.
Win32: Huge cross-compiler support, tried-and-true development path, slightly difficult syntax.
.NET 2: Very low cropss-compiler support, EXTREMELY rapid development, easy syntax, but they are only offering visual studio 2005 free for one year, what happens if we make rf on .net 2, then microsoft drops support and starts making it pay-to-use? we're stuck back where we are with rf now, tied to one rapidly sinking yet still expensive compiler.
and you probably don't need much more of that.
