next »

[iffi]

I ddefinitely feel your pain. The main game i want to make is an RTS but i haven't anywhere near the skills to do so. That's why i'm starting with simpler ideas.

You can start small without resorting to my-first-tetris, y'know?

Make an RTS with one unit, a top view map, some jukespots and a simple combat mechanic.

You can keep adding to that as you go and you might eventually get the RTS you want!

That... might not actually be a bad idea! The thing is, i eventually will want several specific mechanics, as well as quite a lot of flexibility, which means that even the 1 topdown unit thing will need a metric tonne of code to be expandable in the direction i want.

I, too, have gotten myself stuck by worrying about future flexibility. I think the best way to get started is to not worry about it (though I have to admit I'm terrible at that). It's better to have to redo a lot of stuff later than to not get started at all.

[GameRoom]

I have this project I'm working on that I've wanted to do for like a year or something. I'm so intimidated by it I haven't even started on the menu. I've been working on it for almost a week.  

[Nix]

Don't wanna make simple games? Go ahead and make complex ones.

Fail miserably.

Get up.

Try again.

Fail less miserably.

Eventually you'll get there. Just get to work.

This really is perhaps the single most helpful piece advice to any new developer who doesn't know how to get started, or who doesn't think that he/she has the skills. Everyone started out with no knowledge, and slowly built up their knowledge and skills through experience, and the only way to get that experience is to push your boundaries and do something that you don't think you can. Even if the project never sees fruition, you will have learned, through trial and error (the best way), what you should and should not do when making a game. Plus, there seems to be this 'veil of understanding' where people don't have a full grasp of what exactly it is to develop games (even if they think they do), and just breaking in and trying it for yourself will give you whole new insight into not only what you can and can't do, but what you need to learn in order to take the next step.

[gimymblert]

melly you can't be quote enough here

[J.W. Hendricks]

See: Super Mario Bros.

[Rob Lach]

You just explained one of the pitfalls of the AAA game industry. Don't underestimate the power of art from adversity.

[voidSkipper]

I ddefinitely feel your pain. The main game i want to make is an RTS but i haven't anywhere near the skills to do so. That's why i'm starting with simpler ideas.

You can start small without resorting to my-first-tetris, y'know?

Make an RTS with one unit, a top view map, some jukespots and a simple combat mechanic.

You can keep adding to that as you go and you might eventually get the RTS you want!

That... might not actually be a bad idea! The thing is, i eventually will want several specific mechanics, as well as quite a lot of flexibility, which means that even the 1 topdown unit thing will need a metric tonne of code to be expandable in the direction i want.

No, you don't. Trust me - I learned this the hard way, and the sooner you do, the better.

Flexibility for the sake of flexibility is the surest way to kill a project. Unless your code is godawful, I will guarantee you 100% that it is easier to go back in and hack in some flexibility than it is to get bogged down trying to allow for every possibility.

Think about it - how many kinds of units are you going to have? 5? 10? 20? You're almost certain to spend more time making your code needlessly flexible than you will actually using that flexibility in a meaningful way.

Build a "unit" base class. Give it some useful template methods. Override them for each different unit.

[moonmagic]

No, you don't. Trust me - I learned this the hard way, and the sooner you do, the better.

Flexibility for the sake of flexibility is the surest way to kill a project. Unless your code is godawful, I will guarantee you 100% that it is easier to go back in and hack in some flexibility than it is to get bogged down trying to allow for every possibility.

Think about it - how many kinds of units are you going to have? 5? 10? 20? You're almost certain to spend more time making your code needlessly flexible than you will actually using that flexibility in a meaningful way.

Build a "unit" base class. Give it some useful template methods. Override them for each different unit.

Furthermore! Designing broadly from the beginning can prevent you from evolving your design based on what has worked. Game design gets overwhelming very quickly when you have a broad, inclusive, crazy-town design document from the very beginning. You want to start with a microcosm of a game, and make sure it is fun. After that, you start embellishing and iterating. At least for early attempts at making games, in my admittedly limited experience.

[RCIX]

However, the thing is, i know i'd end up jettisoning my work and starting over a bunch of times. It happened with one of my failed projects (failed to plan for the proper design and enough flexibility, and eventually decided to partially start over)

[Nix]

However, the thing is, i know i'd end up jettisoning my work and starting over a bunch of times. It happened with one of my failed projects (failed to plan for the proper design and enough flexibility, and eventually decided to partially start over)

Then try to plan ahead, but don't get religious about it. If you don't do things right the first time and screw up and have to start again, the second time through you will have learned valuable lessons and made mistakes that you are likely not to make again. It's a learning experience and it's totally worth it. I often make one or two false starts on projects as I try to get a feel for how I want to do them. It's just part of the process.

[voidSkipper]

However, the thing is, i know i'd end up jettisoning my work and starting over a bunch of times. It happened with one of my failed projects (failed to plan for the proper design and enough flexibility, and eventually decided to partially start over)

I'm not telling you to just go balls-out and wing it by any means. Save that for time-limit-development minigames etc.

Design your core game mechanic, make it work. Then work from there. If you have to throw everything out and start again from that point, it means you've implemented unmaintainable code. A ridiculously deep design document probably wouldn't have saved you, and analysing it and learning from it is your best course of action.

[RCIX]

The final obstacle is i (should be) am immersed in another project right now, and don't want to drop that one. Other then that, i could probably take a shot at some point

[yesfish]

I reckon this is a fear of failure? A larger project means you won't have to face the ending and it's easier to rationalize not being able to make something uber-complex over something that 'should be easy'.

[Muz]

If you want to interesting games, then just plan your way up there. Take small steps. If you want to make a grand strategy game, start with simple board games, add some multiplayer code to it, move to a simple turn based strategy, then start working with more and more complicated games.