As a good little OOP Coder I think it's a good idea that we seperate code in seperate DLL's so that's it's easier to update (and break compatiblity) seperate parts of code.
Correct me if I'm wrong here, this is just an sketchy idea. Feel free to come up with something better.
Main App
|
|\_ Engine (Sound, 3D, Input, etc)
|\_ Network (Network Protocol)
|\_ Game (AI, Parsing Gamedata)
\_ DataFetcher (Prefetch data via Network)
For easy use I guess it's easier to use design-time binding for now instead of late-binding during runtime.
With a 128x128 heightmap, this is the terrain it makes, fairly large. It should be suitable for 10 people to run around in if you want them to fight using sniper weapons from far away, or 64 people if you want them fighting from medium/close range.
Give or take a few square miles
I don't think you'll want 64 mechs running around in a box of a few hundred meters :]
Check the mech.jpg file that's attached. That's from MechCommander 2 but Mechwarrior Battlegrounds will have basically a bit of the same look. Isometric-tilted camera and continuous control over the mech instead of RTS-Style point-n-click.
Last edited by Devion; Aug 30th, 2005 at 04:45 AM.
I think 64 mechs running around in a football field sized area would be hilarious, you need to set that up and render a screeny for us
You guys going to sell this or open source it or what?
I used to have MechAssault on the XBox, that a kickass game that was. It'd be interesting to see how your project continues, I shall watch with interest.
Last edited by wossname; Aug 30th, 2005 at 04:51 AM.
So far I think this will be open source with a small expection of certain code (like the anti-cheat thingy which will be implemented at a later stage)
And no.. not 128x128 miles more or less 4 by 4 mile zones in team deathmatch or assaults. 1 by 1 mile for small deathmatch groups, 2 by 2 etc. Maybe we should incorporate Battlefield II's dynamic map size (depending on amount of players)?
128x128 square miles,no. But, safe to say, maps about the size of, or larger than, Battlefield 1942/Vietnam/2. Im going to try partioning the maps then rendering the closest partions.
I used to have MechAssault on the XBox, that a kickass game that was. It'd be interesting to see how your project continues, I shall watch with interest
MechAssault was pretty cool xcept that it was only on Xbox.. I wish they kept it on the PC
Well these partions contain info relevant to where they are along with the vertex data. And unless I am mistaken, a partion is a segment of something.
Partion/Partition
par·ti·tion (pär-tshn)
n.
1.
a. The act or process of dividing something into parts.
b. The state of being so divided.
tr.v. par·ti·tioned, par·ti·tion·ing, par·ti·tions
1. To divide into parts, pieces, or sections.
2. To divide or separate by means of a partition: We partitioned off the alcove to make another bedroom.
Anyway; Partion or Partition or Tile or Segment or Cell - Does it really matter? We know what the subject is - The project thread is getting poluted by meaningless chatter about typo's and misformed words.
Replaced all 56 instances of Partion with Partition.
Btw, Devion, I am not working on the actual game code right now. I will leave it to you to create the base of the actual game. I am working on getting an outdoor terrain rendering system up (Done) and running as efficiently (Not done) as possible.
Replaced all 56 instances of Partion with Partition.
Btw, Devion, I am not working on the actual game code right now. I will leave it to you to create the base of the actual game. I am working on getting an outdoor terrain rendering system up (Done) and running as efficiently (Not done) as possible.
Don't worry, I kinda assumed that
Are you guys designing your mechs from scratch or are you using meshes from one of the other games?
I was going to check in with the development team of Capellan Solution (C&C Generals Mechwarrior mod team) as they modelled about every mech type there is in any of the Mechwarrior games. If that doesn't work we would need a few modellers to work on 'm and build 'm from scratch (thank god there is enough research material on the net )
btw I've designed a small little (Quick and freakin' dirty) logo.. It's on the 1st post.
and...
I've sent the project leader of Capellan Solution an e-mail asking if we can use stuff they made. I hope they allow us as it will greatly increase speed of the project. (Atleast we can test the game with real mech models instead of little square cubes with bright colors)
and......
Another mail sent to Wizkidsgames.com (Property holder of Battletech). As with Capellan Solution. If they allow us to use the battletech property it will severely increase the project development process.. if not.. well then we have a few things to change so we don't infringe on any intellectual property.
Last edited by Devion; Aug 30th, 2005 at 12:21 PM.
Reason: merged 3 posts.
Directory: Source\Game DLL's\MechData_DLL
Author: Devion
Date: 10:22 PM 8/30/2005
Description: MechData contains the class 'clsMech' which is used in-game to hold all the data of the current mech. It's not done yet (Returning Properties of a mech needs to be better for sure.)
Devion - To increase performance, loadtimes will go up, as it generates smaller partions (32x32 or 16x16 instead of 64x64), it must make more partions to fill the map and making each partion means one more iteration through the entire map. That and the overhead of LOD calculations (only when you load the map).
Edit: Im not a DX3D guru. Im a DX2D guru and my 3d knowledge is based on software rendering I used to do.
Scince we are using an isometric camera angle, The draw distance does not have to be very far. In the screenshot, I have loaded a 512x512 heightmap, with each pixel bieng a vertex 32 places apart (making the map size 16384x16384), it took 8 seconds to partition it (as a compiled native code exe) and renders with quite good performance. Using a 1024x1024 heightmap took about a min by the clock.
I will now try to implement LOD by using lower res heightmaps.
Edit: I have implemented LOD. At close to medium distances, the partitions are rendered at full detail. At medium to far distances, the partitions are rendered at LOD detail, defined as a constant, to be OriginalDetail/LODDetail. Currently, LODDetail is set to 4. Unfortunately, there are seams between the non-lod and lod partitions so I have to work that out. It only appears then looking around FPS-style, but it will be fine for isometric 3d.
My current constants, about the terrain detail, are
Private Const PartitionSize As Long = 16
Private Const PartitionViewLODDistance As Long = 64 - 16
Private Const PartitionViewDistance As Long = 128 - 32
Private Const PartitionLODSize As Long = 4
Private Const MapScale As Long = 64 'Map horizontal scale
Private Const MapVScale As Long = 4 'Map vertical scale