Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411423 Posts in 69363 Topics- by 58416 Members - Latest Member: JamesAGreen

April 18, 2024, 03:47:08 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityTownhallForum IssuesArchived subforums (read only)CreativeAdvice for Actually Starting Projects
Pages: [1]
Print
Author Topic: Advice for Actually Starting Projects  (Read 3396 times)
it_is_coming
Level 0
***


View Profile
« on: April 23, 2009, 06:33:54 PM »

You are developing a game on your own. You have a detailed design laid out, a lovingly crafted storyline with developing characters, literary themes and meticulously planned gameplay mechanics. How do you start? Sprites? The engine? How do you go from a fantastic idea to actually getting stuff done? What are the first steps? Give your best strategies for breaking through the first wall of game development.
Logged
Chris Pavia
Guest
« Reply #1 on: April 23, 2009, 06:45:00 PM »

1st step: Do a bunch of small prototypes of your gameplay mechanics to make sure they are actually fun.  Far too many people skip this step.  Things that look good on paper may not work out as intended in practice, or may just be plain not fun to others, who don't see the game the same way you do.
Logged
Snakey
Level 2
**


View Profile WWW
« Reply #2 on: April 23, 2009, 07:05:01 PM »

That's certainly is true. I'm glad I did a prototype of CitiPlanner. It wasn't as fun as I thought it would be, and most people just felt like it was missing 'something'.
Logged

I like turtles.
ஒழுக்கின்மை (Paul Eres)
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #3 on: April 23, 2009, 07:15:58 PM »

I'd say the next step would be to get a team, preferably with people on it who have finished games before. From what you describe, the game in question seems large in scope, so I doubt one person could handle it, especially as their first game.
Logged

Ivan
Owl Country
Level 10
*


alright, let's see what we can see


View Profile
« Reply #4 on: April 23, 2009, 07:16:05 PM »

starting is usually not the problem, it's finishing that's the real challenge
Logged

http://polycode.org/ - Free, cross-platform, open-source engine.
ChevyRay
Guest
« Reply #5 on: April 23, 2009, 07:54:31 PM »

Quote
You are developing a game on your own. You have a detailed design laid out, a lovingly crafted storyline with developing characters, literary themes and meticulously planned gameplay mechanics. How do you start? Sprites? The engine? How do you go from a fantastic idea to actually getting stuff done? What are the first steps? Give your best strategies for breaking through the first wall of game development.
Prototype prototype prototype. Don't set out one some huge endeavor (or even a small one, actually) until you've prototyped the ideas you have in mind and are sure they work. This comes before rounding up team members, before writing music, before concept art, before anything else.

If you work out a successful prototype, then you're game. Share that prototype with the people you want to work with, explaining best you can how this will work out to be a game, and then start structuring and desiging the game around that prototype.

From a personal standpoint, I value sketching very highly, and assign most of the credit for the amount of work I get done to sketching. I write notes, draw diagrams, make lists, and have copious amounts of the game designed on paper and filed before I ever touch the game's code or resources. Usually it goes something like this...

1) Sketch your prototype ideas and general functionality, deciding how it will work and the rules of how the prototype will operate. Revise your sketches, making sure to locate any problems/loopholes beforehand, so you don't run into them after you've already programmed a whole bunch. And remember: flow charts are your friend.

2) Program the basic prototypes and refine them further. You'll always run into unforseen problems and opportunities when programming that never occurred to you while sketching, so come to expect it. Quite often this is where the best ideas come from, because you get a feel for how your prototype behaves, and more ideas for the game start forming in your head.

3) Back to sketching. Take a step back from your prototype and get out of programming mode. Think of what your game should be, what would be fun to play, and how you can best use this prototype to create an enjoyable gaming experience. Refine your ideas as much as possible and keep your information organized and presentable so that you can share and discuss it with your teammates or other people for feedback.

4) Now we get to creating the game. I've always made a point of programming the game's basic engines and layout first, and worrying about sound, music, and hefty resources like backgrounds and extensive animations for later on, or last even. Separate your game into specific goals, and write these down. Take on these goals one at a time, so you can concentrate on each aspect specifically and refine it the best you can. From this point on, the flow of the project is pretty specific to what you're making, but you should be getting a hang of the project workflow now, so things should take off on their own from there.
Logged
it_is_coming
Level 0
***


View Profile
« Reply #6 on: April 23, 2009, 08:08:27 PM »

Wow, awesome advice, everyone. I will definitely keep all of this in mind when embarking on my first large game project.

On the topic of flowcharting, I've never been able to make it work with large games. It seems to me that flowcharts are more geared towards state-based programs, not games. I haven't really experimented much with them before.
Logged
ChevyRay
Guest
« Reply #7 on: April 23, 2009, 09:23:10 PM »

Quote
On the topic of flowcharting, I've never been able to make it work with large games. It seems to me that flowcharts are more geared towards state-based programs, not games. I haven't really experimented much with them before.
They are if you use them in a purely technical sense. But for brainstorming, and managing your idea flow, they're great. They can give you a visual perspective of your game's assets, and show you where your game is lacking in ideas, allowing you to branch out from there and perhaps see connections in things that you'd otherwise not notice.

For me, it's really good, because I don't have the best spacial skills. If you have fantastic spacial skills, flow charts might not be neccessary at all for you. But knowing how to use them properly helps me endlessly with my projects.
Logged
mirosurabu
Guest
« Reply #8 on: April 24, 2009, 11:21:37 AM »

One very important step that isn't mentioned yet, but it's important for both large and small games - test your abilities if you haven't yet. Prototypes and large games designs usually present some new challenges. New challenges come with new designs.

Test your programming abilities. Can you really come up with solution to particular problem? If you haven't done such thing before or if you're not sure - prove yourself that you can do that. By making simple test program with or without flowchart on the paper. For simulation games, where I have to make sure that calculations are working correctly, I rely on paper, but I use test programs in some situations. For problems involving spatial interaction (spatial movement, visual effects, collisions, physics, etc) both paper and test programs are of great value.

Testing your abilities and improving them as you go along is possible, but can be quite frustrating and may push you away from game development. I used to do this in the past.
Logged
Alec S.
Level 10
*****


Formerly Malec2b


View Profile WWW
« Reply #9 on: April 24, 2009, 11:32:59 PM »

Usually I get started on a project rather late at night.  I try to make some basic assets which I can then play with once I start actually designing.  This takes the form of sprites and basic objects.  This is because I'm not very good at sprite making so I like to get some of that out of the way before I start the actual implementation.  I generally also try to do a rapid prototype in about 3 hours to get the basic idea of the game down and test it out.  I then start working seriously the next day making a more polished prototype.
Logged

fogfighter
Level 0
*


View Profile
« Reply #10 on: April 26, 2009, 12:08:59 PM »

Oh, it's quite easy. First you decide what you have to do. Then you just do it  Smiley

Easier said than done of course. The starting-small-advice from the more experienced tigers seems very useful.

Keep up the good work.

fog  Gentleman
Logged
I_smell
Level 5
*****



View Profile
« Reply #11 on: April 30, 2009, 01:34:05 PM »

I usually make arcade action games like fighters, shooters, platformers etc.

I start by deciding roughly what genre I want to make, and thinking up similar games that I want it to play like. Then I draw the main guy a load of times while thinking of an aesthetic. Once the main guy looks good, I make the engine of them moving and try to find the right amount of speed, jump height, sprite size, game dimensions etc. Then I think about the game every second I'm not making it and carry on.
Logged
nihilocrat
Level 10
*****


Full of stars.


View Profile WWW
« Reply #12 on: May 03, 2009, 07:28:27 PM »

I do it all bass-ackwards...

I get some sort of fairly simple idea in my head, then get to coding. I should probably really plan out the coding better, but I'm happy with not planning out the design because then I'm less disappointed when the game never lives up to the design.

Because of this, whenever I get a complicated design in my head, I write it down in a particular document I have sitting around and then, usually, never think about it again. I found this really helps me not get distracted on my current projects. This self-discipline is something I probably should have developed years ago, and it would have led to more finished games earlier in my life.
Logged

JasonPickering
Level 10
*****



View Profile WWW
« Reply #13 on: May 04, 2009, 12:22:20 PM »

I usually start with an idea. then move in to researching other games that have similar mechanics. if you can see the short comings of what has already been done before you this helps mold you. (example: I am working on a platformer so i played lots of platformers, Mario and Megaman handle very differently. which one works right for me and my game.)

I also do a lot of sketching and note taking. I will usually do some mock coding in a note book. nothing serious just stuff like "Press A player jumps, plays jumping animation". Also I agree with what everyone has said about prototyping and dynamic prototyping. if you are making a platformer maybe pressing 1 and 2 add and decrease from gravity, and 3 and 4 change jump power. these are very valuable because it allows you to fine tune the engine on the fly without having to exit out, change code, and do another build, and by doing that possible forgeting how the game handle before you changed anything.

and lastly do as much research as you possibly can before you undertake anything gigantic. Playing games, looking at games, reading books, watching movies all this helps.
Logged

ஒழுக்கின்மை (Paul Eres)
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #14 on: May 04, 2009, 12:32:05 PM »

that just gave me an idea for an all-purpose function. imagine something like this:

test_variable = "variablename";

you could change what test_variable is for different builds, and then pressing + or - would increase or decrease that variable by some percent (with its current name and value shown on the screen). i think i'll implement something like that now, it should be pretty useful when tweaking mechanics. you could even get fancy and have a list of variables that can be changed in-game, and a way to cycle through them and choose them while playing.
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic