[Game idea] An Idea (Isometric Multiplayer Shoot'm'Up)

Just posting this to poll if peope would be interesting in playing such a game and if there might be people here that are interested in helping - I didn't want to post this in project request just yet as I wasn't too sure if people actually visit that area nor if people would be interested in the first place.

Anyway.. The game description:

Mechwarrior :: Battlegrounds
An isometric real-time shooter.

Note up front:

The Copyright of the whole Mechwarrior/Mechcommander/BattleTech/etc lies with FASA (Read:Microsoft) and the images and such used would be copyright Microsoft, etc. This would be a freeware game which people could play on the internet or on a lan.

Overview:

Mechwarrior :: Battlegrounds (from now on MWBG) is a real-time isometric shooter. Players get to outfit their own mech with a number of weapons based upon the weapons invented and used in the Mechwarrior series, MechCommander series and the RPG of Mechwarrior. Players control their mech with their mouse and a number of keyboard buttons. Holding the mouse button will make the Mech walk towards the area where the mouse is pointing. The keyboard would be used to select the weapon the player wishes to fire or commence an alpha strike (shoot everything you got). The battleground would be open for anyone to connect. The view in-game could be compared to MechCommander yet without the point-n-click effect.

Players in MWBG can salvage any destroyed mech for new weapons or extra armor. There is no end-match in the game the match just keeps on going with people joining and leaving. Over time there could be a possibility to have multiple servers and/or multiple game-rooms.

Depending on the kills the player makes in their career they get ranks which would grant them more weapons and such. These rank/kills are stored by the server.

There would be several game-types available including the normal types for shooter games:
- Capture the Flag
- Deathmatch
- Team Deathmatch
- Assault (1 team attacks, 1 team defends certain objectives)
- Operation Overlord (everyone against the computer army (massive))

Extra features:
- Maps are downloaded by the client from the server (which hosts the current played map). The textures used in the map are checked if they exist or not. If not they are downloaded as well. This allows a really small delivery package to the player (yet has a negative impact on people with a 56K modem)
- Mech/Player properties are stored in XML packages and thus easily sent/updated/modified.
- Voice over IP Support with channel support.

I'd be interested, except I suck at graphics. I don't just "gee, I suck", I'm totally useless with graphics. What language would you be using? I'd be willing to help in VB6/.NET. I'm pretty crappy with G&G programming in C++, but the basic engine I could get going. Also, would you be using a Graphics library such as DirectX or OpenGL? I kinda suck with those aswell, but if I had to I'm willing to learn the 2D part of it, otherwise, in VB I'm pretty good with the graphics stuff (BitBlt, all those GDI apis).

chem

Diablo with Mechs?
Sounds interesting.

Regarding the map, will kit be just flat?
You could add hills, valleys and vegetation to hide behind.

How about supporting weapons?
A mech could call for artillery, maybe spot for the strike.
Or dropships for scenarios like airborne assault, or defend a base until you are rescued.
Assets like artillery, transports or special sensors could also be attacked by enemies and would require protection.

Tips/Advices/etc everything is welcome.

Anyway;
Some technical information regarding the game project;

- DX8 Based Isometric engine
- DX8 Based soundFX/Music engine
- Client-Server protocol (>64 players should be supported dus light-weight protocol over TCP)
- Written in VB6 (or maybe VB.NET), Since VB isn't a real bottleneck anymore and slightly easier to code in VB6 it will prolly be in VB6.
- Class (de)serialisation via SOAP (Sending user/mech classes from server to client)
- Light-weight client due to on-demand data fetching from data-server (seperate server then the game server to balance load) *
- Database connectivity (Server Only) to save/load user data (ranks, authentication)

* By light-weight client I don't mean the actual code in the client but the external datafiles required by the client.

Quote:

---

Originally Posted by jeroen79

Diablo with Mechs?
Sounds interesting.

Regarding the map, will kit be just flat?
You could add hills, valleys and vegetation to hide behind.

How about supporting weapons?
A mech could call for artillery, maybe spot for the strike.
Or dropships for scenarios like airborne assault, or defend a base until you are rescued.
Assets like artillery, transports or special sensors could also be attacked by enemies and would require protection.

---

Well It's all still an idea at this point but supporting weapons have always been a key feature in any Mech game so it should implemented.

For the Assault Gametype things like the ideas you just gave are very nice objectives to begin with. I think that everyone who's addicted or just loves the Mech-scene would find it very cool so see things in the game that they've seen in other games (ie. Dropships, Everyone's favorite mech etc)

The map is still a bit questionable how to do it. Hills and such would be a very interesting perspective regarding being able to hide behind stuff (And being able to shutdown your mech for the time being to really create an ambush).

In Response to your post in the G&G forum:

DirectX isn't my thing, but if you are going to have a game like this (especially with things like hills, vegetation, etc), the best bet would be to use .NET. Inheritance and such, would make the game engine a whole lot easier to control.

chem

Quote:

---

Originally Posted by chemicalNova

In Response to your post in the G&G forum:
DirectX isn't my thing, but if you are going to have a game like this (especially with things like hills, vegetation, etc), the best bet would be to use .NET. Inheritance and such, would make the game engine a whole lot easier to control.

---

I guess so but my .net skills aren't that extremely good. Mmh though it is something to think about. It would be beneficial to do it in VB.Net due to the extra features which in VB6 would require more code to do but then again my VB6 skills are a lot better.

Anyway; I need a friendly bunch of coders to do a number of things including DX (Which partially I can do myself) but there's also the part of the server, the protocol used between the client and server, the database configuration, anti-cheat protection and what ever more comes to mind in the next few days :)

Mmh this image kinda gave an impression.

This is from Mechcommander 2; MWBG would have a static isometric camera and you can only control 1 mech (your own) and instead of clicking somewhere for it to walk to you'll have to keep one mousebutton pressed done for it to run, the other mousebutton to shoot at where your mouse is at.

If you circle your mouse around it, the mech would turn to look at where your mouse is. (To a certain degree before it would actually turn around to be able to look at it)

http://www.games.ru/review/mech2/mech2-2.jpg

Hope that all made sense ;)

Thread merges..hope not too much got cluttered....tell me if anything should be deleted, and I will..:)


- ØØ -

I've just deleted a few posts I've made in this thread, looks good.
Thnx NoteMe :]

Just a few more technical things:

- Code: VB.Net/VB6(?)
(Might be easier in the long run and runs a bit faster then VB6)

- Engine: IrrLicht - http://irrlicht.sourceforge.net/screenshots-recent.html
(Seems to look good, can render terrain and supports the necessary models)
(Also supports normal/detail maps for terrain..)

- Models: MD2? (Edit: Was MD3.. But was not supported)
(So far I could see IrrLicht can handle MD2 models and since Q3 went GPL
we can now finally use it for different projects without pissing Id off.)

- Sound: (There are a number of sound engines available, haven't checked if IrrLight also supports sound)

So... To get an interesting alpha version together a team would be required featuring:

- VB/VB.NET Coders (for client & server) (2+)
- DB Modeller (Can be a coder also) (1)
- Modeller/GFX Artist (Could be one person, if the person knows how to create models and package them into a MD3 with textures) (1+)
- Webmaster (Someone who can fiddle together a nice website with info and such) (1)

(The digit after the description/info is the amount of people probably required)

Anyway - If anyone after reading this thread is interested feel free to join the discussion. It will probably take a few days before a team will actually get together to create a game of this magnitude ;)

I would be intrested, my primary programming language is VB6 and I know it very well, so I can be one of the programmers. Also, I know quite a bit of DirectX.

Quote:

---

Originally Posted by Cade

I would be intrested, my primary programming language is VB6 and I know it very well, so I can be one of the programmers. Also, I know quite a bit of DirectX.

---

Sneak-peeking at your website I see you are indeed busy with DX.. If you wanna help. Be my guest..

--

Question for everyone:
What would be better? An Isometric tiling engine or just a 3D landscape with the camera tilted?

Irrlicht has a basic Sound Engine incorporated into it. I can't remember directly, been ages since I've used it aswell. Something like, Aurora? Probably nothing like it, but yes, it has one.

The models don't have to be compiled to a specific format. Milkshape files (.ms3d) can be saved and loaded without a fuss. Also, skeletal animation makes it interesting aswell.

The maps: Irrlicht supports Quake 3 BSP files (I haven't tried loading a Half-Life 1 BSP into it before, but I assume it would work ok).

Either way, Irrlicht is open source, so if something needed to be added for specific needs, then theres alot of Guru's here who can help :)

Its in C++ btw :|

chem

Oh, also.

The BSP files have collision detection for the camera. So if you load the map, create a camera, and move around, you are ready to go. This is what grabs my attention with the engine. I might scrap my old 2D Vb6 stuff, and start an FPS from scratch if any modellers would be interested.

I can't help at all with anything for a while. My PC blew up a couple weeks ago, and I'm getting a new BEAST (:D) this week sometime.

(Its going to be interesting with my new PC: VS6, VS2005 (VB, C#, C++ and ASP), Apache, MASM, and that old Delphi I love playing around with so much :eek:).

(PS: I just noticed (for anyone who has a life), that if you put fruit juice in front of an LCD screen, the colours which come from the juice glass are cool :))

chem

Well the problem with BSP's in the context of this game would be that the maps would be fairly big if we would have >64 mechs running around shooting eachother.

Though it would make terrain mapping fairly easy :)

Quote:

---

Originally Posted by jeroen79

Diablo with Mechs?

Regarding the map, will kit be just flat?
You could add hills, valleys and vegetation to hide behind.

---

Just Requoting this after all the posts above; It's basically that. Diablo + MechCommander. No barbarians, sorcerers and such but a number (2-64) of players either blasting their way around the map.

I'll draw up a nice pre-design document tonight which I'll post in this thread that gives a clear understanding on what the project contains and the predicted end result. Though there are still a few technical uncertainties and a few facts by now:

Fact:
- We'll use VB6 due to more people being able to code in VB6 then VB.NET
- Initially we'll try IrrLicht and see what happens.
- Isometric view wether it be a 3D view or 2D Isometric Tiling.

Uncertain:
- BSP Terrain or Terrain generation?
(What would be the best to use in such a situation?)

Me, busy, not quite enough as I have been bored for the past 14 hours ;)

A 3D engine with the camera tilted would be easier than an isometric engine IMO.
If you want to try Irrlicht first, that is up to you, but it would best to write a new rendering engine because scince your coders are mostly going to be VB6, it would be easier, more simple to implement, and gives us low level access to all the models mesh data, and the DirectX object itself.

What do you mean by BSP Terrain or Terrain Generation? Do you mean handling the rendering of outdoor terrain or the loading of terrain?

We could use a 256x256 heightmap, enlarge it by 1024 times(or some other number) when you load the map and each pixel from the original heightmap is a bsp node.

I've never tried using Irrlicht with VB6. You can have fun with that part :)

I agree with Cade about using VB6 though. If you are, create the engine, and you won't have the restrictions you normally would (unless the engine allows quite a bit of direct access, however doubtful).

Thats an interesting way to load a BSP Cade. *thinks on that*

chem

A custom made engine would indeed solve a few problems as it would allow us to change/modify or add features that would otherwise be locked out or hard to change due to 3rd party code.

Though development of the base of the engine might take a while and it's kinda required to able to develop the game further. Or any of you are such 3D-Oriented coders that you can develop an engine in a week (I can't).

Anyway - VB6 it is.. and IrrLicht might be scrapped from the list of things to use if we can get an engine up and running.

I'm working on a game design document atm. Will post it here later on when I got a sketch.

Mmh.. Think we need a discussion thread on the project forum ? :]

As promised; The game design document as it is at the moment. Currently a number of things I haven't written down yet due to the limit of time I've got today. Expect an update soon =)

Feel free to leave a *lot* of comment regarding the document :)

I will try to get a 3d terrain engine up and running using my AgrDX framework, I will post the results here. Also I will try making the terrain as large as possible :)

Don't ask why the skybox is a large grass texture :afrog:
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.

The sky looks indeed very... green :)

Mmh. and that's only 128x128.. So if we went insane a 1024x1024 heightmap could hold up +/- 512 players (if the server can actually keep up with that amount of bandwidth required)

With the terrain engine, any special things (graphics-wise) in mind? Normal/Detail maps etc?

The terrain map can be stretched. Actually with that scale, using a map as large as 128x128 is too large, 64x64 seems to work nicely. ;)

Also, performance wise, it is chugging along slowly! The map is made up of 16384 vertices, and is running at 31 fps on my 9800 Xt. Unfortunately, I have no prior experience with outdoor/terrain rendering in DirectX. I'm going to ask around in the Games and Graphics section about rendering...

31 fps.. on what resolution?
Implementing LOD might be a good idea to increase the FPS a bit.

And semi off-topic:
What type of models are going to be supported? MD2/MD3?
(The top part of the mech should be able to turn left and right to look (to a certain extend))

Small addendum; With such a small heightmap it might be difficult to add detail in the landscape (Canyons etc). Maybe a bigger heightmap (512x512) and less scale so that a certain degree of detail could be implemented?

Just an idea.

I've always found small steps when creating a game is good :) When I wrote my crappy old FPS in Irrlicht on a Quake 3 map (even though it was extremely whack), I still wrote it in steps. For example, first was camera movement (keys), second was combat (really just shooting), third was bot combat, fourth was bot AI (movement, etc). After creating a type of waypoint system, I noticed that neither of us died after being shot the hell out of. Which I then went back and implemented.

My point being: Perhaps detail isn't important this early in development :)

chem

31 fps, 800x600. And a canyon can be implemented quite accurately, I have tried that. Even with a larger scale.

Very true. I'll be patient - Though I wanna start coding as soon as possible too :)

Anyway; I'm gonna create a thread in the project discussion group as this thread is getting more and more to the point of being a project discussion thread then a 'Game Idea' thread :)

Lets continue our conversations here:
http://www.vbforums.com/showthread.p...91#post2144591

I am not sure if this is going to be any help to you guys. What is your monsters looking like? Like the first screeny there?


At least I was looking for an airplane (don't ask me why) when I came over these free 3D models. So I thought I would share them with you in case that is what your monsters look like:
http://www.turbosquid.com/FullPrevie....cfm/ID/161495
http://www.turbosquid.com/FullPrevie.../161495/blFP/1
http://www.turbosquid.com/FullPrevie.../161495/blFP/1
http://www.turbosquid.com/FullPrevie.../161495/blFP/1


- ØØ -

http://www.turbosquid.com/FullPrevie.../236682/blFP/1 Better madcat imho :)

But that's a bunch of mechs that are really useful to test the engine with. Now we just need someone who's good with 3dsMax :D

Anyway ehh.. Use the other thread :D