Game Development Community

dev|Pro Game Development Curriculum

Plan for Pauliver

by Pauliver · 12/07/2005 (12:11 pm) · 4 comments

So at startup each map will have smaller built bases by the Indigenous people, w/ underground caverns piping linking them AND one large underground base. The indigenous people will be bots and there underground base will be Packed, It will be large

Each group will have a main command center (flying?) w/ npc's who give out quests to clear out indigenous people, and indigenous animals, and take bases.. these mobs will have a direct server link (explained by control panels that they are near). And will be able to know if enemies OR indigenous people are near your base. The indigenous people will attempt to reclaim bases at a time of X (10 hours) [give or take 6 hours] from when they are taken, and will also have random patrols that attempt to re-claim bases.. that they pass. If you hold a base for 1 week and build a command center, than one of your command staff will appear there and you will be able to get quests from them too. Each week you hold it you will get another command staff there, if the command staff is killed you must wait till next week to get another member of the command staff there. If a base is taken back over by indigenous people it will start having patrols of them in the base itself after 24 hours, w/ X men showing up each Y hours after the base is taken by them. Till its fully stocked by these Indigenous people

Bases will be expandable. You can user your resources to create "deployable walls", pipelines, more equipment terminals, spawn locations, towers, turrets, Mining equipment ect.. there will be 1 or 0 vpads in each base, and from your main base you can spawn vehicles that deploy into vpads. Each deployable item will have 1,2,4,6 or 8 link points, and new things can only be deployed on these link points. The more stuff you have, the more of a drain on the resources for your base you will have. Resources from a base can run out in long run. And bases/ maps will have to be abandoned after lets say 1 month.

Deployed structures can take damage. And will require repair, they will also show damage that they take (if we can get models for that), they can not be un-deployed, and they explode killing everyone in them/ near them if they are destroyed. They auto-repair themselves, relatively fast, but have an internal switch that can be turned on to disable auto-repair, even w/ auto-repair off they still take a bit of time to destroy.

The central point of the game is still Resources; there are 3 to start out with. One is an energy source [crystals, or just straight energy taken from the ground under the base], one is a water-ish resource, used to help re-constitute the body when its spawned, and the other is a mineral used to build everything. Each thing you create [weapons, a player spawning, vehicles, ect..) will take a bit of 2 if not 3 of them. The existing bases that are created by the indigenous people will be built on sites of resources, but there will be more around that can be "farmed" if you choose not to take a base itself, and just build your own. The indigenous people's bases will not harvest as much of the resources as they possibly can, and you will have to get/deploy additional mining equipment and additional pipelines to get all of the resource possible from the base, and then to the other bases if they are short on one resources.

Most bases will harvest 1 or 2 resources, maybe a tiny bit of the third but the goal will be that you have to link 2 or more bases in order to be in optimal fighting condition (able to pull all vech's, weapons, spawn fastest, ect..) These will cause a drain on resources and each base will have resource counters so that players in them can see what they lack/ have excess of. Some sort of engine code will work on balancing resources between bases, to get the resource from where it is to where its needed.

The Pipelines will have 3 types, 1 underground [in the tunnels] pipeline, 2 microwave beam, 3 above ground pipeline. Each takes a different amount of time to build, has a different amount of damage it can take, and moves a different amount of resources. Microwave will be the fastest to build, w/ just setting up small vechs between bases that "beam" resources from one to another, they are fast to build [deployable vechs], semi hard to destroy and move the least of all 3 pipeline types. Above ground pipes will be the middle, they will be semi-slow to build, but will still be deployed from vechs, so faster than the underground pipeline, they will move a middle amount of the resource. The slowest building will be the underground pipeline, There will be some of this in place from the indigenous people, so you will have to destroy what you don't need of theres, and then put your own in place, it will be a back pack carried item, very hard to destroy but it will take a single person several trips to put enough in place to get a pipeline going.

**NEW**
There will be two systems, an XP system that you can get lvls in, and a skill system you can get lvls in. You get skill lvls by using a skill, and the result is the more lvls you have in a skill [door hacking, base taking, repairing, combat medic, combat res, ect..] that faster you can do it in, and the more you restore in some of the cases. The XP system will be straight forward, if it doesn't raise a skill, it gives you xp. At each lvl there will be new skills you can take? Possibly more weapons, ect.
/**NEW**



*(Indigenous people are ALL bots)

There doesn't look like alot of more code to be actually added to the engine itself for this, just need to do some scripting, and all of it is cookie cutter script, do it once and repeat it for all other items of the same type.

The main thing that is needed is modelers / animators.

About the author

Recent Blogs

• T2D Risk Done (Now what?)

#1
12/07/2005 (12:13 pm)
OH* i forgot to post that this is designed to be a FPS Between 2 teams, it just has bots in it to give it some aspects of a MMO, and to keep it from bieng boring if the teams are small. The dream would be though to eventually link several servers together and have lets say 500 vs 500 across maybe 8 servers, so that some have heavy battle for the people that like that, and some have just player vs bot battle.
#2
12/07/2005 (12:30 pm)
This is a great idea.
#3
12/07/2005 (9:39 pm)
This is vastly more complex to implement then you are thinking, especially with concerns to AI, dynamic environment building, and managing this very large amount of data over a server. But it sounds neat.
#4
12/08/2005 (8:03 am)
I understand that it is a bit of an undertaking, however most of it really is repeating one thing i have done, on a bunch of other items. The AI while bieng complex is easily broken down into a bunch of conditioning statements, and the vast AI would be the last thing to go in. The only thing that really worries me is server load. But i'll deal w/ that when i come to it.

I'm working w/ Ted ( http://www.garagegames.com/my/home/view.profile.php?qid=1236 ) but i didn't want to post his name w/ it because while he has seen earlier documents he is reading this currently and hasn't given me feedback on it yet.

When me and Ted originally discussed this project we were thinking of trying to make it more of a community project, we would get all of the unique code working (basically have an example for each concept that works), and then we would try and get some help from the community to get the repetative code done (its in TS so we could get help from non-SDK owners), and w/ models, ect.. It was our thinking that

1) A more complete FPS / RPG example for the community would show people how to do it, and result in more games and less frusturation coming from the GarageGames community. [Lets face it Marble Blast 51 sounds great.. and im very happy for the Marble Blast guys but i really would like to see another AAA game come out of the Torque engine, and the genra's i play are RPG and FPS so i would like it in that genra]

2) Teds original project, which i joined called Epic Frontiers is well on the way code wise but has hit a stand still in a lack of Artists helping it. We were hoping that if we can get a good showing on this project, which will require significantly less models than his incredible RPG idea, that we could attract artists that would hopefully be willing to help on Epic Frontiers.

3) Potentially write some tools in one of microcofts .Net languages to help quickly and accurately crank out torque script files for things that are done often and repatively (like creating weapons, armor, ect..)

4) People (us and others who helped) could use this as a testing ground for things that are going to go into other projects, which are less far along (i would give you examples, but im under Ted's EULA so let me just say check out the last 5 posts of this [ http://www.garagegames.com/mg/forums/result.thread.php?qt=19509 ] thread to see the kind of thing Ted has done that could use some testing.


We are mainly doing this for reason 1 and 2 though..