OT - Kind of

[Alpha Kodiak]

quote:

---

Originally posted by chewy027:
so alpha ur saying that any language could possible be used...ok... now about game design do you mean like ideas and such or rule sets for the program to follow

---

Think of it as a game first, before thinking of it as a computer game. If you and a friend were to sit down and play it as a board game, how would it work? What would the rules be? How would you move, fight, etc.? What about economics, research, population control? The computer can allow the rules and computations to be more complex and in depth than a playable board game, but there still need to be consistent rules.

[Will]

I'm going to ditto a lot of the other comments here. I'm not exactly an "experienced" programmer (about two years on-and-off as a hobby), but I do know that if you don't know any details about your program, you won't be able to write it. Programming is not really something where you can just "wing it", especially if you're doing object-oriented programming. Object-oriented was made like that on purpose, forcing programmers to plan what they're going to do.

I would recommend learning C++, mainly because the only Languages I know much about are C++, Java, and VB. C++ is just plain more powerful than VB, and it's "sexier" . Java... well, on a list that compared programming Languages to automobiles, IIRC, C++ was a turbo-charged Ferrari, VB was the clunker you ditched as soon as you got $2,500 to get a decent used car, and Java was an All-Terrain, Very Slow Vehicle. Plus you could get help in lots of places in learning C++.

After you spend about a year learning and practicing C++ (including how to do graphics, basic AI, standard game loop, etc.), come back to your game idea, and develop it. A lot. Make all the rules, as stated by Alpha Kodiak. Find a friend that doesn't know about your plans for the game (would be nice if the friend knew how to program, and even nicer if the friend is a she and you give me her number... . If they ask for more details about how something works, you don't have enough details in that area, so keep developing.

Once you've developed all the rules, in the case of object-oriented Languages, plan out your classes. You'll be very glad at this point that you developed throroughly. If you didn't, planning your classes will be difficult, and if planning your classes is difficult, you didn't develop enough. Find more friends to look at your ideas. Find strangers to look at your ideas. Find anyone.

Once you've developed the rules and planned your classes, you begin programming. If you have anyone helping you, it is really nice to have well planned classes, because you can divvy up programming the classes, and make things much easier. Since each class has it's internals mapped out pretty good, you can be reasonably sure that everything will click together with minimal work in the end.

Now with all that, you can see that making a game of SE4's magnitude is really quite difficult. I'm really amazed that Aaron made SE4 on his own, albeit with a large idea factory made up of fans of SE3. Even if all this seems discouraging, I urge you to look into it. Even if the game itself doesn't make it to something close to a working computer game, you will learn a lot of skills that are very valuable in the world today. And you just might come up with a better game idea, and since you've already gone through the process once, the second time around will be much easier (I'm sure Aaron could verify this, or any of the programmers of the other games Shrapnel publishes).

Good luck

[chewy027]

well i guess i'll have to get started on the research and development part of it . Figuring out all the little details.

One question to Will, could you clarify a little bit for me about "classes". I followed everything fine just that word didn't fit to me. Sorry.

[Lemmy]

classes are at the base of object oriented design.
every object in the program is a member of a class. Classes are made of attributes and methods. For example a class Ship could have attributes :
size
movement points
and a method:
move

then every ship in the program must have a size and a number movement points.

Before you start designing maybe you should first read a bit about OO design, it's really usefull to break a program down to little understandable bits of information.

[Lemmy]

quote:

---

Originally posted by Will:
Even if the game itself doesn't make it to something close to a working computer game, you will learn a lot of skills that are very valuable in the world today. And you just might come up with a better game idea, and since you've already gone through the process once, the second time around will be much easier

---

that is so true, in my short(3 years) programming career i tried to make 3 games, the first one was in Jave but just too complex, the second one was in C++, i did this with a friend of mine who is really good at C++ and graphical stuff, but that was also too complex and once we had a design we estimated it would tak 2-3 years to make, so we gave that one up.
And now i'm working on my 3rd game, trying to follow every Object Oriented rule i learned at school, and it's going quite well, i haven't programmed on it for about a month now, but not because it's too difficult or complex, but a lack of time(school/civ3). It's turn-based and while i program it i learn lot's of new stuff, like the mechanism to end a turn and start the next players turn, it sounds simple, but it took me a while to make it solid and dependable( that is bug-free ). Without the experience from my first two "games", i never would have gotten so far as i am now.
hmmm talking about it makes me wanna go home and continue working on it.

[ 30 November 2001: Message edited by: LemmyM ]

[dogscoff]

Classes and OO design:

As I understand it (I've studied programming but never really done any) OO design is diferent from regular programming design because:

In regular programs, you set up a system with a bunch of rules to govern how the things within in that system behave. Then you drop a load of itms into that system and the system looks after them. For example, you might make a menu screen, and the menu checks constantly to see whether one of it's buttons has been clicked and what to do if it has.

In object oriented (w00p!) design you set up a bunch of classes, with their own rules about how they interact with on another and the system they live in. Those classes then spawn objects (A class is essentially just a blueprint for an object) into the system, and you just sit back and watch them interact with one another like a little ecosystem. In the menu example, each button would be an object. (probably all from the same class) Each button would watch out for it's own mouse clicks, and store it's own information about what to do when it is pressed.

Of course it's never as easy as I make it sound...

Anyway, the advantage is that an object within a system is by definition smaller and less complex than the system itself. Therefore, it's easier to capture and define all the possible permutations and interactions for that object than for a system. This means you can break your code down into (relatively) simple and (utterly)self containd parts.

Furthermore, because objects are treated as self contained and completely independent of outside intererence, it's easy to add, remove, replace and alter them to/ from/ within your program.
As long as its interfaces remain unchanged, you can just pull it out, make whatever changes you need to within it and then drop it back in without fear of generating some seemingly random error on the other side of your software.

Or something.

*Dogscoff skulks back to his pint.

[chewy027]

thanks for the clarification guys really helped.

Anyone else with some words of wisdom