Where to begin...I'm 43 and remember when pong was released. I started programming in 1982 on an Atari 400 w/ Atari BASIC. I've owned QuickC, Zortech C++, Watcom C++, now MS VC++ 6.0 and I'm hoping OpenWatcom matures a bit faster to compete against MS's line. Disregarding all that, my game idea is massive, so massive that I got frustrated with the scale 10 years or so ago and gave up...now I'm attempting it again. The idea: a space shooter...YASS (Yet Another Space Shooter). I intend two play modes: Physics and Hollywood, and two command modes: Solo and bridge crew. The Physics and Bridge crew modes are the main goal. Those should prove the most challenging, because I'll have to relearn physics, program different workstations, etc. I have plans for the engineer's workstation that will be...different. I could detail my idea, but I'm sure it's either been said before or some other reason people will just go, yeah, ok... At present though, I'm working on some peripheral development. A program called "fisix" whose sole purpose in life is to take a closed, complex 3D model defined as a list of triangles, a mass in metric tons, scale (if you modeled at 1/Nth scale) and a resolution (defaults to 0.001) and generates: volume, density, center of mass, center of percussion and moments of inertia for the game objects. I'm developing this in C, so I can keep it portable to *nix because I'll likely be used to batch process a lot of models overnight. After I have a test model done, I'll start pkt comm code and other items more closely related to my game. The current plan: Phase 0: fisix, pkt comm. Phase 1: Free 1v1, co-op to judge consumer interest. Phase 2: commercial campaign. Incorporates Phase 1. Phase 3: Premium MMO while trying to leave the door open for expansion to other directions. Note the use of the words commerical and premium. I do intend to do this for money and I intend to make it my business. I suspect my physics engine will be too closely interwoven with the game to make it a seperate lib, but then again...who knows at this point. I'm just tackling it alone, one step at a time. I have no artist and I'm not one, I have no modeler, but I suspect I'll end up having to do that myself as I don't think a USS Enterprise will fly straight in my game. IOW, the ships will have to have some balance to the forces so they don't become giant space pinwheels. I have no musician, but music is secondary to getting a working demo going. I'm trying to not write in any other franchise's but I admit to getting this idea back in the 80s from a TSR table top RPG called "Star Frontiers," so eventually, the dream is to make this a flyable, walkable, MMO RPG space shooter. I'll also say, that I'm planning on C, I may look into C++, but I'm not fluent enough to make effecient use of it's nuances, so my plan is to use C. I've been using it since the mid 80s and I'm quite comfortable with procedural programming. My current lit resources: "3D Math primer for Games and Graphics Development," "Introduction to Game Programming using Direct3D 9" I'm also signed back up to my local U for classes in physics and math. I'll need to get to Mechanics and vector analysis before I'm happy. [Edited by - aCynic2 on September 19, 2007 12:31:31 AM]

EDIT: closed HTML 'big' tag.

Quote:Original post by aCynic2
I've owned QuickC, Zortech C++, Watcom C++, now MS VC++ 6.0 and I'm hoping OpenWatcom matures a bit faster to compete against MS's line.

Um, where did you find MS VC++ 6.0? It's something like ten years old now, and is not a proper C++ compiler. Also, MS offers up-to-date, free compilers for download. There's really no excuse for holding onto such outdated technology; nostalgia is fine for what it's worth, but...

FWIW, I've never even *heard* of Zortech, and didn't Watcom go out of business?

Disregarding all that, my game idea is massive, so massive that I got frustrated with the scale 10 years or so ago and gave up...now I'm attempting it again.

Quote:I'm developing this in C, so I can keep it portable to *nix because I'll likely be used to batch process a lot of models overnight.

Um, this is a joke, right?

#1) Lots of very fast hardware runs Windows now. For that matter, hardware is much, much, much faster than it was when you started programming. Overnight batch jobs really aren't done that much any more.

#2) For that matter, you're going to have to *use* this data in the game... how much pre-calculation do you really imagine is possible and/or useful? Finding a center of gravity, for example, is really not going to be that much work compared to all the transformations required to *render* the object several times a second. But anyway, all kinds of specialized tools already exist for this kind of stuff.

#3) Your choice of implementation language has very little to do with portability. If anything, you are HURTING portability to Unix by using C. A low-level language introduces all kinds of pain in the form of platform-specific assumptions. Higher-level languages abstract these things away, and are *widely* supported. Not to mention that *Unix*, per se, barely exists any more - it's all Linux and BSD now. (Both of which support, say, Python just fine.)

Quote:After I have a test model done, I'll start pkt comm code

You'll start *what* code? You do know that even when you're programming, the only thing that you save by leaving out letters like that is typing time (which gains are usually offset many-fold by losses in *reading* time anyway), yes?

Quote:Note the use of the words commerical and premium. I do intend to do this for money and I intend to make it my business.

Really, now; 43-year-olds are supposed to have better business sense than this.

(Snipped more dreaming and hallucination)

FWIW, I'm 26.

Quote:Original post by aCynic2
I'm still deciding on what to "upgrade" to...VC 6.0 does what I need it to do for now. I will make the move sometime. I've had VC 6.0 for at least as long as you say. Remember youngin, I was programming probably before you were born.

Great. With your extensive experience, then, you should understand the value of keeping current. Having used the compiler for a long time is not a reason to hold on to it; if anything, it's a reason to drop it ASAP.

Lots of newcomers here are still talking about VC++ 6.0. Some of the better respected posters here (myself included) are trying to figure out where all these copies of the program are coming from. You can't get them from Microsoft any more. It's ten years old. Does Windows 98 still do what you need it to do for now?

Quote:

Quote:
FWIW, I've never even *heard* of Zortech, and didn't Watcom go out of business?

You must be very young. Zortech C++ produced the smallest code on average of all the compilers, while Watcom produced the fastest. Watcom was discontinued by Sybase, but was released to the public as an open source project in 2001.

Well, I was apparently 10 when Zortech was acquired by Symantec (aren't they better known for anti-virus programs? WTF?), which I guess is young by your standards :)

But it's worth noting that in 1998, the C++ language was standardized, and is very different from what existed in 1991. Unfortunately, it took a few years for compiler writers to catch up (hence VC++ 6.0 including lots of pre-standard stuff and having serious issues with even fairly basic uses of templates), and a few more years for people to start taking it seriously. Old habits die hard, apparently.

Quote:

Quote:
#3) Your choice of implementation language has very little to do with portability. If anything, you are HURTING portability to Unix by using C. A low-level language introduces all kinds of pain in the form of platform-specific assumptions. Higher-level languages abstract these things away, and are *widely* supported. Not to mention that *Unix*, per se, barely exists any more - it's all Linux and BSD now. (Both of which support, say, Python just fine.)

Not in this case because there is at present no rendering. It's all mathematical. So the only hardware dependency is a need for a CPU. It could even be done with FP emulation, but that would take longer.

Platform-specific assumptions go far, far beyond "hardware dependencies". (Not to mention, even *cell phones* offer native FP on newer models; emulation is a thing of the past.)

Quick, what's sizeof(int)?

Quote:

Quote:Note the use of the words commerical and premium. I do intend to do this for money and I intend to make it my business.

Really, now; 43-year-olds are supposed to have better business sense than this.

And I wouldn't have thought someone so young could write in anything other than IM speak...still. Now, if we're done trading allusive insults...

[smile] I deserved that.

Quote:Yeah, and what is wrong with it? Hmmm? Doesn't it also make sense to test the market before taking out a business loan to start setting up shop to see if your produce will even sell? I could take a $1M loan, make 10 custom cars, but if they don't sell, I'd be busted and still owing > $1M to the bank.

It makes sense to do the research on the current technology, too. Especially if you're going to be heavily dependent on it.

Here's a good place to start. The articles go back quite a few years (though new ones are still being written), but sadly the industry is still much the same even as the tools march on.

You are taking the wrong approach to making your program. The very first thing that you should program is getting something on the screen. The very first. Then get some input. Then you start making the physics and gameplay. Visual feedback is so important. Otherwise all of your projects will fail and you will end up with 1 year of experience 8 times rather than 8years of experience. At least that is what happened to me.

What I do now is decide what I want to get working, then I hack it in. Then a rework my code over and over again until it is tolerable. I probably rewrite every section of code ten times, but I do it AFTER it is working, and it stays working through each iteration. If your software process is efficient then it probably doesn't work.

I have two projects. The first is a multiplayer turn-based strategy game. I plan to eventually charge 5$/month and have 1000 customers. However I am starting very slowly and building up to that. There are no phases. I just add feature after feature and constantly rework the mess. The second is a new programming language. Even though programming languages do not need fancy graphics this one generates graphviz graphs so that I can see what is going on. This goes back to the principle of getting something on the screen. Also instead of using "easy" techniques like a parser generator, I wrote the thing by hand. It is actually easier that way, because you don't need to plan.

So what I am trying to say is that planning is the enemy. I have become a successful programmer by almost eliminating planning from my process.

Quote:Original post by Glak
So what I am trying to say is that planning is the enemy. I have become a successful programmer by almost eliminating planning from my process.

That's a bit too careless.

Planning isn't the enemy. Planning poorly is. When you devise a good plan, you actually devise multiple plans: a long-term, project lifespan plan; a short-term, immediate feature implementation plan; and an intermediate, progressive from feature to feature plan. Further, you realize that you must constantly adjust your plans based on the feedback from your development cycles.

Another common planning mistake is to focus too much on what you think you will need, as opposed to what you know you will need. This is the problem with people who start out making engines, and end up either abandoning them or never quite being able to use them to make a game. Their long-term requirements were driven by imagination, which is bad development mojo. A far superior approach is to build prototypes and formalize interfaces based on the requirements of the prototypes, then build out functionality by refactoring the prototypes.

I suspect that's closer to what you actually do, Glak. I just don't want the notion that planning is a negative to be perpetuated. Planning is a positive, but only when it's done right, and doing it right is HARD.

Quote:Original post by Oluseyi
Planning is a positive, but only when it's done right, and doing it right is HARD.

That's probably where I get hit hardest, since I'm not actually sure how to plan. I can follow one without issue, but can't make my own to save my life. Know any resources? :P

Quote:Original post by aCynic2
How poor is it to plan as you go...say, start broad:

Step 1: build client
Step 2: build server

Then refine as you approach each step:

Step 1a: develop lobby function
Step 1b: develop message packet protocol.

Etc, etc.

Very poor. Your refinements are unfocused; they don't serve a specific known requirement, but only your guesstimated notions. If you had a prototype, then you could drive your requirements from that and you could build out the application in such a way that you always had a working build.

Don't underestimate the value in that. Your dedication to your project will lag - in your case, you've abandoned it before, and the way you're headed you're likely to abandon it again. Being able to kick back, fire up your game and just tool around, even if 90% of actions aren't implemented yet, can be a powerful motivator. But I won't belabor the point; I'll revisit it when I finish the article I'm working on.

Quote:I understand what you're saying. I started this project a decade or so ago, but I wanted to do it all at once and the scope was too vast. Now I'm breaking it up into manageable chunks. That's essential because the last time I couldn't attract anyone in because they didn't want part of a startup, so I must assume I am alone again. I depend on no one.

It's easier to attract people when you have something that's working and when they can easily see their changes reflected in the working version. That's another advantage of the prototype-and-refactor approach, especially for independent developers and internet teams.

Quote:Original post by Quanta_StarFire

Quote:Original post by Oluseyi
Planning is a positive, but only when it's done right, and doing it right is HARD.

That's probably where I get hit hardest, since I'm not actually sure how to plan. I can follow one without issue, but can't make my own to save my life. Know any resources? :P

Only a few rules of thumb:

1. Always have a running version. Being able to fire up your game and see it working is an excellent motivator.


2. Prototype and refactor, instead of doing a huge amount of upfront design and trying to power all the way through it.


3. Let actual usage drive your interface designs. Often people design these engines that are capable of everything and include the kitchen sink, but they can't make games with them - and isn't that the objective? - because they never really thought about the consumption of interfaces. If you write the game first, even in a tremendously stripped down fashion, then the interfaces will almost automatically suggest themselves.

There's no amount of reading that's going to substitute for experience. I came up with those rules of thumb based on failing at my own personal projects and succeeding at projects at work. As I've taken on more responsibility professionally, I've seen that the projects that adhere to these guidelines are my most successful.