RenWerX To Create Complete Game!
by Steve Ford · in General Discussion · 04/06/2005 (11:50 am) · 36 replies
RenWerX To Create Complete Game!
RenWerX has announced they will not be working with the Legends team to produce a game (reasons) instead, they will be producing a complete game themselves. RenWerX does plan to make both a Base game and their Renegades mod for it, but needs everyone's help:
We want both Base and Renegades to be formed by the Tribes community, and to do so have put together a custom living design plan for both. If you are interested in making sure the next tribes-like game or Ren mod plays like you want it to, please see our design introduction page.
In addition we plan to keep the Renegades name for our Mod, however need a name for the Base/ the game overall. We have put together a voting / suggestion process on our forums in [url="http://www.renwerx.com/forums/showthread.php?t=735"]this thread[/url], and would appreciate anyone interested in contributing doing so.
We still plan to release this game for free, but also we will now be able to release all of our scripts, models, maps etc. for other mods to use too. With our divergence from legends we plan to work with many mods to make sure anything they would like to see in the game engine is in there so they can bring their mods to new levels. If you are interested in more information for modders please see our modding page.
Finally, our team is rounding out nicely, we are at 46 people right now with some amazing talent. We do still have jobs open however, so please see our job listing page if you think you can help. As always for those who want to make a monetary donation we have a donations page and that page also explains how we use donations.
RenWerX has announced they will not be working with the Legends team to produce a game (reasons) instead, they will be producing a complete game themselves. RenWerX does plan to make both a Base game and their Renegades mod for it, but needs everyone's help:
We want both Base and Renegades to be formed by the Tribes community, and to do so have put together a custom living design plan for both. If you are interested in making sure the next tribes-like game or Ren mod plays like you want it to, please see our design introduction page.
In addition we plan to keep the Renegades name for our Mod, however need a name for the Base/ the game overall. We have put together a voting / suggestion process on our forums in [url="http://www.renwerx.com/forums/showthread.php?t=735"]this thread[/url], and would appreciate anyone interested in contributing doing so.
We still plan to release this game for free, but also we will now be able to release all of our scripts, models, maps etc. for other mods to use too. With our divergence from legends we plan to work with many mods to make sure anything they would like to see in the game engine is in there so they can bring their mods to new levels. If you are interested in more information for modders please see our modding page.
Finally, our team is rounding out nicely, we are at 46 people right now with some amazing talent. We do still have jobs open however, so please see our job listing page if you think you can help. As always for those who want to make a monetary donation we have a donations page and that page also explains how we use donations.
#22
**EDIT** realized this had to show how to use one return..
04/14/2005 (4:51 pm)
Well Gonzo, you asked how to write it, so here ya go:**EDIT** realized this had to show how to use one return..
/**
This function returns the team that the client should belong to in this game
@takes %client
@returns <Team Object> (Team1 | Team2 | Observers)
*/
function Game::teamSet(%client)
{
// Decide if the server should auto-assign player
if($Server::MatchMode $= "True"){ // No Auto Assign
// The match is looking for team 1 player
if(strstr($GTC_Pref_[%client, BaseName], $Match::TeamTagTeam1) != -1)
{ %objhold = Team1; } // Assigns Team1 to object place holder
// The match is looking for team 2 player
if(strstr($GTC_Pref_[%client, BaseName], $Match::TeamTagTeam2) != -1)
{ %objhold = Team2; } // Assigns Team1 to object place holder
} else { // Auto assign team
// If we got here, the server's job is to auto assign the player
if($Server::CountTeam1 > $Server::CountTeam2) { %objhold = Team2; }
else if ($Server::CountTeam1 > $Server::CountTeam2) { %objhold = Team1; }
// Check to see if Both teams have no players, auto assign to 1
if(($Server::CountTeam1 $= "0" && $Server::CountTeam2 $= "0") ||
$Pref::Server::NoWait $= "True"){ %objhold = Team1; }
}
// If we got to this point, this client can only be observer
if (!%objhold){
%client.isObserver = "True"; %objhold = Observers;
}
return %objhold; // return the object
}
#23
Nick said this:
And Gonzo called him on it. Your function still has return statements in multiple places (as Gonzo's does as well).
Personally, I think Nick's statement is a bit unusual myself--but that's just me.
04/14/2005 (4:59 pm)
...I'm not siding with Gonzo at all here, but that function has just as many exit points as his version does...Nick said this:
Quote:==> Very important... don't put return statements in the middle of a method. You would be surprised at how many issues can be avoided if the code is written such that it has a single return at the end of a method.
And Gonzo called him on it. Your function still has return statements in multiple places (as Gonzo's does as well).
Personally, I think Nick's statement is a bit unusual myself--but that's just me.
#24
I almost feel bad even posting though, because really this whole post is way off topic. Good luck with your game Nick. I can't think of any good name for the game as a whole. It seems ironic you are on such a search! Doesn't it?
04/14/2005 (5:01 pm)
...but you did not remove all the returns (except one)....wasn't that the point?I almost feel bad even posting though, because really this whole post is way off topic. Good luck with your game Nick. I can't think of any good name for the game as a whole. It seems ironic you are on such a search! Doesn't it?
#25
04/14/2005 (5:02 pm)
Yeah I fixed to use one return.. my bad..
#26
"One Entry, One Exit"
They also generally state that all functions should have a return.
04/14/2005 (5:08 pm)
Current Computer Science programming classes teach and preach "One Entry, One Exit"
They also generally state that all functions should have a return.
#27
04/14/2005 (6:32 pm)
They also say to not use GoTo but there are situations where it is useful. You guys need to put down the Dikjstra pipe for a bit. He was smart, but really, who cares.
#28
04/14/2005 (6:36 pm)
Not to mention way OT:)
#29
04/15/2005 (5:15 am)
So, good luck to the RenWerX team!
#30
The whole point of one-entry/one-exit is that it makes the code predictable to read. If you expect one return, you don't have to comb the source for others. It only makes the code better in the sense that it simplifies communication. Not a trivial benefit, but also not an overriding one for which no exceptions can be made. It's an instance of a coding standard, like where you put your braces and whether to use tabs or spaces for indenting. When you go against the standard, you post BIG COMMENTS to warn the maintenance programmer that something unusual was required.
Also note that the code should adequately explain HOW something is done, and the comments should explain WHY it's done a particular way.
04/16/2005 (2:20 pm)
Hehe, don't you love ivory tower programming?The whole point of one-entry/one-exit is that it makes the code predictable to read. If you expect one return, you don't have to comb the source for others. It only makes the code better in the sense that it simplifies communication. Not a trivial benefit, but also not an overriding one for which no exceptions can be made. It's an instance of a coding standard, like where you put your braces and whether to use tabs or spaces for indenting. When you go against the standard, you post BIG COMMENTS to warn the maintenance programmer that something unusual was required.
Also note that the code should adequately explain HOW something is done, and the comments should explain WHY it's done a particular way.
#31
As you can see we are checking a member of foo and adjusting it accordingly, in this instance there is absolutely no reason to provide a return value, hence none is given.
Anyways thats my 2c
04/17/2005 (11:20 am)
@Harold... I've only ever seen what you speak of in the "entry level" programming classes,for example BASIC and Beginning C. One entry and one exit is all but impossible to maintain in an OOP environment especially when you are talking about programming for an Event Driven environment, where everything behaves like little self contained programs working together in concert to produce a result. Also a return value is not always needed for instance...void MyFunction(void* foo){
foo.bar = 1;
}
if(foo.bar !=1){
MyFunction(*foo);
}As you can see we are checking a member of foo and adjusting it accordingly, in this instance there is absolutely no reason to provide a return value, hence none is given.
Anyways thats my 2c
#32
On the whole code debate... I side with Gonzo in terms of using the language anyway you can to write clean, efficient code. If your code ends up being uglier or more confusing by forcing yourself to use only one return, then why use only one? Little rules like "one entry, one exit" are just rules of thumb, not guaranteed-best practice by any means. They are good, sometimes, especially when you're learning programming and don't have confidence in your ability to write the best code.
There's always more than one way to solve a problem, and once you've chosen an algorithm, there's more than one way to write up its routines. Until you're really good at determining the best amongst various algorithmic and implementation options, rules like this can help you avoid the *wrong* decisions. You get to a certain point though, and you end up writing code that is clean naturally, probably adheres to rules like this for the most part, and goes against the grain when that's a better choice.
04/17/2005 (12:42 pm)
Sorry to hear that you guys won't be working with the Legends team. But, good luck with your game. :) That part's great news, glad to hear you guys are doing a full game.On the whole code debate... I side with Gonzo in terms of using the language anyway you can to write clean, efficient code. If your code ends up being uglier or more confusing by forcing yourself to use only one return, then why use only one? Little rules like "one entry, one exit" are just rules of thumb, not guaranteed-best practice by any means. They are good, sometimes, especially when you're learning programming and don't have confidence in your ability to write the best code.
There's always more than one way to solve a problem, and once you've chosen an algorithm, there's more than one way to write up its routines. Until you're really good at determining the best amongst various algorithmic and implementation options, rules like this can help you avoid the *wrong* decisions. You get to a certain point though, and you end up writing code that is clean naturally, probably adheres to rules like this for the most part, and goes against the grain when that's a better choice.
#33
I believe if you ensure that the team structure and tasks are appropriately assigned, and everyone is quite clear on their contribution to the puzzle, much can be accomplished with a larger team.
It is true though, that the communication and clarity of what's required would be a downfall with so many.
Good luck Nick and team!
@Dave - Very long and aggressive post, must have hit a sensitive nerve somewhere in there?
Not sure it deserved that much of your time though : )
04/29/2005 (6:29 pm)
@NickI believe if you ensure that the team structure and tasks are appropriately assigned, and everyone is quite clear on their contribution to the puzzle, much can be accomplished with a larger team.
It is true though, that the communication and clarity of what's required would be a downfall with so many.
Good luck Nick and team!
@Dave - Very long and aggressive post, must have hit a sensitive nerve somewhere in there?
Not sure it deserved that much of your time though : )
#34
04/29/2005 (6:35 pm)
Thanks for those on-thread posts, as for flames coming from the TW community means we are used to a lot of it. We have made huge leaps in the last three weeks and things are coming along well. We plan to release a preview of what we have been doing in the next few weeks for everyone to see some of what we have been working on.
#35
04/29/2005 (7:42 pm)
Most likely not, we will announce it on our site for some of those who are watching our progress closely but a lot of what we have done hasn't been something that will look amazing in screenshots. Mainly getting skiing, jetting, skipping, vehicles, inv stations, etc. in place. Once we have something photo impressive we will be submitting a snapshot.
#36
Edit:
Dave, please be kind enough to post a list of your team members, I would sure hate to render advice or assistance to them knowing how much it would insult you to learn from a clown. If nothing else, send me a list by E-mail and you have my word I'll never help you or them ever again.
04/30/2005 (12:19 am)
Well Digi Dave, all I can say is you spent a heck of a lot of time on that to be so completely wrong about all of it. Regardless, I take it you're defending your team member Judd? So I guess it wouldn't bother you at all to know that your team member still delivered a faulty function even after all the edits and re-writes? What a shame. Had he written the software in my cell phone, I suspect I wouldn't even be able to make a call. Before you criticize another camp, you should clean up your own. Can you see his mistake or do I have to spell it out for you?Edit:
Dave, please be kind enough to post a list of your team members, I would sure hate to render advice or assistance to them knowing how much it would insult you to learn from a clown. If nothing else, send me a list by E-mail and you have my word I'll never help you or them ever again.
Torque Owner Gonzo T. Clown