Isometrics, the framework for my next game.

My last attempt at a game (an RPG), was defeated by the fact I didn't have my own character images to use. I suck at drawing, so I hit a dead end.

Drawing simple isometric shapes (even having the code do it for me [I specify which 'cube' it would belong to x, y, z postion, specify the shape type, rotation, and color]), is a definite possibility.

Also note, this game, or whatever I create will be in C++ Win32 GDI (I may want to evolve to DirectX, which I am not sure if I could learn... but the reason for that, is I want to be able to create a map field outta isometric shapes, and be able to view it at different angles, so each shape would literally be its own 3D object.) I would also need to learn some basic lighting. (If I used Win32 GDI, the map field would have to be for the majority static (maybe it would sidescroll.) I would not be able to get any camera angles, and the shapes would just be drawn to appear 3D.

So far how difficult does this sound? Supposing I go with the DirectX route?

Next, once I have classes written to handle the main game (and its map field [which I am not sure how to go about storing]). I would write an engine to draw the various isometrics shapes at given points.

In the main program [I can only speak for the GDI route] I would have a mapShiftX value, for sidescrolling purposes. The main paint method would draw everything to the buffer [DirectX may be different, or I may have to write a new double buffer] ~ It would loop through the map field data, taking any map shifting into consideration, and it would draw each shape 1 by 1.

I will have to predefine how much of the map to show at once, so I can add logic to determine what and what not to draw.

I would have a timer setup in the main program for every 50ms -> 20fps.

The timer procedure would call the function which draws the screen to the buffer with the data the program has, and it would copy the buffer to the screen. (Again, DirectX maybe completely different.)

And wala, I would have my map rendering engine done. It wouldn't have any functionality, but it would be cool to play with.

Next, I want to add a little spherical "marble" (Later I may upgrade to a skateboard , but that requires A LOT more calculations). Anyways, the marble will start at a specific point (specified somewhere in the map configuration).

Also note: This entire thing is based on likely 32x32x32 cubes, each one transformed to appear isometric, and each cube will contain 1 isometric figure. The marble will also have the same dimensions, or if you will, a radius of 16.

Now it gets a lil tricky. I want to use the mouse to tilt the field, if I get 3D with DirectX I could probably get a great deal of rotation, of course I would probably need a great deal of help on calculations.

The marble should react realistically, how difficult do you suppose this will be to accomplish? I mean, tilting the screen in all different directions has to be realistically simulated...

Plus that is just accounting for the marble rolling on a flat field, with no barriers.

I will need a lot of logic and calculations for the next parts, especially if it is going to be simulated properly:

First, the variations in slope of different isometric shapes. For example I would have 45 degree slants, plain old cubes, curved object, 30 degree slants, etc. The slants will have to adjust the balls position accordingly, and its velocity as well. The curved object will be the hardest. I have no idea how I would go about figuring out where to position the marble, or how to adjust the velocity accordingly.

-If I get replys or any interest in this, I will draw up the map framework and a field example in photoshop.

Next would be the collision detection. This would be especially complicated by the field rotating. (Well, if the ball never leaves the surface of the field, I guess it is still basic what x,y,z cube your in). But if I wanted the ball to be able to catch air off a ramp or something, then what? And how to go about simulating gravity?

Oh, yes, I have a lot on my plate, but if I do this right, it could be so sick.

Any input on this? Anything at all .

I might be in way over my head, but I know I can at least get the basics done without much of a sweat... so that would be a start. But I gotta know, should I go ahead and try learning to use DirectX?

Definitely a good idea to prototype your game engine with geometric shapes first but your descriptions give away that you don't really know what's involved in making this game and are basically guessing... Which is fine, some of your guesses are in the right ballpark.

Go down the DirectX route - learn the basics and you will soon grasp how 3D game programming really works and see that some things you thought would be very hard are actually very easy (camera positioning/rotating) but other things you thought would be quite easy are maddeningly difficult (collision detection) but overall once you understand the principles and the (really easy) maths involved you'll find it easier to get results with Direct3D than with GDI.

You sound like you're already comfortable with C/++ - GOOD - Work your way through all the tutorials on www.directxtutorial.com doing ALL the exercises and not copying and pasting any of the code and if you're dedicated you'll have grasped the fundamentals and you'll have your first demo together in no time.

To get the basic concept working isn't difficult at all, however, it's still too difficult for a first game project. If you haven't already made a tetris/minesweeper/snake/space invaders close - do that first!

Anyway, I wanted to make a very similar marble rolling type of game recently but I just got a full-time game developer job and want to focus my efforts onto that.

However, I'd still like to work on this type of game/demo for playing with physics and shaders without having to worry about models and animations. If you want any specific help with code, send me a message!

And if your map is made up of 32x32x32 cubes, as a simple solution you could store it as a std::vector<D3DVECTOR3> where each vector is the location of a cube. Better still, an std::vector<MapCube> where MapCube is your own map square type including a D3D vector for the location. Serialize it to an XML file (you're only loading it once) and you'll find it easy to edit maps or write a map editor in .NET or something else a bit nicer for writing tools.