Release Question

[paradoxnj]

As some of you probably know, I have been working on RF2 by myself for the last 6 months or so. I've lost Andy to carpal tunnel and no one else has time to lend a hand. That being said...May 2010 is around the corner. I have a semi-releasable product...BUT...it is not beginner friendly. My question to the community is:

Should I clean up and release what I have as 0.1 or delay the release to make things more beginner friendly?

What I mean by "not beginner friendly" is the following:

-- There is no editor. Everything must be done by hand.
-- There is no world save format. Worlds are created through script.
-- Some basic functions are not there yet like collision detection and response, different types of cameras, etc...
-- I have not assembled a good toolset
-- There is no documentation

A more advanced user can play with the scripting and get something going but it's not going to do much. Again...keep in mind that I have only been on this project for 8 months and 6 of them have been by myself with only 1-2 hours a day to work on it and extended periods of time where job and family had to come first.

[zany_001]

Release it. I can't think of a reason not too. However, don't start an advertising campaign until it's more user-friendly.

Is there no way you and bernie and terry and maybe QoD could all work together on this?

[bernie]

@ paradoxnj, Go ahead and release, you have nothing to lose just don't advertise it.

@ zany

Is there no way you and bernie and terry and maybe QoD could all work together on this?

Terry and I are far too busy working on our own project RF_GameDirector (an RF2 alternative).
We thought that the way RF2 is being built was far too complicated for beginners to use. A game can be made at present using Ogre if you build it using C++ without the need to change the language. We thought a better approach would be to build the editor first and add the game shell afterwards and this is what we set out to do for RF2 but paradoxnj didn't like what we were doing and said it didn't fit in with his plans. We do ralise that a certain amount of scripting will be necessary to improve gameplay, it seems more logical to add the scripting afterwards rather than beforehand and to get something working that people can use (beginners don't want to be messing with scripting). We want to keep with the RF theme "Games without programming" as much as we can and scripting is programming.
As we had gone quite some way whith the project we decided we would carry on and do our own thing for the comunity. We are using and have been for the last 2-3 months Ogre 1.7 which is far far better than the outdated Ogre 1.6 particularly for the outdoor scene stuff. It also seemed logical to use Ogre 1.7 from the start as it uses a completely new and different terrain system to Ogre 1.6, it drops direct support for CEGUI (although it may be possible to use it via a plugin soon) and uses its own gui system along with many other major changes. Therefore to update would virtually require a complete re-write. Terrains can be made with unlimted size and the textures easily bumpmapped for extra realism.
We have a stable working demo of the editor on our svn that you can download and take a look at (explore the Island its quite big) although there is still a lot of work to be done (many more things to be added). You can add your own models in Ogre mesh format but animation is not working yet and at the moment you can only play with the terrain we have as a demo. You will soon be able to build a terrain of your own from a heightmap and blendmaps exported from L3dt.
We are starting the gameshell quite soon to run in parallel with the editor development and there will be regular builds on the svn.

Demo download: https://sourceforge.net/projects/realityeditor/

You will need latest directx9c redist on your pc and the redist will work on vista side by side with dx10

[zany_001]

...

So there's now THREE Reality Factorys?! Sigh...

[bernie]

Well at least you have freedom of choice. You are not compelled to use any of them. Just use whatever suits your needs.

[Juryiel]

Doh! I've been browsing the forums for a very very long time waiting to port my RF stuff to RF2 come may, and now this Sadness. You guys should work together and make a kickass hybrid product that scales on the ease of use vs. user power spectrum. I'm not much of a programmer in terms of software as big as a game engine so maybe I don't know what I'm talking about, but my guess is that having people split up like this will likely lead to either not ever releasing something useful, or instead, releasing something useful that is way too behind the 'edge'. Ah well, It is a hobby for you guys so we can't make demands, but the news that you guys split up was disappointing enough to get me to log in to post after a long time browsing.

I hope it works out, whatever the case.

Paradox, is there a reason to release to everyone (including noobs like me, I mean)? It would just flood you with support requests. Maybe just let whoever has more knowledge compile their own version and have it be officially unsupported, because it doesn't sound like anyone who can't compile their own will be able to do much with a pre-compiled version either, and would just likely give you headaches and the typical 'noob' demands of "Why isn't this working RF2 suxxxxxxx!!!!"

[paradoxnj]

paradoxnj didn't like what we were doing and said it didn't fit in with his plans

I never said I didn't like what you were doing. I said that you needed to follow the design I put forth. When I talked with Terry about the design, I needed to document it for him. I did that and I have not seen him online (AIM) since.

We thought that the way RF2 is being built was far too complicated for beginners to use. A game can be made at present using Ogre if you build it using C++ without the need to change the language. We thought a better approach would be to build the editor first and add the game shell afterwards and this is what we set out to do for RF2 but paradoxnj didn't like what we were doing and said it didn't fit in with his plans. We do ralise that a certain amount of scripting will be necessary to improve gameplay, it seems more logical to add the scripting afterwards rather than beforehand and to get something working that people can use (beginners don't want to be messing with scripting). We want to keep with the RF theme "Games without programming" as much as we can and scripting is programming.

The code you saw is not done. In addition, if you don't know the design, how could you determine that it was too complicated? It's like looking at a half built Ferrari and saying it sucks. Rome was not built in a day.

As far as ease of use is concerned...it will not require you to do anything but define an entity if you want which is 3 lines of code. No different than an INI file today except expandable.

How can you build an editor if you don't know what you are editing? The editor I had in mind would have written the scripts for you. You would build your logic graphically.

If you add scripting after you've already built your engine, you are limiting the engine to whatever you built it as. It becomes harder to generalize. I am generalizing and giving the user control as to what type of game they want to make through packages. Instead of distributing the entire RF2 as your game, you would distribute just your package (set of scripts, models, scenes, music, and soundfx). People would download the shell and game packages separately.

When RF2 starts, it looks for the installed packages and presents a list of "games" to play. I was also going create Game Kits. For example, an FPS Game Kit to start you in creating an FPS, an Action-RPG Game Kit for those Diablo fans, etc...

The problem I had is that I said there was a design, the work was started without even knowing what that design was. This means to me that you guys are going off and doing your own thing. All I asked for is that the design was followed and the editor was tightly integrated, that means supports nothing other than and is specific, to RF2.

[Allanon]

The editor I had in mind would have written the scripts for you. You would build your logic graphically.

Like the C4 Engine's Graphical Scripting Language?

[bernie]

@ 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.

Now for something I want to say to the forum in general.
/Rant
I would like to make something quite clear.
There has been no split.
There has been no fall out over this.
We are not moaning or complaining about what has been done.
Paradoxnj has family and work commitments but he is still prepared to carry on and do what he is doing for RF2.
People like Paradoxnj, QOD, Jay, Juutis, Terry, myself and others are doing what we do because we enjoy doing it, it is our hobby.
We are not a commercial organisation and do not ask for money, we do not slap unnecessary copyright notices all over the stuff we do or demand any sort of royalties for our work, we just like to share what we do with others and help out where we can.
We don't mind answering questions about stuff people don't understand.
No one is compelled or forced to use what we give.
So please, do not complain or be-little what we do, just accept our gifts gracefully.
If you do not like it use something else or make it yourself.
There is a very old proverb that fits the bill perfectly "Do not look a gift horse in the mouth".
/ Rant over

[hgt_terry]

What Bernie said is on the mark we have never or will never split things up we all need to work together.

Paradoxnj

We will support RF2 things where changing so much your end we could not start to write the editor based solo around you.

The answer now I think is now that you are at a stage of a beta release we will take the nut files that you have made and alter them visually in the editor so in the case of the player.nut the user won’t have to script but rather we will show the actor and have a properties box and changes can be made then saved out i.e. we will alter the nut file for the user then we will have a play button that will run the game shell. This can be done for all the nut files that are required for the game.

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.

Terry

[QuestOfDreams]

Regarding paradoxnj's original question whether to release RF2 in May:

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).


Concerning the development of the project:

It makes absolutely no sense if everyone is doing his own thing. None of you will finish a project that large on your own (at least within a reasonable time). If you want the next version to become a reality you must pull together.

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. This doesn't mean all things must be set in stone right from the beginning, but you need to discuss controversial subjects and not just turn away and start coding something (I mean you're free to do whatever you want but it doesn't help this project and as far as I'm concerned I will not support it).

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.

If you start a component like this and want to provide scripting control later you will end up either rewriting the complete feature (i.e. double the amount of work) or produce slow and messy code.

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.

[paradoxnj]

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.

[zany_001]

What QoD and Paradox have been saying about users needing scripting is very important. There are several game design programs out there, some free, that require no programming OR scripting. And they're crap. They produce crap games. Sure, the engine is graphically powerful enough, but you can't make a FPS with puzzles, switching between FPS and 3PS whenever you want, and different styles of game play. That's what makes RF unique. It requires no hardcore coding. In fact, if you don't want to, you don't have to script (much) either, as there are several pre-made scripts. But if you DO want the power scripting gives you, it's easy. Really easy. I understood the basics of RF scripting when I was 13, without any programming knowledge, and let's face it, I was a kidiot So a game engine without scripting isn't really RF at all, in my view.

[Allanon]

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.

Might consider using WaYee3D as a starting point for your editor. It is open source and uses Ogre.

[paradoxnj]

Might consider using WaYee3D as a starting point for your editor. It is open source and uses Ogre.

Where do they get these names? Thanks...I'll have a look.