Game project recommendations.

[H00G0]

Hey people!

So I've had an idea for a game for a while now, while I'm learning C++. I think I can get
around with pretty much the “basics” of object oriented programming so far. As far as
game programming goes I have no experience what so ever.

The game I want to make would be:
- 2D isometric (with a ~45° tilt of the camera)
- Turned Based RPG
- The movement in the game would be much inspired by that of the MMORPG
DOFUS if you know about it. In short no keyboard input, the character's
actions are controlled by an interface and it's movements are only from square
to square during combat sequences, and simply by a click of the mouse to navigate
the world.
- As far as I know there would be no physics involved since all the character's
actions being interface based, there would be animations.

I know that a frequently asked question about game programming is “which engine should
I use?” But I've noticed people reporting that it's pretty much down to personal preferences.

So here is my question(s):
_Do you have any recommendations?
_Is there any skill I need to acquire before getting myself into a project like this? If so which
one(s)?
_Is there any resource I should be aware of, that would help me (tutorials, books, etc.)?
_If this forum is not the place for such question, I apologise, please guide me to the
appropriate place for that.

In advance, thanks to any suggestion, advice, anything!

Edit: format, typos.

[jonnin]

I would say do everything non graphical that you can first, like save/load, track stats, data structures/storage, whatever. Then once that stuff works well in a console, add graphics to it.

The easy way to do the graphics is to find a sample project that you can hack on. From scratch is tougher, but not insurmountable. Still, I would start with a demo or open game and modify it, mess with it, get a feel for how they did stuff... just play with it.

Be aware that 2d projection games are usually a 'limited 3-d' game in practice.

[H00G0]

I would say do everything non graphical that you can first, like save/load, track stats, data structures/storage, whatever. Then once that stuff works well in a console, add graphics to it.

By console do you mean windows console or should I use a renderer to create a application window and start implementing things from there?

I would start with a demo or open game and modify it, mess with it, get a feel for how they did stuff... just play with it.

I've been thinking about that actually but since it's a MMO I don't really know if it's ever possible to have a peek at the code. Also how do you access and modify the code of an existing game?

Edit:

Be aware that 2d projection games are usually a 'limited 3-d' game in practice.

Are you talking about the engine that would be needed in this case?

[MikeyBoy]

I've been thinking about that actually but since it's a MMO I don't really know if it's ever possible to have a peek at the code. Also how do you access and modify the code of an existing game?

Typing "MMO source code" into Google would seem like a good start. It certainly produced several promising-looking results when I just tried it.

[H00G0]

Typing "MMO source code" into Google would seem like a good start. It certainly produced several promising-looking results when I just tried it.

Oh you're right, i hadn't thought of the keyword "source code" in my research. After some research too, it appears that the MMO I want to base my gameplay on is using flash and has never been made public according to a moderator on the official forums.

[jonnin]

I meant windows console. You are just testing the non graphical parts, you won't keep the main program file just the included code you wrote. Its a 'driver' or test program only approach. Its a sort of defensive coding technique, that I am recommending. I always do the graphics or the GUI last. Then you can apply the latest engine or port to various GUIs with minimal trouble. If you build the graphics/UI first, you have a nasty temptation to tie the graphical constructs to the code in ways that are hard to undo. If you do them last, you can change engine or UI or platform much easier if you pick the wrong tool.

I am saying that I think modern top down isometric games often use 3-d. I could be wrong, but some of them seem to use 3-d models not sprites, these days. You need an engine/library regardless, I am just wondering if they are really 3-d that just happens to have a relatively thin world and relatively fixed viewpoint, rather than 2-d trickery. I don't know anything for sure, going off gamer experience not coder experience, but they sure seem to be using 3-d models... of course everything is 2d when it reaches the screen so you can fake it quite well... hard to say.

There are opensource flash games also. Or you can re-create the idea from the flash game in another tool. /shrug. Pick something and give it a look and see what you can do. I delivered several programs that grew out of taking a provided example program from a library and playing with it for a bit, making it do more and more until I got what I needed. There is a LOT of free code out there.

[H00G0]

I meant windows console. You are just testing the non graphical parts, you won't keep the main program file just the included code you wrote. Its a 'driver' or test program only approach. Its a sort of defensive coding technique, that I am recommending. I always do the graphics or the GUI last. Then you can apply the latest engine or port to various GUIs with minimal trouble. If you build the graphics/UI first, you have a nasty temptation to tie the graphical constructs to the code in ways that are hard to undo. If you do them last, you can change engine or UI or platform much easier if you pick the wrong tool.

Right I see what you mean and indeed it seems like a reasonable way of progressing, I do think I'll try to work that way since all the graphics, animations and so on are purely aesthetics and non functional as far as gameplay goes.

I see what you mean about 2D/3D it's a shame if I had to model in 3D, I was really excited about animating my own sprites.

I shall also look into opensource flash games, thanks for the suggestion I hadn't thought about that, it seems like a smart thing to do!

Cheers!

[Ganado]

+1 to jonnin's suggestion of being able to program major parts of the code without need of any actual graphics. This helps separate the "Model" of the game (underlying data, logic, and structure) from the "View" of the game (how it is represented to the user).

On the other hand, I personally wouldn't do the graphics last, after everything else. But I would still keep the graphics as logically separate from the game logic as possible. Unless you have some strong willpower, it could be discouraging to go a month+ into writing and testing without actually being able to see a sign of any graphical fruition. Graphics are what hook people into a game, after all. (Also, for example, I find it very hard to imagine things like object collision without having to at least think about basic graphical shapes, like circles and rectangles).

Chasing a square is boring. Chasing a cute hyper squirrel that squeaks is fun. But the underlying logic is the same.

Also about isometric: The game engine that I've used (FOnline) was isometric but was still fully 2D in its logic. The hex grid is composed of simple x, y coordinates. Even if you add in the option for 3D models, the game logic itself is still 2D. This connects to the first point; the game logic should be separate from any graphical representation as much as possible.

My friend made a game in Unity3D, but I heard Unreal engine is free now, so I guess check that out.

But also, you should be aware that games take a serious amount of work. Newcomers will tend to be very ambitious at first, but then get overwhelmed once they figure out just how much goes into making any solid game. In general, I suggest starting a small game at first, so that you can actually see a product come to fruition. It will be hard enough the first time to do this, let alone make a whole RPG. In doing this, you'll be able to get a taste of the easy and hard parts of making a simple game. You'll learn basic code organization and techniques/lessons learned that you'll be able to then apply to a bigger project.

Edit: Also, I noticed you double posted in General. Don't do that.

[jonnin]

that is a valid point. I am kind of a robot in some ways, and I am one of those rare nonvisual persons who would rather see a page of text (takes 15 seconds tops) than sit through a video saying the exact same thing (takes 5 min...). So chasing a square is equal to chasing a real graphic to me, if I am testing the movement function. But I understand (ok, not really, but sort of at an intellectual level) the idea that it might feel better to chase the graphic for normal people :)

In that case, as the song says, keep em separated! That was the key point, order of operations was just to enforce that and remove the temptations. My first graphical program tied windows gui, graphics calls, and the actual code all in an unhappily married mess. I had windows on-paint calling itself to constantly (its last line triggered it to be called again) draw as my drawing 'loop' and that was in turn drawing things in the graphics library which in turn were tapping the data in the program that governed what to draw .... It would be easier for anyone but me to re-write from scratch rather than try to modify it... it was awful. Nothing like a hands-on case study in what not to do... and I never made that mistake again.

[H00G0]

On the other hand, I personally wouldn't do the graphics last, after everything else. But I would still keep the graphics as logically separate from the game logic as possible. Unless you have some strong willpower, it could be discouraging to go a month+ into writing and testing without actually being able to see a sign of any graphical fruition. Graphics are what hook people into a game, after all. (Also, for example, I find it very hard to imagine things like object collision without having to at least think about basic graphical shapes, like circles and rectangles).

About that, I was intending to make maybe one or two sprite for my main character, maybe an idle animation and a walk animation, and probably a generic, simplistic one for enemies and NPCs. So that I still somehow get a look at the finished look while working on the actual game.

Also about isometric: The game engine that I've used (FOnline) was isometric but was still fully 2D in its logic. The hex grid is composed of simple x, y coordinates. Even if you add in the option for 3D models, the game logic itself is still 2D. This connects to the first point; the game logic should be separate from any graphical representation as much as possible.

My friend made a game in Unity3D, but I heard Unreal engine is free now, so I guess check that out.

Aren't some of those engines more demanding than others in terms of PC specs required to run smoothly? This is one of my goals too, since I have a poor PC - to make the game somewhat smooth and not too demanding.

But also, you should be aware that games take a serious amount of work. Newcomers will tend to be very ambitious at first, but then get overwhelmed once they figure out just how much goes into making any solid game. In general, I suggest starting a small game at first, so that you can actually see a product come to fruition. It will be hard enough the first time to do this, let alone make a whole RPG. In doing this, you'll be able to get a taste of the easy and hard parts of making a simple game. You'll learn basic code organization and techniques/lessons learned that you'll be able to then apply to a bigger project.

I was starting to lay this out the other day, tell me how faisable and reasonable this sounds to you: I thought of making the tutorial of the game first, implementing the mechanics, combat, movement system and dialog in a very restricted map, a sort of level 0. Also in the first version of the game I'll make only one character class (class as in to race) and start making the other ones only when the rest of the game is rock solid and running. I'm thinking that if I can make the game work in a tiny tile and with limited focus on graphics, I can focus mostly on building the game efficiently.

Edit: Also, I noticed you double posted in General. Don't do that.

Gotcha, won't do it again!

[H00G0]

that is a valid point. I am kind of a robot in some ways, and I am one of those rare nonvisual persons who would rather see a page of text (takes 15 seconds tops) than sit through a video saying the exact same thing (takes 5 min...). So chasing a square is equal to chasing a real graphic to me, if I am testing the movement function. But I understand (ok, not really, but sort of at an intellectual level) the idea that it might feel better to chase the graphic for normal people :)

I think I would be like you too I don't really mind working an a poor looking thing as long as the focus is on it working well, or at least better and better as time goes..

In that case, as the song says, keep em separated! That was the key point, order of operations was just to enforce that and remove the temptations. My first graphical program tied windows gui, graphics calls, and the actual code all in an unhappily married mess. I had windows on-paint calling itself to constantly (its last line triggered it to be called again) draw as my drawing 'loop' and that was in turn drawing things in the graphics library which in turn were tapping the data in the program that governed what to draw .... It would be easier for anyone but me to re-write from scratch rather than try to modify it... it was awful. Nothing like a hands-on case study in what not to do... and I never made that mistake again.

Do you mean that if you have every graphical part attached to mechanics and game functions, it extends the inter-dependency of game elements and it's a nightmare to modify/remove one without having to change the whole thing?


Also, since I'm sort of planning things out in advance before actually starting coding I have a few more general questions that come to mind.

_How is AI managed with C++? I will need to determine all "monsters/enemies" 's behaviour so far as attacking the character. Maybe a different behaviour for each type of enemy but nothing too mind-blowing.
e.g: monster1 has an aggressive behaviour and will use melee on the character
monster2 is less aggressive and will use a "hit and run" strategy.

Edit: Do you juste have a function that does that sort of "mechanical" comparison and call it AI?

void agressiveBehaviour(/*arguments*/)
{
    int char_xpos,
	char_ypos,
	monst_xpos,
	monst_ypos,
	xDifference,
	yDifference;
		
	bool nearCharacter = false;
		
	xDifference = (monst_xpos - char_xpos);
	yDifference = (monst_ypos - char_ypos);
		
		
	do
	{
	    if(xDifference > 1)
		monst_xpos --;
            else if(yDifference > 1)
		monst_ypos --;			
	    else if(xDifference < 1)
		monst_xpos ++;
	    else if(yDifference > 1)
		monst_ypos ++;

            if((xDifference^2 == 1) && (yDifference^2 == 1))
                nearCharacter = true;
	}
	while(!nearCharacter);
			
	if(nearCharacter)
	    monsterAttack(/*Player reference & coordinates*/);

        return;
}

_So far as sound and music goes, one has to be really careful about copy rights and author consent I suppose? Is there any sort of written thing that is required for you to have in order to use someone's music so that you don't get in trouble?

Edit: Spacing

[MikeyBoy]

I thought of making the tutorial of the game first, implementing the mechanics, combat, movement system and dialog in a very restricted map, a sort of level 0. Also in the first version of the game I'll make only one character class (class as in to race) and start making the other ones only when the rest of the game is rock solid and running. I'm thinking that if I can make the game work in a tiny tile and with limited focus on graphics, I can focus mostly on building the game efficiently.

Starting small is good, but I'm not sure about focusing on the tutorial specifically. Tutorials are kind of a "special case" mode, and you might find yourself writing things in such a way as to be tied in to the tutorial mode and not suitable for general gameplay.

But certainly, starting with a small level, and a single class, is a good way to begin, though.