Just to be clear...I have no problems with anyone. I'm here to do a job that was left to me by Andy and try to fulfill his design and promise to the best of my ability. That being said...
People like Paradoxnj, QOD, Jay, Juutis, Terry, myself and others are doing what we do because we enjoy doing it, it is our hobby.
That would be one hell of a team and would move this along much quicker. The total experience would be enough to make a killer product. I have a base, we can all discuss the design and change it if needed and I would definitely let QoD run the project as I hate project management.
@ pardoxnj Sorry if it appears this way but I am not getting at you at all. We are doing what we are doing because it suits us that's all. We had put a lot of work into it and didn't want to waste what we had done so decided to carry on.
I think you misunderstood the phrase "You didn't like what we had done". I'm afraid it's an old Yorkshire idiom. It means it doesn't suit your purpose.
Bernie, you are correct...I took it as a literal statement. I asked Terry to develop an editor for RF2. I told him there is a design. I also told him to use the same Subversion repository as RF2 to keep it tightly integrated. No sooner than I finished typing, I see a post about an editor and a separate Subversion repository. I never sent any designs, nor did I suggest a separate project. To me...this looked like there was never an intention to develop as a team but to develop as separate entities. The one issue I see with RF is that there are too many options. There are at least 4 world editors, 2 ini editors, multiple script editors, various texture tools, etc. My design is making one tool for everything (or at least one GUI).
Andy spent a good part of 1.5 years designing this. When I joined...I told him I would follow the design and discuss with him any changes. The only change i've made from his original design is using Squirrel instead of Python.
So the procedure will be easier for the user they run the game then if they want to alter something they run Game Director alter the part they want visually then save re run the game and it’s done.
No scripting involved.
Later things can get more involved but for now I think that’s the best way forward for all concerned we will carry on me and Bernie developing. We are dong particles next and there’s nothing stopping us from creating a nut file for them with the parameters in it needs to run then you take and interface to RF2 so it’s a 2 way street we will take what you have and as we develop you take what we can give to you and you interface.
This way I think will be better for the community.
You are talking about changing properties of objects. That is not very flexible. What about the more advanced users. They are the ones who seem to stick around the longest (Juutis, Jay, Allanon, you, Bernie, etc). So...it's better for the new people, but not the more experienced people who have to wait until you integrate that functionality.
Like the C4 Engine's Graphical Scripting Language?
Allanon, yes...I was using Torchlight as the example, but it's the same as C4.
If you can complete the basic functionality (e.g. you said collision detection is still missing) then I would release it. Just make clear that it's not a finished product and not suitable for beginners at this stage (limited support as well).
That makes sense. Make sure all the basics are there and build from there.
That being said, someone of course must take the lead, make decisions and keep track of the overall plan. Due to his experience Anthony is qualified for this job.
Wow!! Thanks.
Let's take the scripting for example. From my experience with RF, people always want to have more control over the gameplay than you can provide with hard coded features that are influenced by a limited amount of options.
Exactly. I have been hanging around the forums long enough to have seen what people do. At first, they mess around with ini files to get their own stuff in there. Next they want to start making it do things (scripting). All I did there, was combine the INI files with the scripts so that the users would use the scripting language to define data at first, then apply logic.
If on the other hand you create a flexible design right from the start, it may be more complicated for beginners to use at first. In this case you can a) provide sample scripts and b) almost always come up with a tool that simplifies the process. This might take longer than the first way but will lead to a better result in the end.
Exactly the approach I'm taking. The only difference is I was planning for the editor to be the only tool. I would give the users ability to create plugins to make their own tools. The game shell would handle everything and the editor would be a GUI to the game shell, just like Jet3D. The editor's interface to the engine was the most powerful feature of Jet3D.
IMHO, the game is more important than the editor. If you can edit stuff, but the shell doesn't work correctly...you're product effectively sucks. More importantly, the shell defines what data you need to edit.
Here is what I propose. Everyone has their strong points...GUI development is not mine. I would prefer to keep developing the shell instead of worrying about an editor. Bernie/Terry, I would like to ask you guys to develop the editor based on the RF2 code. Please do not assume that something is not right. Please talk to me about it via email, PM, AIM or MSN. I'd be more than happy to accommodate any needs that you may have including working on something that I consider done. Integrating with your existing GUI is ok...the only thing I ask is that the editor be RF2 specific and work based on the RF2 code.
If you guys are not willing to do that, I am ok with it. I will just start an editor using wxWindows or MFC and work slowly at it or make something using CEGUI to get people going.