well Havok(tm) is too expensive ;)
Printable View
well Havok(tm) is too expensive ;)
I dont think they would give it to us even if we had da money! They only sell it to high level companies to have a good name ya know!
screenshot in post #227 looks very nice, can't wait to fill it with rockets and smoke :D
Hehe, soon my young apprentice.. soon :-)
Large Update
---------------------------
Topics:
1. MWBG will be renamed to Capellan Conflict - Logo update and such follows.
2. No more Irrlicht due to several features that are not incorporated well.
3. Change of plan completely for the game-basics.
1
MWBG will be renamed to Capellan Conflict due to the fact that Microsoft wasn't all to happy about us using the name MWBG.. (Had to send them a mail about it as Wizkidsgames only has the IP for the irl board-games.)
2
No more irrlicht.. Yes.. no more irrlicht.. This has to do with several features of Irrlicht that aren't finished and I got bored waiting for them. Some people on the forums there did give some hints and advices on changing it or finishing it but that would require recomplilation of Irrlicht. The other reason is seen below @ 3.
3
A change of plans.. Actually just back to the basics of what I planned before 3d came into the scene. More about this plan will be posted soon when I get a decent idea written down. :)
Hi there...
Updated main title .. new logo soon :)
ToDo:
- Game Design
- Game Overview
- Getting a big ass ToDo list :]
Small overview:
Capellan Conflict
Overview:
Capellan Conflict is an isometric 2d/3d hybrid action shooter. where as the player will enter the battlegrounds and fight for their survival or for the survival of their team. The game features a range of mechanized units and the ability to go on foot if the player wants to. The game has large open maps based on hi-tech surroundings and desert landscapes depending on planet/cityscape/etc. The game is multi-player biased. Players can play against bots but the main feature of this game is to play against or together with friends online.
A gameserver depending on hardware and connection speed could host up to 64 players.
The basics:
Code:
The game codeline will be written in VB.NET and parts in C#.
Graphics:
The game graphics will be sprite-based. 2D / Iso-tiled textures. Models will be sprites thus not using any model-structure like md3/md5/.X/etc.
Engine:
Engine has to support a large number of 2d/iso/3d functionality. Features including stretch/crop/skew/rotate/alpha etc. All textures would be in either TGA/BMP or PNG.
Audio:
Support for OpenAL (and thus EAX/A3D) (off-screen sounds can be dampened etc)
Input:
DirectInput (Key/Mouse). Controls like Diablo II
Requirements in the team:
For starters:
- 2D Artists (Textures/Sprites)
- VB.NET/C# Coders (Iso 2d engine, Audio handling, Input handling, AI, Network, Game basics, Scripting)
Bit of explanation:
Iso 2D Engine : Development of the 2D Engine so that we can actually show something on screen is a good starting point, The 2D engine should allow location hotspots (mouse) and height-detection.
Audio : A developer with knowledge how to use and access OpenAL subsystems via VB.NET or C# (if C# also knowledge of exportable functions would be nice)
Input Handling: Input handling in regards to in-game and gui handling. A fast and stable way of having the player be able to control the in-game character. Mostly also done by the persons dedicated to the 2d engine.
AI: Artificial Intelligence for Single player mode and maybe bot-support for online games. A* Pathfinding, Scriptable events/triggers etc.
Network: As said in the overview; The server should be able to handle atleast 32 but pref. 64 players at once. This requires a stable and light-weight game protocol.
Game Basics: The basics for the game to run on; How the world reacts, firing, etc. Basically the game itself in the pure-content form.
Scripting: Scripting for the AI and maybe interesting things for maps. Doors/Gates/etc. The developer(s) for this section have to write both parser and script style/syntax.
Addendum: The reason why the Irrlicht version (3D MWBG) didn't continue was mostly due to missing features in IrrLicht which came to pass too late in the process and the reason that the team missed key feature people like modellers/texture artists and so forth.
Now that we are back on 2D/Iso grounds the availability of people that are able to help has increased slightly to a more favorable percentage ;)
Well, then shall I start on a 2D isometric engine? Also, while I'm at it, anything you want me to add to AgrDX.NET? Scince it's 2D, I can use more advanced shaders than I could ever have in 3D, such as fire using texture perturbation. The only way to get that in 3D is billboarding.
Edit: I'm not going to start this time, I'll leave it to you to create the base. Or should I create a really really empty shell project?
Example
In frmMain,
modEngine.LoadMap "Base\Maps\Blah.map"
modEngine.Render
And in modEngine, all the code related to a 2D isometric engine, in terms of the renderer (terrain handling, detecting the height, etc) and a camera.
Also, what do you want me to call each module/class and what do they contain?
Note, I'm better at using classes now ;)
The 3D first-person engine I am working on has almost all of it's code in one class or another.
And just to clarify, you mean isometric in this style?
Red Alert 2
Red Alert 2, simpler terrain
I'm fairly sure I can start on the terrain engine, once I get some specs :)
Edit:
Whoa, that's gonna be really hard :rolleyes:Quote:
Features including stretch/crop/skew/rotate/alpha etc. All textures would be in either TGA/BMP or PNG.
Well I didn't say that would be hard and yeps, kinda like C&C series etc. :]
Right, well, should I start on the blank shell then? Blank shell with terrain engine. Also, specs please! Specs on the map format and the sprite format.
Edit: Not a blank shell, a minimal project with a module containing the terrain engine, using AgrDX.NET (Pretty much the same as the version in the tutorial, minor differences in the new version, only been a week).
Yup, start creating a small base to work on; At this moment we can still seperate most of the work till it gets to a point that we can to sync and combine. Tonight I'm gonna try and setup a real CVS system so we can easily check-in/check-out sources.Quote:
Originally Posted by Cade
Empty shell project for starters; Most of the work I'll be doing right now won't be requiring any baseline yet.Quote:
Edit: I'm not going to start this time, I'll leave it to you to create the base. Or should I create a really really empty shell project?
Anyway firsts things first and that's getting an Isometric engine and some gameplay basics. Oh and try to think up a good way for the texture pool, I would love to see a sorta use of keywords to load 'm up instead of filenames.
Engine.DrawSprite("AVENGER_UNIT", 200, -2000, etc etc., AVENGER_UNIT would be loaded somewhere in the init phase with Engine.AddToSpritePool("AVENGER_UNIT", AppPath & "\Data\Sprites\Avenger\Avenger.tga", etc etc.
I'll leave that up to you :-)
I'll get started sometime later today. Come on MSN a bit more often ;)
Got any sprites I can use as templates? I'll just use a grass texture for the ground, for now.
Edit: HLSL shaders (Read: pixel shaders), yes/no? (Say yes...)
If I use multitexturing for different textures based on height(or what is defined in a editor which will be made in the future :afrog: , water, grass, mountain textures), we will be limted to 8 textures which should be enough unless you plan for some wacky maps. I would like to not go multipass, so it's 8 texture's for the terrain at any 1 time. Keep in mind, this includes stuff like clouds casting on the ground.
So, textures in use at any 1 time, for terrain, in the test map I will make
1. Water
2. Grass
3. Mountain
4. Clouds casting shadows
Still got 4 slots free for whatever we think of.
Blank project;Quote:
Originally Posted by Cade
Specs.... Specs...
Maps ranging up to 1024x1024 cells (cell size would be 32x32px?).
Sprite format:
Offset-based. so one TGA holds all the animations for that partilcular animated sprite. A xml or info file would hold certain information regarding the sprite... kinda like:
INI-style ;)
Useful? Or should be try a different approach?Code:
[Avenger]
SpriteFile=Data\Sprites\Units\Avenger.tga
SizeX=32
SizeY=64
AnimationBlock=AvengerAnimation
[AvengerAnimation]
; Start Offset - End Offset - Row!
WalkingNorth = 1-10-1
WalkingNorthEast = 1-10-2
WalkingEast = 1-10-3
WalkingSouthEast = 1-10-4
WalkingSouth = 1-10-5
WalkingSouthWest = 1-10-6
WalkingWest = 1-10-7
WalkingNorthWest= 1-10-8
[/code]
No MSN here at work but I will come online more often when I get my laptop tomorrow which allows me to work at home more often ^.^Quote:
Originally Posted by Cade
INI-style?
...
Here is how I do config files in my 2D game engine (sidescrolling, so its not usable here)
DefineName|Player
//DefineAnimation|Name, Sprite, MeshArray, FrameW, FrameH, SpriteW, SpriteH, AnimSpeed, LoopFromFrame, CollisionScaleW, CollisionScaleH
DefineAnimation|Idle,Sprite\Idle.png,IdleKF.mesh,34,36,34,36,0.05,0,0.75,0.95
DefineAnimation|Running,Sprite\Running.png,RunningKF.mesh,44,36,484,36,0.2,3,0.75,0.95
DefineAnimation|Jumping,Sprite\Jumping.png,JumpingKF.mesh,29,52,87,52,0.2,3,1,1
DefineAnimation|Falling,Sprite\Falling.png,FallingKF.mesh,29,44,87,44,0.2,3,1,0
You get the general idea. Or XML, give me a XML reader class/module and I will design it around that. :)
First priority - Terrain engine. In my post above, I edited it, so please read it.
Not really; I'll have a look around but feel free to use some weird colorful block for testing purposes or some weird manga character of which there are multiple around on the internet ;)Quote:
Originally Posted by Cade
Yes.Quote:
Edit: HLSL shaders (Read: pixel shaders), yes/no? (Say yes...)
8 textures per pass or a total of 8 textures per texture-mapping for the terrain? If we allow cloud-casting we basically have 7 textures per pass max. which should be more then enough (as this excludes decals as they are passed on as shaders?)Quote:
If I use multitexturing for different textures based on height(or what is defined in a editor which will be made in the future water, grass, mountain textures), we will be limted to 8 textures which should be enough unless you plan for some wacky maps. I would like to not go multipass, so it's 8 texture's for the terrain at any 1 time. Keep in mind, this includes stuff like clouds casting on the ground.
I think will prolly fill 'm all up at some point :)Quote:
So, textures in use at any 1 time, for terrain, in the test map I will make
1. Water
2. Grass
3. Mountain
4. Clouds casting shadows
Still got 4 slots free for whatever we think of.
XML is standard issue in .NET.. But I like that style of defining the animations.. :)Quote:
Originally Posted by Cade
What I'm going to make...
1 - Load and render a heightmap.
2 - Textures (basic)
3 - Camera
More soon... :)
Edit: Note, that the paths in that are not based on the main folder, but the folder of the NPC. Each NPC has a sub-folder in the main NPC folder. It's much more easy to manage.
Check. :)Quote:
1 - Load and render a heightmap.
2 - Textures (basic)
3 - Camera
Aye, true.Quote:
Note, that the paths in that are not based on the main folder, but the folder of the NPC. Each NPC has a sub-folder in the main NPC folder. It's much more easy to manage.
A small addendum on this would be to put the resource directory outside the source directory..
It's a bit easier on the CVS system that way =]Code:<Root>
|
|\ Bin
\ Data
Expect something tomorrow, I'm not going to be able to do much today.
Ps. Due the nature of VB.NET we can seperate a bunch of stuff in different DLL's which make it easier to compile/update for clients?
Yes, if you really want to. But, I would prefer not to. So, I'm about to start on a blank project. CCTerrainEngine, should I call it that for now?
CCTerrainEngine sounds good;
Seperate DLL's why not? Having everything in the main is app is going to be one hell of a chaotic mess to deal with later on. Having several seperate areas makes it all manageable.
\OpenAL32.dll :p
\Script.dll
\RendererDX9.dll
\Network.dll
etc.
Most stuff will be in classes anyway so whether they are in the main app or in dll's doesn't really matter.. having them in dll's just makes it all a bit more 'neat' (not in the context of cool btw)
And thnx to VB.NET they ain't COM-Objects and thus don't have to be registered before use.. (yay)
Fine, so I can have all my rendering stuff in 1 dll and keep my sanity if you will please keep out of it? ;)
Update: RendererDX9
Referenced from an empty shell just to give it a front end.
Got a (stupid) question to ask... when I use a .dll, what event is called when it's bieng unloaded?
I won't touch it.. =)
Mmh, only got Vb6 here at work - I think it was something like Finalize?
Edit: A bunch of info on classes in VB.NET vs. VB6 http://www.developerfusion.co.uk/show/1047/3/
Ah heck, nevermind.
Public Class clsRendererMain
Public Function Init(ByVal frmHandle As System.IntPtr) As Boolean
Return DXInit(frmHandle)
End Function
Public Sub Dispose()
DXUnload()
End Sub
End Class
Works well enough :)
Yep - Works as well; The main app has to make sure that it cleans up and de-inits everything before quiting - and calling System.GC.Collect after that to force clean up.
Process flow chart... simple version :]
Cade: Little side note - Don't worry about the choosers too much for now ;)
Where we are:
Main Application->Renderer (Sort of)->"Work in Progress"
:)
Edit: Working on a heightmap, expect more news in 20 hours from now.
Isometric, must the tiles (of the map) be rotated so they are diamonds from the camera's point of view, or squares? It'll be a LOT easier for me to work with squares.
isometric is mostly diamond shaped..
http://en.wikipedia.org/wiki/Isometric_projection :p
Going for square-drawing makes it a hell of a lot more difficult regarding things like a map editor later on.
Then I'll use diamonds then. If all axis are rotated to 120 degrees, when loading the heightmap's vertices, I can just rotate 120 degrees with a matrix. Expect a first screenshot tomorrow, or in about 20 hours from now :)
My ToDo list:
---------------------------------
- CC Logo
- Getting CVS up and start creating usergroups/users.
- Getting Baseline code up and running (several different branches)
- Basic web-site on http://cc.pineapple-nl.com or http://www.capellanconflict.be (48 hours max for registration. CC.pineapple-nl.com works already.)
- Setting up DB Table structure (User table with registration and such)
- Basic Network/Mysql Connection via Client (DLL)
- Writting better gamedesign document with information regarding gameplay style.
- Getting more people to the team (GFX, Coding etc)
http://cc.pineapple-nl.com -or- http://www.capellanconflict.be (in 24 hours) - .be domain will point to pineapple which is my own domain which will also host the mysql database for data storage (like player info/authentication later on)
New logo @ page 1.. (or just below this line ;))
http://cc.pineapple-nl.com/images/vbforumscaplogo.jpg
URL : http://www.capellan-conflict.be/ :)
Might require a DNS update so if it doesn't work instantly.. wait a few hours for it to be propagated between several root dns servers...
ToDo Status:
Done:
- CC Logo
- Getting CVS up and start creating usergroups/users.
- Basic web-site on http://www.capellan-conflict.be
- Wallpaper @ http://www.capellan-conflict.be/wallpaper/wallpaper.zip
Busy with it:
- Getting more people to the team (GFX, Coding etc)
Not Done:
- Getting Baseline code up and running (several different branches)
- Setting up DB Table structure (User table with registration and such)
- Basic Network/Mysql Connection via Client (DLL)
- Writting better gamedesign document with information regarding gameplay style.
Devion - The CVS link is a 404. :)
*blinks* oops.. it's being re-uploaded now. :)
instead of using CVS, i would suggest using Subversion .
Port 2106 right?
capellan-conflict.be Port 2106
With the user & pass you sent. It doesn't work, I can ping but it does not connect and log in.
I'm going to start on the engine again now, expect a screenshot within 2 hours if all goes well.
Must the camera be fixed? Or can the camera freely rotate? It would be good to let it rotate. For that, the terrain will be 3D and the sprite will be 2D. In 2D, there are many limitations. For example, if a mech is behind a hill.
So, 2D terrain or 3D terrain with a camera that can only rotate sideways, not move/rotate up/down?
No not capellan-conflict.be, use the IP in the pm I sent you. The CVS system runs on my own little server, the site runs on a co-location :)
Subversion.. Been there done that.. Didn't like the feel of it.
Edit: CVS IP: 80.56.5.90 (2106)
As in any isometric game if the player is behind something it will show-through with Alpha. This also gives an advantage in-game as they can sneak up on people ;)Quote:
I'm going to start on the engine again now, expect a screenshot within 2 hours if all goes well.
Must the camera be fixed? Or can the camera freely rotate? It would be good to let it rotate. For that, the terrain will be 3D and the sprite will be 2D. In 2D, there are many limitations. For example, if a mech is behind a hill.
So, 2D terrain or 3D terrain with a camera that can only rotate sideways, not move/rotate up/down?
So 2D Terrain (Height in 2D is done by just a larger height texture.. ie. 32x64) and the camera should be completely static it just has to keep the player unit in the middle of the screen.
"Unknown username, wrong password or invalid client IP"
User & Pass are the same you sent me in the PM.
Your FTP server works fine :)
Scince we will not be doing 3D, I can use the ZBuffer for back-to-front rendering from an isometric point of view.
weird.. I'll check it out when I get home (which will be somewhere around a few hours from now..) :]
Any idea yet how you are going to store map data? what properties and such in the struct? - the reason why I'm asking is that I'm starting to think about the editor a bit so we can easily create maps for testing purposes and at the end have a full-blown map editor for the community ;)
Heightmap, .png/.bmp/whatever format you want. And some form of scripting for placing items like trees.
Heightmap is going to be difficult for something like RA2 Style maps (they are built from isometric tiles) or atleast look weird when objects are placed on top of it.
I was more thinking along the lines of having it actually isometric tile-covered landscape - take Ra2 or any -Craft games for example. The suggestion of height is done by the textures used but basically it's as flat as a pancake ran over with a streamroller. (Showing off some rock in a grassy field gives a bit of height perspective)
Rather silly example:
http://web.oroboro.com:90/rafael/gba/image/wooted_s.jpg
Got a basic terrain up. Now trying simple N.L lighting, vertex colors. A screenshot will follow after that. ;)
Got N.L lighting working, but it's not smooth (Faceted. Each tile has a different normal, so the lighting does not smoothly shift from one tile to the other). I'm going to try a bumpmap for normals later.
Okay - I'm gonna work on the Baseline code today and going to work out a way to get an audio engine up and running, script engine system and maybe the mysql connection worked out :)
No offense, but I'm not too confident we will actually find a 2D sprite artist.
Dont worry too much about that - There are more pixel-twiddlers out there then d modellers, plus I got a few people I know that might be interested to do some work so by the end of the week we might have a few.
I'm having some problems with lighting. I can't really remember what I wrote in my "outdated" terrain engine, so it'll be some time before the first screenshot. But, the first screenshot will look pretty good.
per pixel lightning? :p
No perpixel lighting until I get normals working. Once I get normals working, simple N.L lighting will suffice for a screenshot. Once I feel like sticking in a HLSL shader and we have point lights instead of just directional lighting (the sun), there will be perpixel lighting. ;)
But I still prefer to work with 3D...
Well you are working with 3D - considering Dx9 doesn't actually have a DirectDraw class anymore ...
If we create a sturdy isometric renderer most problems will go away 'instantly', at that point things will get a lot easier as we can easily see results. So just hang on in there - you'll figure it out :) (I can remember something about you saying you were a DX2D guru ;))