Re: Re: Developing new games:

From David Shadoff <xxxxxx@interlog.com>
Date
>Hmmm if this developing a new game idea takes root I'd love to help in 
>the artistic area.  But one thing.  How easy is the Turbo to develope 
>for?  I aim this question at the gentlemen on the list who made some 
>homebrew already. 

I've written a version of Tetris ("Blox" - in assembler), and a version of
Othello ("Flipit" - in 'C') for the PC-Engine.

While the basis for Tetris is actually about the same difficulty as
Othello, the game took a long time and a lot of hard thought - several
weeks of spare time - because it was written in assembler.  Most of the 'C'
game was put together in a single weekend.

But adding all of the 'release quality' finishing touches can take a lot of
time in either language - the title screen, high score saving, etc.  This
is because there really is a lot more to a game than just the raw game itself.

The piece which takes the most time for me is preparing the graphics - but
that's because I'm not an artist, and I'm probably not using the best
graphics software to prepare it either.  (And I still haven't done anything
with music yet...)

>If you look at the Turbo library, games like ninja Gaiden and Ys 1 and 
>2 were riddled with choppy scrolling. It took developers a while to 
>over come a intial limiting factor.

I don't think Ys 1 and 2 had choppy scrolling... but I will agree that some
games just didn't work well.

This is basically because of either:
(a) the programmer's approach,
(b) time constraints to release the software by a certain date, or
(c) something about the game definition that was too demanding of the
machine's resources (like pixel-perfect collision detection on a complex
figure).

Keep in mind that the developers weren't all experts about the hardware,
and weren't necessarily great programmers (although some certainly were both).

And they weren't able to modify their tools to improve their programming
either; this is something that we are certainly able to do.  In fact, I
wrote both of these games to get some experience with the tools and
understand what new features were needed.

>The kind of game is important.
>A RPG seems a bit big for a first game.

Certainly - big, but not impossible.  But a single dungeon would be a good
proof-of-concept.

> A simple shooter or platformer would be a great start.  I bet we could 
>make a decent game in the vien of Parasol Stars, Circus Lido, Pop N 
>Magic. 

Action-Puzzle games are an easy 'first try'.
Digital comics are also easy (although they need large amounts of
comic-quality graphics).
Shooters and platform-style games are also currently within our scope, but
may require a bit more skill to ensure good speed and smooth scrolling.

> Heh hee if we do produce a game I don't think we'll have hit with the 
>first game, definitely worth the effort though!  *-neo 

I agree.

The first game or two would probably only rate 'release quality' based on
the novelty of a newly-developed game.  And many people would want the
games on that basis alone.

We would also gain practice on this system, decide on enhancements for our
tools, and create useful code that could be re-used later on similar games.

In your own mind, compare 'China Warrior' against 'Bonk's Adventure', and
you'll see that time and experience certainly make a difference.