Re: Gaming Engines

From: "MindShift Design" <teammsd@mindshiftdesign.com>

Date: Mon, 30 Oct 2000 06:17:32 +0000

"MadCentral" <madcentral@aol.com> wrote in message
news:20001027100454.28853.00001705@ng-bh1.aol.com...
> >>Opening up the conversation here helps me focus my thoughts as well as
see
> what other developers think.<<
>
> Well, heres what I think! <grin>
>
> (1)  You'll never do it in 6-9 months and make it any good.

Make the engine any good, or the games themselves ? They are two very
distinct seperate parts to this. Within the time frame we feel we can make
the engine work as required. As for creating good games that's another thing
altogether ...

> (2)  No amount of experience you think you have will help you make a
decent
> game engine.

I'll beg to differ. A game engine is no different from any other programming
application that can be developed. It has to be very carefully designed,
created and implemented. In fact the original game program for STSI worked
great. It was written in Delphi and used full OOP programming techniques to
their advantage with eliminated a lot of repetitive code. It worked great,
but it was specific to STSI only. The engine is a software product, and
there's no such thing as a "decent" software product, which is a subjective
term - what may be decent to you isn't to me.

Or do you mean decent in that the games that it will run will be fun to play
? That's up to the design of the game itself and how it handles gameplay.

> (3)  Planning it all out on paper as you go wont help you get the
documentation
> right at the end.

Once again I'll beg to differ. No rapid application development can occur
without first creating design documentation, and documenting change and
development practices and code as you go along. The documentation practices
we use are the same that are used by large software development companies
such as Microsoft, Borland, Corel, etc. They seem to work well enough for
them, and they've always worked for us. It's always better to adapt
documentation as you go than to retrofit documenation on a complete project.
That's why there are technical writers that work on development projects. If
you've ever had to reverse engineer a software API because the documentation
was incorrect then you'll know why documenting as you go is the ONLY way to
develop the documentation. It means that everyone that needs to know about a
function has the correct up to date information. It means that everyone
knows what each function, procedure, variable or element in a program does
without have to spend ages working through other lines of code and
backtracking. It also means that you have a solid base to create
modifications in the future or create new versions of the program.

I'm sorry Steve, but to my mind taking three years to write an engine, then
having a new programmer spend a year using it and not be able to know all
the features of that engine because the documentation isn't written is NOT a
sound development practice. I'm not saying it hasn't worked for you, because
it obviously has as the Nexus engine is operating and you are making revenue
from it. But think of all the time that your new programmer could have saved
if the engine were properly documented. Yes, documentation adds extra time
to a project. But it stops you losing a whole more time in the future. And
debugging is hell if you have to work on someone else's code. Everyone
code's differently. I remember having to repair some software that was
written by another programmer and who left little documentation. What should
have taken a day to repair took a week because I had to go through the
entire program and work out exactly what the hell was going on in the
program. He was using multiple variables to perform the same function for
different elements and hadn't documented them at all, when he could and
should have used the same variable all the time.

We develop software commercially everyday and have for years, and I know
that the products I've been involved with have had documentation developed
through the lifecycle, and that it's alwasys eased the process. That's why
Fortune 500 companies are continually happy to use our services for
development.

> (4)  Planning it all out on paper beforehand wont help you get the game
engine
> right.

"Right" in what way ?

That it won't perform as it's supposed to and run games ?

If you don't plan the engine in the first place then how can you build it
with the expecations to make it a solid extensible product that will perform
as it's supposed to. Plans are always subject to modification. I'm not
saying write the code out on paper before you write it into the program.
There are many stages to go through; discovery, design, development,
deployment etc. Writing up the tech specs, program specs, langauge and
variable standards, feature information etc all make a solid foundation to
build a program on. With the pseudocode stage of writing, you can plan out
the entire program and know how its supposed to perform. Then you can go in
with all the information you need for you and your team to develop the
entire application without having to retrofit code or features. Sure there
are some elements that may not operate as they're supposed for various small
reasons. But they won't be as many as when you DON'T plan the engine
properly.

Or "right" in that the games that it will run won't be good ? The engine is
completely different from the the games themselves. That's the whole point
of using scripting for this. The engine will only do what the scripts tell
it to do, and if the scripts are badly written then the engine will detect
that.

> But I'll look forward to seeing what happens.  We did all this a few years
ago
> now and learnt some very strong lessons along the way.  The *main* thing
that
> we learnt is that if we *had* tried to plan it all out before we started
it
> would never have got done.

Right now we're looking at another 2 months of design for the engine. We've
already isolated a lot of the core features and started our documentation.
We know a lot of the technologies it's going to use. We know how it's going
to interface with databases (any database we choose - we could even switch
database systesm at any point from MS SQL to Interbase to DB2 to Oracle if
we wanted to). We know that we're going to use a custom XML specificaiton
for the reading and writing of game information before it's delivered in the
delivery package (email, PDF, mail, fax, web or client program). We know
what language the engine will be coded in, and how the scripting will be
processed. We know how the engine will handle low level functions such as
reading/writing files, interfacing with databases, handling variables. We
also know how we'll handle the modular script creation, game scripting
seperation to allow multiple games to be run, including variants of the same
game. We've even worked out the debuggin functions on a per game and at the
procedural level to allow us to check that the scripts are working before we
run them live. There are 1001 other things we're worked out in our heads and
on paper that are being transformed into proper documentation now.

So I guess we'll see in 6-9 months. <g>.

For those that are interested, during the development period we're going to
post the progress of the engine development at the Claymore Games website at
http://www.claymoregames.com. There's only a placeholder there at the
moment, and the real site will go up on 1st Dec 2000. There'll be a whole
section dedicated to the engine.

--
Jason Paul McCartan - jasonm@mindshiftdesign.com
CEO/President
MindShift Design LLC
http://www.mindshiftdesign.com

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

References

Re: Gaming Engines
"MindShift Design" <teammsd@mindshiftdesign.com>
Wed, 25 Oct 2000 00:00:00 +0000
Re: Gaming Engines
madcentral@aol.com (MadCentral)
Fri, 27 Oct 2000 14:04:54 +0000

Referenced By

Re: Gaming Engines
"MindShift Design" <teammsd@mindshiftdesign.com>
Wed, 25 Oct 2000 00:00:00 +0000
Re: Gaming Engines
madcentral@aol.com (MadCentral)
Fri, 27 Oct 2000 14:04:54 +0000