FLeBlanc

I recommend you design it from the start to support multiplayer; hacking a singleplayer to add multiplayer is usually a lot more effort than just doing it right from the start.

 

Multi-player programming isn't too difficult, but it is kind of tricky for a beginner to get it right. It's not just a simple matter of sending commands through the connection; you also have to figure out a method for dealing with latency and disconnects, methods for screening input to try to prevent hacks and exploits, etc...

 

If you haven't completed a single-player game, though, I recommend you do that first. In the process, think about ways that you can structure your code so that when you do design a multi-player game you know a bit more about how to put it together. Come up with strategies for object management and communication that will facilitate multiplayer.

 

Also, do some smaller-scale multi-player projects. Simple chat clients, tests to figure out synchronizing objects, etc.. The more time you spend here, the better you will be able to spend your time on the big project.

Yes, you can import 3D models. (Though you don't import them into C++, per se. You import them into a program which might be made with C++, and you might use C++ to do the importing, but you're not importing into C++ itself.)

 

And no, you can't program the imported model. However, you can write your program such that you can manipulate the imported model according to keypresses.

My game is not going to support multiple objects pushing each other. Integrating my game with a 2D physics library is just to much work for such small game. It would be like putting a 500 horse power engine in a piece of junk from the seventies.

 

I think you overestimate the difficulty and complexity of integrating a 2D physics lib. Seriously, take a look at the Box2D tutorials. It really isn't all that difficult.

It looks like you are doing something wrong.

To start with, you assign eximg=explosion[1], so now eximg points to the first image in the list of explosion frames. But then in explode(), you assign eximg=eximg[anum]. This is the problem. eximg at this point isn't an array of anything, it's just a love.graphics.image type. So eximg[anum] (when anum is pretty much any number) will be equal to nil. So when you call explode(), you essentially set eximg equal to nil. Then when draw rolls around, you pass eximg[anum] to love.graphics.draw. This is tantamount to passing nil[anum], which is not allowed.

I think that what you are wanting to do instead is set eximg=explosion[anum] inside explode(), then in draw just call love.graphics.draw(eximg, 20, 20). This way, eximg gets pointed at the proper entry of explosion.

You will probably want to use multiple meshes placed adjacent to one another. For lower LOD chunks, you can use a lower res block of samples plus a skirt to hide the cracks between seams.

 

Perlin noise fractals are ideally suited for this kind of on-the-fly generation, because in order to get a lower detail terrain (and incidentally one that will generate more quickly) you simply reduce the octave count of the fractal. So for example, if the largest block size is MxM, and the next LOD level down is a block M/2xMx2, then you can generate the first one using, say, 8 octaves and the second LOD level using 4 octaves.

 

If you are going with a large or practically infinite terrain, then I would recommend against using a quadtree. The basic quadtree takes a finite, bounded volume and splits it recursively into 2x2 sections, which doesn't extend well to an infinite sized volume. Instead, I would use something like a spatial hash where blocks are indexed using a BlockX, BlockY pair that is hashed to find the "bucket" in which that terrain block lives. Block coordinates can be negative and practically infinite (if a large enough precision type is used for the coordinate pair) and you can easily draw a "chunk" of blocks centered at some given coordinate to implement your moving window into the world. You can also easily implement streaming and discarding of blocks as they come into or go out of a larger "active" window on the world.

The missile's direction wouldn't be from (centerx,centery)->(vx,vy). (vx,vy) indicate the direction the missile is going. That is the direction, and that is the vector you need.

 

angle=atan2(vy,vx)

This would bug the crap out of me, to be honest. Especially making it harder later in the story (where the combat itself would also be harder, and thus I would need healing more often). It just seems like it would pull me out of the game I'm playing (and RPG), and into some game I don't want to play (matching crap).

Well, you don't really need to link those libraries into your game, unless you will be generating your effects on the fly. What you might want to do instead is just use those libraries from a separate program to construct the images for your effects, then use those images from your game.

I tend to use a lot of procedural stuff for my effects. You can grab a library such as ANL or libnoise and use various fractal functions along with patterns to generate the effects you need. If you want animations that repeat, procedural functions can be made to loop seamlessly (the creator of ANL, wrote an article about looping fractal noise in 1, 2 or 3 dimensions at http://www.gamedev.net/blog/33/entry-2138456-seamless-noise/ which he also includes in ANL). 

 

You could also write some one-off particle systems and bake the system to a series of textures. Spawn a few particles, and over some span of time, "render" the particle system to an image and save it. As the particle system is animated and baked, the effect will be saved as a series of PNGs.

 

Doing things procedurally does require you to tinker with things quite a lot, and think creatively about how you can use your available tools to create the effect that you want.

You might take a look at the GLConsole project. While it is OpenGL-specific, it should still be instrumental in understanding what goes into a console system.

You can use initializer lists:

characterAnimation::characterAnimation(short int numOfSteps, short int height, short int width, short int animationRow, ALLEGRO_BITMAP *spriteSheet) :
numberOfSteps(numOfSteps-1), currentStep(0), imageHeight(height), imageWidth(width), row(animationRow), images(numberOfSteps)
{
    for(int x = 0; x <= numberOfSteps; x++)
    {
        images[x] = al_create_sub_bitmap(spriteSheet, (imageWidth * x), (imageHeight * row), imageWidth, imageHeight);
    }
}

There really isn't a rulebook or set of common practices for this. Just discuss payment terms with the artist as you interview them and hammer out a contract. Give them a good idea of what is expected, and they can give you a good idea of what they will expect to be paid.

If you're serious, then instead of posting another topic like this, go through all of your previous posts. Read the answers that other people posted, think about what they're saying, try to apply it to your problem. Your thread history has some good advice. Encapsulation. Separating logic from rendering. Collision detection. Go ahead and try to process it, then when you have specific new questions, come back here for clarification. Because the thing is, you are still pretty much doing collision "wrong". Previous answers in your other threads gave you some avenues to follow to learn how to do collision "right". It's really pointless to ignore that advice and keep chasing the wrong things and asking the same questions.

Man, I really hate to be a dick, but...

http://www.gamedev.net/topic/636083-little-more-help/
http://www.gamedev.net/topic/635556-little-help/
http://www.gamedev.net/topic/635213-collision-detection/
http://www.gamedev.net/topic/634727-breakout-game/
http://www.gamedev.net/topic/633265-collision-detection/
http://www.gamedev.net/topic/625158-collision-question/
http://www.gamedev.net/topic/622320-collision-code/
http://www.gamedev.net/topic/622165-2d-collision/

The list goes on.

You have this habit of posting a question, getting some answers, maybe posting some final response like "Wow, that is a lot of code", then disappearing for a few weeks. When you come back, you are asking the same exact questions as before. I really hate discouraging anyone, but are you really certain that programming is for you? It just doesn't seem like you are actually learning anything or making any progress at all. There is nothing wrong with not being able to program, but there is something wrong with continuing to ask the same questions over and over, wasting the time and effort of everyone who has posted in your many threads trying to help you out.

I'm not a DirectX user, but it seems to me from the documentation that it only wants a pointer to an unsigned int so it can return the number of passes needed to do the operation. Surely something like this would work?

 

unsigned int numpasses=1;
mSkyBoxEffect->Begin(&numpasses, D3DXFX_DONOTSAVESTATE);