Realm Wars IV - a new hope!

#1 Interesting. While I doubt that GG would want to take that on again, and I doubt that the community can be herded efficiently enough for this, I'll bite...

What I can do is contribute a basic inventory system to this, based on what I have working in my own MMO project (I'm saying basic because it's possible that not everyone will agree on some of the crafting features we've implemented for Epic Frontiers).

As for the versions, it doesn't matter so much. TGE is just as capable as TGEA, and most of the resources out there are either portable to TGE, or started as TGE in the first place, so it's fine. Probably better to get people to concentrate on features rather than eye candy and shaders. Except for artists- they sort of need to concentrate on making things pretty ;)

#2 Even though it is a community project, I think a lot of developers would be wary to invest their time on an MMO.. just because it's an MMO.

Plus, there isn't a wealth of people here that are really knowledgeable in the MMO aspects (Tony and Ted come to mind as two main contributors), so it seems like the most knowledgeable people would have to do the majority of the coding/networking parts, which are the most difficult to design and code (in my opinion). And those most knowledgeable in the advanced topics have their own projects that they are working on.

Instead of an MMO, why not create a game with the networking design of something like NWN or Diablo - where there's not really a persistent world, more of just an offline/online rpg. There aren't as many security features of course, but we've already seen that this strategy is fun and viable.

#3 Yes with the new material in T3D I have been able to port all* 1.5 content to T3D as long its not a *diff I have had no luck with diffs but thats maybe my maps using maptodiff+ crashes in T3D.

T3D has the community dazzeld, so you may want to get the soon to be released MMO kit for T3D for it is a new hope! :D

#4 [minor hijack]
@OmegaDog, re-export your models as TGEA difs and they should load fine in T3D.
[/minor hijack]

#5 Thanks all for your interest! I just want to point out that I am by far the last person that should be attempting this. I'm not a programmer, and even though I've been a garagegames member since 2001(?) I've only been using Torque since ... 2005, maybe? When did 1.5.2 come out?

Anyways, the only reason I'm taking the initiative is because I'm on drugs... No, seriously, its because no one else has.

Before I try to make a new Realm Wars, I have to get the LogIn/Password feature and Save/Load systems working. I will then submit that as a Resource, as a Persistent World starter kit, even though its really only the absolute bare bones framework.

Torque creates the world and has functional networking. This along with a minor security setup and a simple save/load and the ball is rolling.

Then, and only then will I feel ready to move on to Realm Wars.

Thanks for the offer of an Inventory system! I will definitely come calling for that when the time is right!

Again, thanks for all the attention, and please keep the discussion alive. More ideas and suggestions and comments are needed!

Tony

#6 Sounds like fun. I could throw a wall of scripting towards that, and a little C++ code to, but I have very little experience in setting up outside databases and log-in servers. If you want to use TGE I may be willing to step backwards for that... even if it might be easier to use TGE and implement various resources already written.

It would be interesting to see if the current community could come together and finish up where the previous generation left off. In all actuality I think the original RW project fizzled out due to the egos involved and battling over who was in control and who was in charge of what, plus a specific lack of direction. From what I remember "A" would get things moving in one direction one week, but then "B" would want things to happen in another direction the next. Then "C" ... you get the idea! And what do you do when "X" decides to pull out all of his/her art because of an argument with "Y", and "Z" decides the hell with free for the community I want to make money? So I think you would need to have a clear cut set of guidelines for everyone who helped to follow, disclaimers for release of code and artwork, etc.

@OmegaDog: map2dif sucks. Period. Sure it may work sometimes, but it causes far too many problems and failures, bad lighting, etc... Use Constructor, save all of your maps to .csx format and then export them using "Export To DIF" -- that will work in TGE 1.5+, TGEa, and Torque 3D universally (and you can embed .dts shapes using that method). The buildings you see in the Constructor screenshots are actually part of an unseen (it was glimpsed in one video) and unfinished level for Torque 3D.

#7 I think you are better off rolling with TGEA 1.8 or Torque3D to be honest as there are many technical benefits and features offered there that would make the product easier to develop and of course make the game more interesting to do.

If you truely plan on making this though, before you start screaming out to the world "ITS A MMO.... NOW GO WOOOOOO!" you should really take some time to think about the type of game that you want to make (and no, a MMO is not what I mean). Create a pitch document that you would use to sell the game to any publisher as a means of knowing if this is something worthwhile investing in or not.

There is also ALOT of backend work that you should begin to setup before you even begin to recruit for the project and you should try to do a lot of reserach as to why community project games in the past have fizzled out so you don't repeat the same thing. I hate to say it but you are already starting to repeat the problems that made the past projects fail.

Logan

#8 Yeah, I would second that TGEa 1.8.1 or even Torque 3D would be a better alternative than TGE -- kind of thinking ahead. Porting in either direction can be a pain (depends on what changed) regardless of what engine is used.

#9 Indeed.

Personally speaking I would say got the Torque3D route and be pretty free from an art standpoint to make something that matches the visual quality that gamers are expecting.

#10 I've offered to help people on projects like this... the only one that I've worked on that ended up turning into a playable game was Fractured Universe.

While I respect Infinitum3D's energy and ideas, unless a programmer familiar with Torque takes the bull by the horns and removes the FPS Starter Kit code and replaces it with an RPG Starter Kit, you're still going to end up with an FPS with some RPG-like features.

No matter how you slice it and dice it, package it as an RPG Starter Kit or as a community project, it's still a huge chunk of work.

This is what I can offer if you're interested.

It'll take a few months, but the code will be solid and it'll give you some time to get your ducks in a row if you want to proceed with a community game project.

#11 I appreciate the offers for RW4, but please remember my very first post: I'm moving soon. It will be late July/early August before I can even begin to do anything for RW4. I would really like to develop a barebones "persistent world kit" first.

Don't get me wrong. I really am glad this is generating community support and discussion, but like someone said in an earlier post; there is a lot of back end work needed before the project even gets started.

@Logan - I need some help from you! You say I'm already making some mistakes. PLEASE explain! I don't want to make mistakes and I hate wasting people's time (my own and others), so if you can give me some tips, I'd greatly appreciate it.

Same goes for everyone else. If I'm saying or doing something wrong, point me in the right direction. I take criticism very well. I know I'm going to mess up. I need the community to keep me going down the right road.

A quick question now;

Why can't the FPS starter be used as the basis of an RPG starter? Why does the FPS starter have to be "ripped out" and replaced? All the FPS starter is is Kork, and the playerOrk with a crossbow. Not much of an FPS anyways, and it IS the earliest stage of an RPG, IMHO.

Thanks! Keep discussing :)

Tony

#12 @Ininitum3D - You'd have to take a look at the code to see it.

Ever notice how Player, GameBase, etc has a lot of "Tribes 2" ish code in it? I don't think Garage Games ever meant it to be more than example code.... FPS example code.

There is a lot of code in there that's simply too accurate for RPG use. The accurate collision detection and physics will waste a lot of CPU time that could be better spent elsewhere.

You can make a great RPG using the FPS Starter Kit, don't get me wrong... but I would never consider making a professional RPG game out of it.

The datablock system, while great for a moddable FPS game, would not be my first choice for an RPG game.

Maybe saying "rip it all out and replace it" is a bit harsh. It's more like:

When I create a new .sln for a RPG using Torque, I wouldn't initially include many of the files found in the "Game" or "T3D" folder (depending on which engine you're using). I might end up copying / pasting a significant amount of it into whatever I write, but each line of code copied would be a conscious decision.

The same goes for the .cs files. When I wrote Fractured Universe, I started with a completely empty script directory. I did end up copying some of the code from the FPS Starter Kit, but probably close to 90% of it was original code.

Again, that's not the only way to do it, but IMHO it's the best.

#13 I see your point, however (and I'm generalizing greatly here), I've always thought that the goal of any game programmer was to get a simple proof of concept playable demo out as quickly as possible, to draw in a development team, and to generate buzz about the product. THEN, redo everything the right way.

I also always thought that was kinda dumb because you waste all that early stuff, but it also makes sense, in a way. Kinda like sketching something a few times before painting the masterpiece, or doing three rewrites for an English 101 class. Just get something, anything, on paper, then make it better.

I can see it both ways...

Tony

#14

Quote:I've always thought that the goal of any game programmer was to get a simple proof of concept playable demo out as quickly as possible, to draw in a development team, and to generate buzz about the product. THEN, redo everything the right way.

You're rarely able to go back and redo everything the right way, so you're likely going to be stuck with whatever you write the first time.

The lazier you are, the higher the software entropy and the quicker you reach the point where the programmer throws up his hands and says "this is crap, we need to throw everything away and start all over."

Game programmers are the worst because they rarely never reach that point, and they get away with sloppy coding, but when they get caught with their pants down, that's when they start running into missed deadlines and tons of overtime.

The misconception, though, is that it takes longer to do things right in the first place. It doesn't. It only appears to take longer, but if you follow the appropriate methodologies, none of the stakeholders will misunderstand the status of the project.

Quote:I also always thought that was kinda dumb because you waste all that early stuff, but it also makes sense, in a way. Kinda like sketching something a few times before painting the masterpiece, or doing three rewrites for an English 101 class. Just get something, anything, on paper, then make it better.

This is still necessary. You always have to go back and iterate, improve, adjust and fix things. That is why it's so important to do things correctly the first time.

"Huh?"

I know that doesn't make any sense, but you have to understand from the perspective of a programmer.

As you program, things will change. The requirements will change, the design will change, and your understanding of the problem (and the answer!) will change.

But, every line of code you modify and every method you change, you run the risk of breaking things. Why do you think programmers prefer to start over? Because they (or the coders before them) didn't mitigate these risks.

Good object oriented design is a way to mitigate these risks. There are other ways too, but this is the way I know best.

Two criteria that are commonly missed: Never expose any more than you must, and use composition instead of inheritance where appropriate.

Torque is a fantastic example of this, and that is the leading cause of so many good programmers getting frustrated with Torque.

"You change one thing, you break something else" is the result. aka "High Software Entropy"

Anyway, sorry to de-rail your .plan... I'll post more stuff that's on-topic, but I have to run off to my day job now :P

#15 Things you might want to do.

1. Create your pitch document. This is like a short 2 pager you would use to pitch the idea to a publisher, but it's very useful to give to other people to get them interested in your project without giving a lot away.

2. Get some backend stuff setup. Bugtracking and SVN are a must as are some tools to handle tasks. Having a team website and likely an IRC channel would be helpful as well. Also if this is going to be a MMO make certain that you have a server of some kind ready to roll.

3. Get a small demo going yourself. No one wants to come into a project and find out nothings even been done yet. They want to see something tangible in front of them that gives them an even rough sense of the game.

4. Get some contributor agreements created. You want to make certain that you have the right to distribute any work that a person has made in the scope of this project. You can worry about what you want to do with regards to ownership rights, copyright, etc. but at the very least get your bases covered with being able to use the persons contributions.

5. Settle on some standard communication and dev tools. Yes I know its supposed to be a community project, but if someone makes a piece of art in a tool no one on the team has access to you are kinda hooped.

6. Get a core team of friends. One of the biggest failings of a community project will happen when your cheif programm, artist or whatever flakes out and disappears leaving you in the lurch. As such you better be ready to either do this stuff yourself or turn to a good friend that can do it for you. These people will also act as your team/project leads and make certain they know WTF they are doing. If someone asks for help you don't want the response to always be "I don't know either man I am as new to this as you are".

7. Create some sort of tiered involvement system. Basicly what I am trying to say is don't list all your tasks for the public to view and choose. The problem that this creates is everyone wants to create "Deathlord Talon" and no one wants to make "Overturned wagon" and thus all your necessary environment art and assets never get create. This also creates a large problem with people cherry picking all the good art (and chances are they will never deliver on it) and leaving the scraps which dont interest people. As such when I say tiered involvement, a new person should proove themselves to the project by having to start on these more mundane tasks and then they can move up to bigger tasks once you get a better sense of what they can deliver. Remember that people always have big intentions, but they can rarely live up to them.

8. Keep your goals in sight. While it is a community project it is not a design by commitee project. Someone needs to be the Producer and have final say in how things should be done. You do not need to be rigid and ignore all suggestions, but you also need to crack the whip and stand your ground when you must. Your job is to ensure the main goals of the project or milestone get met.

9. Work in small manageabe chunks. Dream big but start small and simple and grow from there. Don't let your first task be a major city, instead make it a simple farmstead in the valley. This will still let you test all your necessary tech, but won't distract your team with shiney objects. Grow slowly and logically from there.

10. Go pick up your favorite pen and paper RPG. Borrow its ruleset for your game and spend some time before you even get anything else done making what they refur to as a "module" or "adventure" for it. Then play it with your friends. This will give you some good game design experiance and put you on the path of what makes an enjoyable game.

#16 @Logan: you should start a thread sort of like Ted Southard's "Before posting about an MMO, please read this...", but with your 10 rules and call it something like "If you're thinking of starting a community project..." and see if it can get stickied.

#17 I dont know if I would really call that 10 rules, but more of things that I could recall from the top of my head from Realm Wars as well as my own experiances as an indie.

#18 Logan makes a lot of great points there, and you should definitely pay heed.

I really just have one thing to comment on.

Quote:
I see your point, however (and I'm generalizing greatly here), I've always thought that the goal of any game programmer was to get a simple proof of concept playable demo out as quickly as possible, to draw in a development team, and to generate buzz about the product. THEN, redo everything the right way.

Getting a throw-away prototype out quickly can be useful, but not in the context that you're describing. If you already have your core team, and a design, and resources to spend and use, then going gungho to grind out a quick prototype to shop to a publisher is a good idea. But this doesn't really apply to a community-based project, or to indie projects in general.

Since you're probably not going to be able to spend 60 hours a week for the next 2 years on this project, and you're probably not going to find (m)any other people willing to do that for free either, it will be very hard to just throw away work that you've already put into it and start over. So make the time that you have count. Take the time to lay out a clear and robust design from the beginning, and grind it out. You won't get much joy from this in the beginning, but you'll be glad you did down the road... or very sorry that you didn't.

#19 Well said, Logan. All of those are key to a successful community project.

One thing I would like to point out though, is how important #6 is.

There are generally two styles of management... leading and pushing.

Community projects succeed only if you have a core group leading and you publish rapid, iterative releases.

Two, possibly three weeks is the longest you should go without publishing a new build, even if it's only available internally. Each new build should be stable and have at least one new feature, whether it's a new game feature, new art, some updated GUI's or additional quests... whatever. But each release must have visible progress.

This motivates people.... people currently contributing see that other people are working and they dive in and add their own contributions. New people join up and stick with it longer when there are consistent, frequent and stable releases.

But, this won't work unless your core team leads the way.

I know I could do the bulk of the programming and a subset of the environmental art for a community project like this, but I wouldn't want to sink my time into a community project unless it was put together with a successful recipe.

Logans recipe is a great start... the only thing I'd add besides what I have already added is this:

The leader of the project must either be a great 3d artist or a great game designer with the ability to implement at least a part of his design.... otherwise he's pushing and not leading.

#20 @Tony

Great point at the end there. I highly agree that the team lead has to be someone capable of leading that vision with their own set of skills (ie. great art, great code, audio, marketing, etc.). Generally I find a lot of people think that being just an "idea guy" is enough to make a game when really you need to take the bull by the horns.

Inspire your team towards greatness, don't be the guy that sits there and acts like a backseat driver it wears out really fast.