OT - Kind of
 

This is a question for all you computer programers out there. How hard would it be to program a game of SE4's magnitude?, and how much experience would be needed to do something like that?

Re: OT - Kind of
 

I'd say "very" and "lots".

Aaron started (AFAIK) with SE I, way way back in the dim history of computers (anybody know the year?). Each iteration added experience, and hard work, and lots of time.

Re: OT - Kind of
 

Depends on what sort of resources you had, if you had a team, it wouldn't be to hard (still hard but it wouldn't be as hard as) if you only had one guy working on it, very hard. It can also depend on the equipment, there are various programs that help ease programming. And of course your programming skills.

All in all though, from the sheer complexity of the program I would say it is pretty probably hard.

Re: OT - Kind of
 

so where would you start i mean what type of language would you use and such

Re: OT - Kind of
 

One thing about game development if you have ever disected a game is that a game is nothing more than basic images that move. Much like a movie. I took BOTF apart, and found that 90% of the game was graphics. The rest was the program that used the graphics and interacted with the player.

I would love to posess the knowledge needed to program games. Man I have a few that I would love to see made that currently are not on the market.

Re: OT - Kind of
 

The hard part isn't the programming. The hard part is to come up with a complete, consistent game design including all of the rules, combat system, movement system, AI behaviour, etc.

Once you have the complete game design, you can begin the software design. I would recommend an object oriented approach to the design as it would simplify the implementation later. It is important to get the software design to model the game design completely. Pay attention especially to the data structures that you are going to use to model the game. Don't start coding until the design is complete.

As far as language is concerned, it is purely what you are used to. I would use C++ because that is what I use the most. It is not necessarily the easiest, mind you, just what I am comfortable with. Delphi would work, and even (cough... choke...) VB could be used. You want a language that can support objects and understands Windows dialogs, etc. (I am assuming you want it to run on Windows, rather than Linux, Mac, DOS or other operating system.)

The most important thing that most people overlook when approaching something like this is that the design is the important part. If you have a good design, implementation is much easier.
(Not trivial by any means, but easier.)

Re: OT - Kind of
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by chewy027:
This is a question for all you computer programers out there. How hard would it be to program a game of SE4's magnitude?, and how much experience would be needed to do something like that?<hr></blockquote>

More time and experience than one person can possess. http://forum.shrapnelgames.com/images/icons/icon7.gif Even now SE IV is a long way from finished. There were LOTS of features described in the early text files from the game that are now gone. Planetary cloaks, planetary engines, warp gates, "monster" troops, etc. He's so busy fixing bugs that he doesn't have time to follow through on all the plans. If he could find an AI programmer maybe he could resume work on the main game. http://forum.shrapnelgames.com/images/icons/icon7.gif

Re: OT - Kind of
 

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

Re: OT - Kind of
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>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<hr></blockquote>

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.

Re: OT - Kind of
 

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" http://forum.shrapnelgames.com/images/icons/icon7.gif . 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... http://forum.shrapnelgames.com/images/icons/icon7.gif . 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 http://forum.shrapnelgames.com/images/icons/icon7.gif

Re: OT - Kind of
 

well i guess i'll have to get started on the research and development part of it http://forum.shrapnelgames.com/images/icons/icon7.gif . 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.

Re: OT - Kind of
 

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.

Re: OT - Kind of
 

thanks for the clarification guys really helped.

Anyone else with some words of wisdom http://forum.shrapnelgames.com/images/icons/icon7.gif

Re: OT - Kind of
 

KISS (Keep It Simple Stupid)

Make sure that the current section of code WORKS. If its slick and doesn't work, it doesn't do any good. In the words of my Assembly Language Professor (Yep, was a long time ago http://forum.shrapnelgames.com/images/icons/icon7.gif ), "When all else fails, use Brute Force." Once you have a section of working code, then you can 'slick'en it up.

Avoid the 4 P's (Piss Poor Prior Planning).

Everthing is ultimately dependent upon your preparation. Decide early on what you want & how you want it, and, don't give in to Feature Creep. Maintain your objective, add features later.

One other thought....Graphics is window dressing, mechanics will make or break the game. Make sure your (game) mechanics are solid, and the graphics can be added/prettied up later. This relates directly to the 4 P's.

[ 30 November 2001: Message edited by: Spyder ]</p>

Re: OT - Kind of
 

Without trying to give a detailed lesson in object oriented design and programming (OOD/OOP), let me put it this way: an object in a program should model an object in the real world. LemmyM gave a good example with a class called "Ship". All ships have some basic things in common, so having a class called ship enforces that all types of ships have those things in common.

This leads to one of the most powerful aspects of OO: inheritance. Let's talk about a beagle. A beagle is a dog, which is a mammal, which is an animal, which is a living thing. So, we can define a beagle by starting from living things. A living thing has certain properties which we can assign to class cLivingThing. Class cAnimal derives from cLivingThing (which gives it all of the properties of cLivingThing). We then add to cAnimal the characteristics that distinguish an animal from other living things (plants, etc.) Class cMammal derives from cAnimal and adds the characteristics of a mammal (i.e. mother feeds baby milk). Class cDog derives from cMammal and finally cBeagle derives from cDog. Now, if we want to define a German sheppard, we only have to derive from cDog, everything else is already set up.

One of the big benefits to this is that what can be shared, is. For instance, if there is a bug in a routine that defines part of cLivingThing, we only have to fix it in cLivingThing, not in all of the things that are derived from cLivingThing. They all pick up the fix for free.

At any rate, that is a highly simplified account of what OO is. There is much more involved, but hopefully that gives you some idea of what you can do with it.

Re: OT - Kind of
 

all that makes great sense thanks for the input. Keep it coming.

Re: OT - Kind of
 

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.

Re: OT - Kind of
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>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<hr></blockquote>

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 http://forum.shrapnelgames.com/images/icons/icon7.gif ). 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 ]</p>

Re: OT - Kind of
 

Well, all there really is to do now is find a way to learn whichever language you're going to use. I would recommend either signing up for a class (as in a classroom, with teacher and students, not object blueprint http://forum.shrapnelgames.com/images/icons/icon7.gif ), or tracking down someone who can tutor you. Really try for those two, since the other alternative is getting a book that teaches you, and that is a pain. The book doesn't respond to all your questions, when the book does respond to questions, it never seems to be when you ask it, and the book doesn't keep you on-task.

And then, you start learning. "Hello World!" http://forum.shrapnelgames.com/images/icons/icon7.gif

--edit: forgot to uncheck "Show Signature".

[ 01 December 2001: Message edited by: Will ]</p>

Re: OT - Kind of
 

well actually i will be taking a programming class next semester here at Princeton. I know basic stuff but want to learn more. Maybe someday i'll be able to follow through with a game. But until then i've got a lot of ideas i should organize and refine.