Basic game creators

Some time ago I took a *quick* look at some of those Basic-based
game-creation engines. I figured that they're not that much easier to use
than C/C++, as they still had quite a big and elaborate API. The language
itself looked like a mix between BASIC and C. I ussually program DirectX
games in C/C++, so I figured using one of those BASIC game engines wouldn't
result in that much of a productivity improvement. But lately, after reading
some posts in this NG I've been starting to get some doubts.

Anyone who has used both one of those game engines and C/C++ willing to
comment on the gain in productivity? Thanx in advance.

"Ultimate Buu" <majjinbuu@dragonball.z> wrote in message
news:3f2e5f4f$0$146$1b62eedf@news.wanadoo.nl...
> Some time ago I took a *quick* look at some of those Basic-based
> game-creation engines. I figured that they're not that much easier to use
> than C/C++, as they still had quite a big and elaborate API. The language
> itself looked like a mix between BASIC and C. I ussually program DirectX
> games in C/C++, so I figured using one of those BASIC game engines
wouldn't
> result in that much of a productivity improvement. But lately, after
reading
> some posts in this NG I've been starting to get some doubts.
>
> Anyone who has used both one of those game engines and C/C++ willing to
> comment on the gain in productivity? Thanx in advance.

Well, I have been a professional C/C++ programmer since 1996, working mostly
on set top box graphics code, and about 2 months ago I bought DarkBasicPro.
Their was a HUGE productivity increase.

In the old days, when I was coding my own C++ directX stuff, I would always
begin each project by building a library. Exatracting out the subset of
directX that I cared about. These libraries always seemed to be re-written,
no matter how much I told myself that I would re-use them. The reason for
this is of course that I was always learning new and better ways to do
something. I skipped this whole step with DB.

If you read a lot of postmordems in game developer, they talk about how most
C++ game teams have a "3D Engine" programmer,. a "Network" programmer, a
"Gameplay" programmer... If you use DB, you will be doing almost exclusively
the "Gameplay" stuff.

Having said this, their are some things that cause some serious slow downs
at first. And their are some features missing from the language that drive
me nuts, but I don't think I'll be using C/C++ for a game project for a
while.

Tony

"Tony Di Croce" <iaretony@hotmail.com> wrote in message
news:00c085f04cd4fc87ad94684b3ad18929@TeraNews...
>
> "Ultimate Buu" <majjinbuu@dragonball.z> wrote in message
> news:3f2e5f4f$0$146$1b62eedf@news.wanadoo.nl...
> > Some time ago I took a *quick* look at some of those Basic-based
> > game-creation engines. I figured that they're not that much easier to
use
> > than C/C++, as they still had quite a big and elaborate API. The
language
> > itself looked like a mix between BASIC and C. I ussually program DirectX
> > games in C/C++, so I figured using one of those BASIC game engines
> wouldn't
> > result in that much of a productivity improvement. But lately, after
> reading
> > some posts in this NG I've been starting to get some doubts.
> >
> > Anyone who has used both one of those game engines and C/C++ willing to
> > comment on the gain in productivity? Thanx in advance.
>
> Well, I have been a professional C/C++ programmer since 1996, working
mostly
> on set top box graphics code, and about 2 months ago I bought
DarkBasicPro.
> Their was a HUGE productivity increase.
>
> In the old days, when I was coding my own C++ directX stuff, I would
always
> begin each project by building a library. Exatracting out the subset of
> directX that I cared about. These libraries always seemed to be
re-written,
> no matter how much I told myself that I would re-use them. The reason for
> this is of course that I was always learning new and better ways to do
> something. I skipped this whole step with DB.

Yeah, I can relate to that. Like most other people I've tried to built a
complete DirectX library, including sprites, sound and networking
(multiplayer). It would be nice to just to be able to concentrate on the
game logic.

>
> If you read a lot of postmordems in game developer, they talk about how
most
> C++ game teams have a "3D Engine" programmer,. a "Network" programmer, a
> "Gameplay" programmer... If you use DB, you will be doing almost
exclusively
> the "Gameplay" stuff.
>
> Having said this, their are some things that cause some serious slow downs
> at first. And their are some features missing from the language that drive
> me nuts, but I don't think I'll be using C/C++ for a game project for a
> while.

Could you be more specific about the slowdowns? The language itself seems a
drawback as BASIC is any C++ programmer's nightmare. I would rather have
seem them using a sort of C/Basic variant, with a greater slope towards C
(but not C++).

> Could you be more specific about the slowdowns? The language itself seems
a
> drawback as BASIC is any C++ programmer's nightmare. I would rather have
> seem them using a sort of C/Basic variant, with a greater slope towards C
> (but not C++).

That would be Blitz 3D...

http://www.blitzbasic.com

Andy

> Could you be more specific about the slowdowns? The language itself seems
a
> drawback as BASIC is any C++ programmer's nightmare. I would rather have
> seem them using a sort of C/Basic variant, with a greater slope towards C
> (but not C++).

First I will list some positives. Their are functions in DarkBasic.

function inc( a as integer )
a = a + 1
endfunction a

Their are also user defined types:

type foo_t
a as integer
b as integer
endtype

Their is built in support for dynamic lists, stacks and queues.

DB also has all of the looping constructs that C does. It also has all of
the comparison statements (if, if else).

I love C++ as much as the next guy, but UDT's and functions are all I really
need to write good structured code.

Now for some of the bad stuff:

- You cannot pass UDT's to functions directly (I believe that the
upcoming patch adds this).
- You cannot pass dynamic arrays to functions
- Little things sometimes slow you down (for instance it took me a day
to realize that sin() expected degrees not radians())

In all, their is far more good stuff than bad stuff. I really like the
language a lot. You will write a lot less code to complete a game. My games
don't exactly push the hardware to it's limits, so DB is perfect for me. I
may not have all of the language constructs that I love, but using TYPE's
and functions allows me to write code that reminds me a lot of my C / Pascal
days.

Tony

Tony Di Croce wrote:

> > Could you be more specific about the slowdowns? The language itself seems
> a
> > drawback as BASIC is any C++ programmer's nightmare. I would rather have
> > seem them using a sort of C/Basic variant, with a greater slope towards C
> > (but not C++).
>
> First I will list some positives. Their are functions in DarkBasic.
>
> function inc( a as integer )
> a = a + 1
> endfunction a
>
> Their are also user defined types:
>
> type foo_t
> a as integer
> b as integer
> endtype
>
> Their is built in support for dynamic lists, stacks and queues.
>
> DB also has all of the looping constructs that C does. It also has all of
> the comparison statements (if, if else).
>
> I love C++ as much as the next guy, but UDT's and functions are all I really
> need to write good structured code.
>
> Now for some of the bad stuff:
>
> - You cannot pass UDT's to functions directly (I believe that the
> upcoming patch adds this).
> - You cannot pass dynamic arrays to functions
> - Little things sometimes slow you down (for instance it took me a day
> to realize that sin() expected degrees not radians())
>
> In all, their is far more good stuff than bad stuff. I really like the
> language a lot. You will write a lot less code to complete a game. My games
> don't exactly push the hardware to it's limits, so DB is perfect for me. I
> may not have all of the language constructs that I love, but using TYPE's
> and functions allows me to write code that reminds me a lot of my C / Pascal
> days.
>
> Tony

OK thats the basic (pun intended) language. Now whats the game engine
interface
like?? (cant pass UDT - thats gotta be messy.. unless everything is just
global.)

Getting the goodies out of the game engine, doing your magic/crunching, and
then
directing the engine to get something done -- how easy/clunky is that.

Is there a decent event model ??
Is there enuf flexibility in game engine (not constrained to a quite limited set
of options)

I forget if I check this before -- is it truly compiled, or a bytecode
interpreter (or worse RT parsed)

um... yeah.....

it's basic... keeps a lot of that pipeline stuff hidden from the user.
There are some more advance functions built in, like memblocks that work
like pointers or references.... uh.... it seems to move pretty fast on the
rendering pipeline... although it still has some bugs. You can "cheat" the
program and make a lot of your own culling algorithms to speed it up. You
can also use third party DLL's if you really want to. If you use all the
premade game commands and built in functions you'll get a game that looks
like it's about 2 years old and runs at a good speed. Dark Basic Pro is
compiled, regular Dark Basic is interpreted. You know,
www.DarkBasicProfessional.com has all this info on it, plus a whole lot
more!!!

in article 3F35AABB.EFA590D8@oneeye.com, Eternal Vigilance at
wotan@oneeye.com wrote on 08/09/2003 21:14:

>
>
> Tony Di Croce wrote:
>
>>> Could you be more specific about the slowdowns? The language itself seems
>> a
>>> drawback as BASIC is any C++ programmer's nightmare. I would rather have
>>> seem them using a sort of C/Basic variant, with a greater slope towards C
>>> (but not C++).
>>
>> First I will list some positives. Their are functions in DarkBasic.
>>
>> function inc( a as integer )
>> a = a + 1
>> endfunction a
>>
>> Their are also user defined types:
>>
>> type foo_t
>> a as integer
>> b as integer
>> endtype
>>
>> Their is built in support for dynamic lists, stacks and queues.
>>
>> DB also has all of the looping constructs that C does. It also has all of
>> the comparison statements (if, if else).
>>
>> I love C++ as much as the next guy, but UDT's and functions are all I really
>> need to write good structured code.
>>
>> Now for some of the bad stuff:
>>
>> - You cannot pass UDT's to functions directly (I believe that the
>> upcoming patch adds this).
>> - You cannot pass dynamic arrays to functions
>> - Little things sometimes slow you down (for instance it took me a day
>> to realize that sin() expected degrees not radians())
>>
>> In all, their is far more good stuff than bad stuff. I really like the
>> language a lot. You will write a lot less code to complete a game. My games
>> don't exactly push the hardware to it's limits, so DB is perfect for me. I
>> may not have all of the language constructs that I love, but using TYPE's
>> and functions allows me to write code that reminds me a lot of my C / Pascal
>> days.
>>
>> Tony
>
> OK thats the basic (pun intended) language. Now whats the game engine
> interface
> like?? (cant pass UDT - thats gotta be messy.. unless everything is just
> global.)
>
> Getting the goodies out of the game engine, doing your magic/crunching, and
> then
> directing the engine to get something done -- how easy/clunky is that.
>
> Is there a decent event model ??
> Is there enuf flexibility in game engine (not constrained to a quite limited
> set
> of options)
>
> I forget if I check this before -- is it truly compiled, or a bytecode
> interpreter (or worse RT parsed)
>
You guys should all consider looking at REALbasic for
http://www.realsoftware.com. It is very powerful, cross-platform, allows
for what we of the Java world call "Native" functions (C++, etc.). It
COMPILES, so there is no interpreter slowdown. It also supports DirectX and
OpenGL as well as numerous other third party "add-ons". And NO, I don't
work for them.

Best regards,
Martin

Admiralty Walkers wrote:

> in article 3F35AABB.EFA590D8@oneeye.com, Eternal Vigilance at
> wotan@oneeye.com wrote on 08/09/2003 21:14:
>
> >
> >
> > Tony Di Croce wrote:
> >
> >>> Could you be more specific about the slowdowns? The language itself seems
> >> a
> >>> drawback as BASIC is any C++ programmer's nightmare. I would rather have
> >>> seem them using a sort of C/Basic variant, with a greater slope towards C
> >>> (but not C++).
> >>
> >> First I will list some positives. Their are functions in DarkBasic.
> >>
> >> function inc( a as integer )
> >> a = a + 1
> >> endfunction a
> >>
> >> Their are also user defined types:
> >>
> >> type foo_t
> >> a as integer
> >> b as integer
> >> endtype
> >>
> >> Their is built in support for dynamic lists, stacks and queues.
> >>
> >> DB also has all of the looping constructs that C does. It also has all of
> >> the comparison statements (if, if else).
> >>
> >> I love C++ as much as the next guy, but UDT's and functions are all I really
> >> need to write good structured code.
> >>
> >> Now for some of the bad stuff:
> >>
> >> - You cannot pass UDT's to functions directly (I believe that the
> >> upcoming patch adds this).
> >> - You cannot pass dynamic arrays to functions
> >> - Little things sometimes slow you down (for instance it took me a day
> >> to realize that sin() expected degrees not radians())
> >>
> >> In all, their is far more good stuff than bad stuff. I really like the
> >> language a lot. You will write a lot less code to complete a game. My games
> >> don't exactly push the hardware to it's limits, so DB is perfect for me. I
> >> may not have all of the language constructs that I love, but using TYPE's
> >> and functions allows me to write code that reminds me a lot of my C / Pascal
> >> days.
> >>
> >> Tony
> >
> > OK thats the basic (pun intended) language. Now whats the game engine
> > interface
> > like?? (cant pass UDT - thats gotta be messy.. unless everything is just
> > global.)
> >
> > Getting the goodies out of the game engine, doing your magic/crunching, and
> > then
> > directing the engine to get something done -- how easy/clunky is that.
> >
> > Is there a decent event model ??
> > Is there enuf flexibility in game engine (not constrained to a quite limited
> > set
> > of options)
> >
> > I forget if I check this before -- is it truly compiled, or a bytecode
> > interpreter (or worse RT parsed)
> >
> You guys should all consider looking at REALbasic for
> http://www.realsoftware.com. It is very powerful, cross-platform, allows
> for what we of the Java world call "Native" functions (C++, etc.). It
> COMPILES, so there is no interpreter slowdown. It also supports DirectX and
> OpenGL as well as numerous other third party "add-ons". And NO, I don't
> work for them.
>
> Best regards,
> Martin

Except that were looking at Game developing systems -- with built in game engine
features that cut down the coding needed (so you can concentrate on the game
mechanics and the behavior code etc...)

Greetings:

Forgive me if this is orthoganal; I just wanted to give my two cents. The
first bit sets some context, the second bit really makes the point.

Back in 2000 I helped a steel firm migrate from 30 years of COBOL programs
running on a single unisys V series machine, to modern C and VB programs
running on a network of PCs. One of the biggest obsticals was one of
these so-called `Turn-Key Solutions'. How are doughnuts baked? In
batches. How are steel springs cast? In heats. Some genius decided to
buy some `Turn-Key Solution' used by bakeries for use at the mill.
`Turn-Key Solution' should *ALWAYS* be pronounced `Shoe-Horn Solution'
because it forces you to change your business model to the program's. You
must make your business conform to how the program works, rather than use
a program to run your business (at least as far as you understand your
business).
While the migration was not w/o incident, it was successful chiefly
because that damn baking software was rejected whole-heartedly in favour
of a program and set of procedures that supported the business model and
practices from the production floor all the way to the CFO's desk.

Now on to what this has to do with `Game Creators'.

I have seen some of the `game creators'. I am not impressed with the CASE
tools publically available to both gamers and business programmers,
especially so with RPG Maker 2003. When I first saw RPG Maker (a friend
spends a lot of time in front of that) I was impressed with what he was
doing, but soon I became more impressed with it's short-comings,
near-sightedness, and corporate-cookie-cutterness reminiscient of the
originality found in a fast-food chain. You can make a game with
something like RPG Maker (which we will use as our rule-stick), but only
the way RPG Maker likes games made.

I assert it would be far easier for people interested in making games to
actually learn programming and make their own engines, rather than learn
the quirks, idiosyncrosies, and limitations of existing products. RPG
Maker is great for a quick prototype, but it seems about as crippled as
the old SSI engine used for all the TSR games which was released back in
the early nineties (Unlimited Adventures, at least I think that's what it
was called. I'll check when I go home since I own it, along with almost
every other SSI game on original media...). Sure, RPG Maker let's you
have a number of effects/magics/thingies, but only those which the authors
think you need/want/use. This means it is impossible to make an original
game with such tools. The only results one could attain is a game that
looks like any other game made by that tool (a lot like the `web page
templates' a lot of e-commerce hosts offer. It's quick and easy to make a
web store that looks like every other web store they host....). Frankly I
do not see much value in learning `how to use Brand X CASE tool?'
considering it can take almost as much time to learn how to use a CASE
tool as it takes to make your own original prototype, which will *ALWAYS*
be more extensible than someone else's engine.

In short: sit down and make a pencil & paper game (RPG or otherwise), then
make the computer model with Your Favourite Language (self-reliance),
rather than learn how to use someone else's tool (foreign dependence).

HTH
</RANT>