Well, I''ve started a similar thread on VB Forums, but people recommended coming here. Anyways, I''m planning on creating a 2D RTS game in VB. Why VB?? Its only language I have/know. Ok, about the game, its going to be Aoe like, but set in World War 1, and/or 2. Its going to have Land, sea and air units,exactly what, I''ve yet to decied. Obviously, its based on Earth. And, at the moment, no Map Editor or Multiplayer is planned. Sooo, the plan of attack that has been recommended is to use DirectX (is there anyother way?? ) Now, can someone point me in the direction of a game engine or a tutorial that I can use to get things started?? I''d prefer a predone game engine, as I''m still relatively new to VB, and I''ll get bored if I think the project is going no where. Anyways, Thanks in Advance.

First let me say I am not an expert at anything, but if this is your first game, try something ALOT easier (pong, tetris, that sort of game) because every aspect of AoE is infinitely more complex than pong or tetris. The pathfinding for one, could drive a person insane (i know). Can you do it? of course... Is it likely you''ll complete it before you strangle someone? probably not... If this is not your first game and you do think you''re ready for a game of this size, then here is a link that may help:

http://rookscape.com/vbgaming/


- Free Your Mind -

I strongly recommend learning the very basics of directx programming, and i really think you should learn c++. I know that a few people have made a couple neat games with vb, but C++ is definatly the way to go if you''re planning to create games. The beauty of learning directx, and THEN programming a game, is that you can create your engine as you go along, adding things to it, instead of using a pre-made engine. Pre-made engines are usually made to please the person who made them, so you might be hard-pressed to find an engine that includes all of the things you want it too. And, without learning directX first, you won''t know what you want and what you don''t want.


Just a suggestion.

- Fuzztrek

¬_¬

I disagree with your language of choice. VB is fine for making smaller games, but an RTS is a massive project; much, much larger than you would imagine if you''ve never made a game before (I hope I''m not wrong in assuming this). VB will quickly bog you down and leave you with crappy and unusable code, since it was never designed for games.

So my suggestions: try and make a simple game (in VB if you want). Tetris is good. Pac man is even better (but much harder). It won''t take too long, and you will learn how complex it is to make a game. Then think about whether or not you want to make an RTS right then

I reccommend that you learn C++. It''s the only commonly used language I know of that can handle colossal projects like an RTS.

Oh vb being a form of basic is a hell of a lot slower than something like c++. Being a beginner I assume you ain''t that amazing at optimizing VB code so your rts would probably run slow as hell. I''d do it in c++(after learning all the stuff you need to know)

Well...

At the moment, VB is the only language available to me, so thats going to be the language that I''m going to make stuff in.

Why the premade engine?? I''m not bothered about adding stuff later, and, I could really use an example, get the basics going, and then get into making my own engine down the track for a more polished version of the game.


Ok, well, I am aware that the game will probably chug in VB.. but for the first version, I guess it doesn''t really matter. Hopefully, if the game gets half decent, then I might consider sticking it into C. But, until then, VB it is. :D

Pc_Madness, have you read this article?
www.gamedev.net/reference/design/features/makegames

I''m making an RTS in vb (check out the public alpha at emoticonvb.cjb.net). I would definately not recommend that you make it a first project, but I would also not write off VB as being slow. If you know how to code, and exactly what your code is doing, then you should go fine. With that said, here is the advice I copy paste everytime someone asks:

quote:

---

First bit of advice: The design is basically the game. I wrote Emoticon a while ago, and while it was functional, the design was pretty poor. I was afraid to add new features because it might screw something up. Instead of trying to hack it back into working order, I rewrote, and in around 2 weeks, I had a game which surpassed the original both performance-wise and completion-wise. Don''t be afraid to rewrite, it is one of the best things that ever happened to Emoticon.

2) Avoid having public variables. If it looks like they would be useful, then you have probably done something wrong. There are about 3 public variables in Emoticon, MousePos, MouseButtons and MouseShift. They are only put in this way because there can only be one mouse ever.

It would only take a tiny bit of fiddling to get two separate games running split screen independantly of each other. Most of the map editors code is shared with the game engine, and it would also be possible to have a map editor and a game running concurrently split screen with minimal effort.

3) Don''t hardcode anything. I haven''t exactly followed this advice (the position of the buttons in my menu is hardcoded)... but it is still good advice. Try and load all data from external files.

4) Write modules/classes so they can be used between all the different programs related to your game. A couple of generic things are really useful, I have modFileFormat which gets included with anything that needs to read/write a game specific format. It provides all the functions I need for all my formats.

5) Write good tools. I dedicated a couple of days to getting my tools just right, they need to be quick to use and be friendly for making tiny tweaks. Case in point: The Font Editor is used for defining the sizes of each character in a font. This involved loading a font bitmap and going through each character and setting a rectangle to cover the whole thing. After doing this for 2 fonts, I realised that it was a very repetitive process, so I put in a button which would automatically find the boundries of a character and put the rectangle around them. Manual tweaking is still possible (for stuff like spaces), but the time saved is great.

6) One thing I did differently to most VB games is use my own graphics file format. This resulted in slightly smaller file sizes (it wasn''t compressed, but it wasn''t bloated like bmp files). I''m not sure if I would recommend it or not. It has limited benefits, but also limited negatives. The format was fairly friendly for my graphics packer, which made creation and extraction of the graphics file easier. The only thing which was a bit harder was writing my own function for loading the graphics onto a surface, it wasn''t much of a biggie, but it isn''t written as well as I would like so it is slightly slower than the usual loading from a bmp file. If you intend on doing a bit of image pre-processing in game (such as changing colours of units), then it would probably make things a bit nicer. Also, if you want to include some type of compression, then go right ahead. I don''t have a heap of graphics, so I don''t really care to do it

7) Decide how flexible you want the game to be and stick to that. Originally, Emoticon was going to be run on its own VM for the ultimate customisability... while it would have been cool, I doubt I would be finishing such a game very soon given that I''m a one man team. Flexibility is great, and usually goes hand in hand with good design, but it also takes time to get it just right.

8) Log files. Include a log file from the very beginning of your project. That is, a function which will write something to the log file such as "Initialising Graphics Engine..." type thing. These can be invaluable if you ever get a freak crash or problem during start up. Because these are outside tight game loops, you can afford to make these detailed at the expense of speed. Have nice error reporting functions which describe what the error was, where it occured and what the plan of action is . E.g: "Error: Device Lost in modGraphics.BltFast. Restarting Graphics Engine..."

9) Stop bugs early. If you have a bug, stop everything else and fix it first. The more you code, the more that bug is being worked into your code and the harder it will be to find and fix.

10) Compile with Control+F5 all the time. This will catch a lot of errors and stop a couple of stupid compiler bugs from cropping up. It is a little bit slower, but it will pick up errors before it actually runs instead of booting you out of your game halfway through to tell you that there is a syntax error.

11) A useful thing I did was to have a conditional complilation mode where the game would play in 1024x768 resolution. Instead of showing extra map and stuff, I filled the extra space with debug info. This is really useful - it doesn''t interfere with the game, and can tell you what is happening behind the scenes - what the AI is thinking or whatever.


Ok, that is enough general tips, now the structure. Here is what I have:

Forms:
frmMain:
This form does nothing . Just provides a hWnd for DirectDraw. It is bright green so I can tell if it is showing

Modules:
modAI:
Handles enemy level AI. Called once a frame and at the beginning of the game. It just gives orders to units, it doesn''t know how to actually act them out.

modFileFormats:
Loads/Saves all file formats the game uses. A lot of these file formats aren''t used in the actual game but only for tools, but they are still here.

modGameConsts:
All constants which apply in lots of places I declare here. These are public constants, and while I warned against public Variables, I would happlily argue that these are fine . Public variables are bad because you can''t have 2+ instances of them. There is no need for two instances of a constant because... it is a constant.

modGameData:
This stores information and statistics about all the different units and stuff like that. Works with modFileFormats to load the info and then provides it on demand. The stuff here is the info which is true for *all* units of a particular type, not individual units. So the animation frames to use are stored here, but the actual animation frame being displayed by a particular unit is stored elsewhere.

modGameEngine:
This is where most things happen. This module handles the logic behind creating a map, selecting units, ordering units, making units follow orders and drawing the map. Note that this is the logic behind drawing the map, not the actual drawing, it says what to draw where, but doesn''t know how to draw anything.

modGraphics:
This module is a DirectDraw wrapper, I use it for most of my projects, it is able to load my custom file format too.

modGraphicsOrganiser:
This module handles all the different graphics I actually use. Because everything is packaged together, the order of graphics in a package can change. This module will line up a request with a valid surface to use.

modInput:
Mouse and Keyboard input is caught here.

modMain:
Housekeeping sub. Has stuff like the Log file functions and most importantly, "Sub Main". This means that if I wanted to include a splash screen or something, I would call it from this module, it dictates the highest flow of the game.

modMainMenu:
This module will display the main menu and return the menu item clicked. That is all

modMapEditor:
This module will display the map editor and let it do its business. Once the user clicks ''Exit'' it returns to whatever called it.

modOptions:
This module displays the options menu and handles the setting of the options. Woo.

modPathfinding:
Feed this module a map and a point. Tell it how many units will be using the path. This is called each frame with a number telling it how many cycles it can do, once it has used up those cycles, it returns. Next frame, it is called again and resumes from where it was in finding a path (usually it takes about 2-3 frames). It can handle multiple requests for paths too. Once all the units are at their destination, they tell this module, and when all the units are done, it will erase the path from memory.

modUDTs:
This is where I define all the UDTs the game uses, the main UDT is udtMap, one of these holds an entire game. I''ll post a snipped version of it here so you can see what type of stuff it has:

Type udtMap
Map() As udtSquare ''The map
Size As udtPoint ''Size of the map (in squares)

Scroll As udtPoint ''What to offset drawing by (in pixels)

Bullet() As udtBullet ''Bullets on the map

Object() As udtObject ''Objects on the map

Unit() As udtUnit ''Units on the map

Selection() As Long ''Units selected

Marker() As udtMarker ''Markers being shown on the map

Path() As udtPath ''The paths in use (paths as in pathfinding)

AIMasterPlan As udtAIMasterPlan ''The mind of the devious AI

Tick As Long ''What frame of the game we are in

MapName As String ''Name of map
MapDescription As String ''Description of map

WinningState As udtWinningState ''What the player needs to do to win etc
End Type

One thin I have snipped out is that for each array there, it actually reads:

Blah() As Whatever
UBoundBlah As Long

Instead of using UBound(Blah), I use the variable. When I go to Redim something, it looks more like this:

UBoundBlah = NewSize
If UBound(Blah) < UBoundBlah Then
Redim Preserve Blah(UBoundBlah + BLAH_OVERDIM)
End If

This dramatically cuts down the number of Redims I do with a tiny memory hit (I''ve also left out the ''getting smaller'' code). Depending on the array, the _OVERDIM value can range from 1 to 50. Smaller for things that rarely change and larger for arrays which are constantly being resized.

The other benefit of a having everything in a udt is ease of writing code to save/load. A sample function from modFileFormat:

Public Sub SaveMap(Map As udtMap, FileName As String)
On Error GoTo ErrorHandler

Dim FileNum As Long

FileNum = FreeFile
Open FileName For Binary As FileNum

Put FileNum, 1, Map

Close FileNum

Exit Sub
ErrorHandler:
ErrorHandler FileNum, "modFileFormats.SaveMap", FileName
End Sub

It is very similar for the other file formats.

modUI:
This module can display buttons, labels and images. It also handles their behavior. For all of the buttons, there is a function pointer stored with them (found using the AddressOf operator). When they are clicked, the function is called. Pretty much identical to the way VB buttons work except these are created through code and need to be constantly redrawn.

---

There might be some stuff in there which is specific to a certain person, but I''m sure you can get the gist of what I''m saying.

Trying is the first step towards failure.

quote:

---

At the moment, VB is the only language available to me, so thats going to be the language that I''m going to make stuff in.

---

Why can''t you use c++? If you have a net connection(as you obviously do) then why don''t you get one of the many free compilers out there. You don''t have to use Microsoft Visual C++(which costs money).