Re: your mail

[Laguna Loire <laguna@ourmag.com>]

Hi Ashley,

So I take it instead of an actual company, you and your friends are a
group of artists and designers with minimal programming experience?

Btw, how is your experience with Animation:Master? I know they recommend
saving often, but all the same, I'd prefer it more if it didn't crash as
often as it does. But that's just me. ^_^;;

> We have already made our graphics, they are full 3d pictures we made
> using Animation:Master and don't know how to add them to game, I have
> heard they are called bobs no?

Umm... bobs? Has anyone heard of this term before? ^_^;;

Or is it an acronym for... background objects? bitmap overlay backgrounds?
^_^;;

Basically, at least from my viewpoint, the rendered images you have from
AM or any other graphical application can be used as a background or
backdrop for your other images/characters/objects to exist upon.

So if you rendered a landscape for an area, then that landscape would be
the background upon which you impose game based restrictions in terms of
movement and the like to make your background image "come to life".

> We have absolutly no idea of what to make first when it comes to
> making the game with c++, even though we have followed everything on
> this site and even set up pans of what our game is about and every
> little detail of the game, especially the way a little petal will move
> on a small plant that we are using in game.

All these little details are nice and the way you are describing what you
and your team can do is reinforcing my opinion that your group is like 75%
artist, 20% story writer/designer, and 5% coder. I could be wrong. :)

Speaking from personal experience with programming projects, you would
normally work out the "big" details first. Then, break down those bigger
details into somewhat smaller blocks. I think this is referred to as
the "top-down" approach to programming. It's kinda like your arm. You use
the larger muscles to control the big motions and the smaller and finer
muscles like in the wrist and fingers to make the small detailed motions.
The same is with programming.

Work out what you want first. Not in terms of graphics, but in ideas.
Concepts. Storyline. Where do you want to take the game and how do you
want to get there? What technique do you want to use in terms of story
telling?

You mentioned a "3d rpg strategy". This can mean alot of things... so
let's use your category or target as an example. :)

We can break your originating subject into three categories: [3d], [rpg],
and [strategy].

All three of these are encompassed by the overriding concepts of
storyline and goal of the game. I'm going to assume you have a storyline
already in place. If not, then you will probably want to get an outline of
your storyline to work with and flesh it out later, as you progress.

An RPG is where the player assumes a role of a character in the game.
Lunar, Final Fantasy, Dragon Quest, Phantasy Star, etc.. these are
examples of RPG type games for game consoles. They involve a great deal of
exploration and often times, requires management of the characters under
your control. There are also battle systems built in and storyline plays a
big role. Note: Some older games didn't involve combat, but were puzzle
solving and thinking RPGS. Zork, Adventure, and Dungeon comes to mind.

Strategy games are those which are not unlike chess, stratego, Final
Fantasy Tactics(which is rpg-strategy), StarCraft, WarCraft, Red Alert,
Romance of the 3 Kingdoms, etc. Amoung these types of strategy games,
there is turn based strategy and real-time. These games also have battle
systems and game systems. While a storyline doesn't play as strong a role
here, a general history and background story does help the player to see
why exactly they are doing what they are doing.

3D games, I think, are a bit over-rated, but a good deal of people out
there like them, so... they sell. Basically, any game making use of
either/or/both 3d image work or a 3d based game system involving 3d
dynamics like space, motion, and physics. This is really more like a sub
type as opposed to an actual type since it describes the technology
applied as opposed to the game itself. Games based purely on 3d type to
fall into the simulation category or the first-person-shooter category.

*takes a deep breath* Okay. Now that those have been described, let's get
back to your original description: "3d rpg strategy".

This can better be described as an RPG involving strategic combat
scenarios rendered in 3D or incorporating 3D elements.

So your main focus should be to focus and develop your storyline. Where
are you starting your "world", what condition is it in? What condition is
the part of the world where your characters begin? And where is this world
heading? What is the compelling thing which forces your characters to live
out their adventures?

Once you have worked out this concept, you can then decide on how you want
to implement those ideas into the game itself. And this is where we start
looking at how you want the "gui" of the game to be like. The layout, the
information the player will see, how you want the game to look. This will
all affect how your underlying code will be written.

Continuing with translating your ideas to code/structures, you will need
to examine how you want your character's abilities, history, and actions
to be represented. Whether there will be items to use, spells, attributes,
names, emotion points, etc. Next would be the inventory, the items, the
spells, the effects, and their descriptions and characteristics.

You will also need to create a menu'ing system or command interface for
your game.

The various modes of the game: menu, movement, battle, interaction, story
progression, etc.

Once you have gotten most of these ideas translated into a general method
of how you want to implement it and what it will look like, you can then
focus on writing code to create those effects.

If it sounds like alot of work, it is. But then again, you get from your
code what you put into it. So spending the effort in developing your ideas
to determine the best way to put your ideas to code will pay off in the
long run. Just make sure you and your team are in close communication and
can understand what the others are doing in code. 

But once you start outlining your programming project from the uppermost
ideas and start breaking them down, you will begin to see how your image
work and/or wiremeshes or objects can be imported from external apps and
how they will be incorporated into your game.

This does not mean it will be any easier as you will still need to study
and learn the language you intend to use as well as any langauges you will
need to learn to make use of other peoples' code/libraries.

Best advice is to keep at it, spend the time to learn, and to try and
experiment. You'll learn faster as well as be more open to finding new
ways of doing something.

> I am probably very vauge in my description of my problem, but thats
> just me! Thankyou Ashley Rowe

Don't worry about being vague. And I hope my email above doesn't sound
condenscending. Sometimes, it helps to describe the starting point before
going forward. And so I try. ^_^;

But good luck with your game development! It would be nice to see a good
game come out. ;)

Wing.

=================================================================
The GameProgrammer.Com mailing list is for the open discussion
of any topic related to the art, science, and business of
programming games. This list is especially tolerant of beginners.
We were all beginners once

To SUBSCRIBE or UNSUBSCRIBE please visit:
http://gameprogrammer.com/mailinglist.html