gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Prototyping: What's Your Method?

#66989 - qw3rky - Sat Jan 14, 2006 10:22 pm

I was wondering: what do you guys use to prototype your game projects? Do you just go straight into C/C++ and work out your issues with emulators? Or do you start out with a more flexible (and easier to debug) environment on the PC side and transfer it over once your engine/idea is more fleshed out? I've been testing out a number of platforms/ideas: JavaScript with a browser and some images (very useful when I'm away from my own computer), Flash/ActionScript, Blitz Basic, LuaPlayer for Windows (pretty much the one thing I envy from the PSP homebrew scene), Pike + SDL, C + SDL, and Python + Pygame. I'm looking for something that would allow for quick testing (so you can bet that it would involve a scripting language), but similar syntax to C for easy conversion to a GBA or DS project (I'm talking renaming the source file from main.* to main.c and fixing a few keywords). So far it looks like I'm going to settle on Flash (possibly with MTASC and SEPY instead of the official IDE), but I wanted to hear some other opinions. So what do you guys use?
_________________
I've coded about 17 different implementations of Pong. It's the game dev's "hello, world".
DualScheme - Scheme Interpreter for DS

#67188 - ScottLininger - Mon Jan 16, 2006 3:56 am

I sometimes use flash for mockups and basic testing of ideas, since it's so much faster to get something up-and-running in that environment.

But most of the projects I've worked on have been so engine-specific that it wouldn't be worth it to build it somewhere else first.

-Scott

#67199 - MrD - Mon Jan 16, 2006 4:58 am

C + Allegro is great for fiddling and faffing.
_________________
Not active on this forum. For Lemmings DS help see its website.

#67636 - Codax - Thu Jan 19, 2006 5:55 pm

75% of my prototyping is done with Pencil and Paper

Once I have a nice list of things that I need I head into Photoshop to double check my scale and create some assets.

Then I just drop everything I need into my Mode0 template. From there its all playing around with values and animations to get the player interaction clean first. Then, just build the game around the initial code. While I try to stay away from constant re burning, I always double check my assets & interaction on the actual hardware....you'd be amazed at some of the differences that can pop up!
_________________
Codax
Dragon's Den Unlimited
http://www.DrgnDen.com

#67748 - sgeos - Fri Jan 20, 2006 2:48 am

Flash strikes me as the ideal prototyping solution.

-Brendan

#67906 - tepples - Sat Jan 21, 2006 6:44 am

sgeos wrote:
Flash strikes me as the ideal prototyping solution.

How do I get a job so that I can earn $699 for a copy of Flash?

That's why I use C and Allegro, in addition to the fact that I can carry over much of my game's business logic verbatim to the GBA. This is part of the reason I was able to get TOD working in a reasonable amount of time while also dealing with schoolwork.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#68352 - Codax - Mon Jan 23, 2006 10:50 pm

An academic version of flash can run from $0 to $99 depending on your school's software policy. Academic Flash is identical to retail flash...and...I'm sure certain "enterprising" individuals can get a copy to hold them over until they raise the money.
_________________
Codax
Dragon's Den Unlimited
http://www.DrgnDen.com

#68393 - tepples - Tue Jan 24, 2006 6:13 am

Codax wrote:
Academic Flash is identical to retail flash

Watch out: Some publishers of proprietary software have started to time-lock academic versions' product keys so that they expire 365 days after purchase.

But even if Flash were generally affordable, I'd still stick with GCC based solutions because 1. it's free, 2. it's Free, and 3. I'm pretty sure that porting business logic from C to C is easier than porting business logic from ActionScript to C. (Here, "business logic" refers to the rules of the game considered separately from input or output details.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#72736 - tonkinfash - Tue Feb 21, 2006 7:17 am

When I developed a random number generator for the GBA (using 1D cellular automata - Wolfram's rule 30) I tested it in a Win32 console app until I was satisfied with its randomness.

#72756 - sgeos - Tue Feb 21, 2006 1:36 pm

tepples wrote:
I'm pretty sure that porting [the game rule code] from C to C is easier than porting [it] from ActionScript to C.

It is, but I'm convinced that the game spec is more important than the first pass at programming it- especially if the programmer is the same person. The second pass will be much cleaner. You use flash because it makes dealing with assets dead simple.

I find Flash's weak points are files (because it's sandboxed) and modifying individual characters in strings.

-Brendan

#81991 - DakeDesu - Wed May 03, 2006 8:58 am

I would like to set up a system where I can test components, and put them all together.

I find debugging is easier if I know the parts work, and it is the connections between them that is the problem.

Remember, MVC is your friend.
_________________
[ Main Site | Kid Radd Fan Project | Forums ]

#82028 - SevenString - Wed May 03, 2006 5:13 pm

For game dev, I don't prototype at all.

If I'm doing an engine from scratch, I work from a game design to spec out what the engine needs to do. In doing the engine spec, I generalize where it makes sense to do so because designs DO change. Also, if any scripting or custom tools are called for, I spec out the scripting language and the tools as well.

For the first stage in actual coding, I write headers based on the specification's engine components. I usually never create or open a .c/.cpp file until those headers are fairly complete. This applies to tools as well as the engine.

Once I do get into coding the actual methods, I focus on getting data from the artists/designers into the engine as soon as possible. At this stage, I tend to ignore visual fx and audio, other than to make sure that the hooks are in place to support these things when they ARE implemented.

Next up is fleshing out scripting, and working on tuning player controls. By this time, I've probably done some work on getting the audio going. When the above tasks are reasonable complete, the artists and designers have most of the tools they need to "make the game".

The rest is visual fx implementation, beefing up audio support, bug fixes, menus, and any feature creep that HOPEFULLY will be handled by the generalization that I deliberately built in early on.

Believe it or not, these methods work for me whether I'm doing an FPS, a high-end 3D action platformer, or a simple old-skool 2D SNES type game. Obviously the simpler games need fewer/simpler tools, and maybe the "scripting" becomes more of just having a declarative system for calling out level components, but the overall approach still works.


However, interestingly enough, I do a LOT of prototyping these days, just not game engines. I work at a visual fx studio doing R&D, so I do proof of technology prototypes all the time.
_________________
"Artificial Intelligence is no match for natural stupidity."

#86130 - ninjaboyjohn - Sun Jun 04, 2006 5:14 pm

For prototyping basic gameplay ideas, Processing might work well. It's kind of a layer on top of Java, made for getting visual applications up and running in a short period of time - http://www.processing.org/