The one thing I really have liked about angel script is how similar it is to
other languages. I switched over to BGT from vb6.  It was a bit of a hassle
at first, but after about 4 months with it I became very fluent. Around that
time, I had to start doing some PHP work for my job, and I'm finding that
the syntax between angelscript and php has some similarities which has made
jumping between the languages much simpler.  If I had the option to keep
going in I wouldn't have challenged myself and learned something knew
which would not only help my games, but my work as well.

-----Original Message-----
From: [] On
Behalf Of Thomas Ward
Sent: Thursday, January 27, 2011 5:06 AM
To: Philip Bennefall; Gamers Discussion list
Subject: Re: [Audyssey] Game Engines was Heli

Hi Philip,

Yeah, I do see what you mean. For one thing we have taken two completely
different approaches to the same thing. Both have advantages and

For example, as I understand BGT what you have done is basically written a
piece of middleware that wraps DirectSound, DirectInput, Sapi, ENet, etc and
then registered the functionality of BGT with Angelscript allowing someone
to script a game in Angelscript and depend on your middleware to handle all
the low level stuff like input, speech output, sound, networking, and
various other things you have built into BGT. Am I right?

Well, my approach is quite a bit different. As I mentioned before originally
when I wrote Genesis 3D, AKA G3D.dll, It was written in C# .NET and wrapped
Microsoft's Managed DirectX, Sapi, as well as provided a number of custom
.NET classes that provided an API for quick and easy game creation using the
various .NET languages like C#,
C++, and Visual Basic. However, once I found out that Managed DirectX
was buggy and Microsoft's XNA Framework .for .NET is largely inaccessible I
decided to port the engine to C++ and use the various APIs directly rather
than writing a piece of middleware based on other middle ware like Managed

The current Genesis engine is written in C++, is fully object oriented, and
uses a managed C++ design model. The reason I wrote it as managed code is
because in theory I can take the G3D.dll library include it in A C# .NET or
VB .NET project import the library and have input, speech, networking,
advanced 3d calculations, etc ready to go.
All I need to do is initialize the class or classes I wish to use. For
example, although Streemway is not managed C++, I have written a managed
wrapper for it that I can use in a Visual Basic .NET applike this.

' Import the G3D namespace
import G3D

' Declare an audio class object
Private audio As Audio

' Initialize audio
' and play a sound
Static Sub Main()

  if audio.InitializeAudio(Window.IsWindowHandle()) == false then
    ' Show error message
End If

  ' Load and play sound
  audio.SoundOpen (0, "fire.wav")
  audio.SoundPlay (0, false)

End Sub

Okay, this is a bit of an over simplification since I left out all of the
form initialization code etc but you get the point of how easy it would be
for a Visual Basic programmer to include my engine into a standard .NET
application and begin using it right away to build games. Where you use
something like Angelscript for programming my design is more flexable. I can
obviously use C++, since that is the language the engine is written in, but
I can also plug it into any .NET language like C# .NET or Visual Basic .NET
and use that to build games. This would essentually give the end user a
choice of language or languages to use when building games. As a long time
.NET developer I happen to know that C# is hundreds of times easier than C++
and is just as good, maybe better, than using something like Angelscript. If
someone like Jim Kitchen decided to upgrade to VB .NET rather than using
Visual Basic 6 he could in theory use my engine to access DirectSound,
DirectInput, Sapi, all via my engine in .NET. So the choice of programming
language is certainly one advantage I can see as a plus here.

Another advantage is base classes. I have been adding core data classes for
a number of common game objects you might encounter. Since the base classes
are there you can use inheritence to extend or expand the functionality of
the classes without having to rewrite anything.
For example, take the player class. It has all of the normal things you
would expect to find like health, location, direction, point of view, etc.
However, by itself it couldn't be used to create a special character like a
wizard. No problem create your own class and inherit the player class like

import G3D

Class Wizard Inherits Player
  ' Add wizard specific code here
End Class

This gives a game developer all the primary classes they need to work with,
but gives them the flexability to extend the classes and functionality as
needed. Not to mention the fact that doing it this way using C++, C#, or VB
.NET gives you all the advanced functionality of object oriented design like
pollimorphism, inheritance, etc. When I was trying out BGT one of the things
I didn't like as it lacked a number of advanced language features I'm
personally use to having when programming.

Finally, there is he issue of cross-platform support. At this current time I
have elected not to port the Genesis engine to Mac OS or to Linux just
because of the effort in volved plus I've discovered to do it right I need
to use OS specific libraries and toolkits. All the same if I were to create
this port it would be a definite advantage over BGT as the same engine could
be used on more than one platform.

In terms of disadvantages Genesis 3D was designed primarily to target game
developers with some programming skills in C++, C#, or VB .NET.
This enables someone to continue using his/her favorite programming language
while accessing my engine for game development. That's fine if someone
already knows a programming language, but if they don't I can't just point
them to Angelscript, Lua, etc. It wasn't designed to be a stand alone
product, and must be included into a Visual Studio or Codeblocks project.
It is this aspect of the engine I think may hurt sales and turn people off.
BGT was designed to be an all in one product including its own scripting
language where G3D was designed to be a piece of middlewhere between the
programming language and various APIs on the target machine. In a way it is
kind of like the .NET Framework in that it has several classes that can do
anything from creating a basic window to handling input, audio, speech, etc
all through one common library. Make sense?


On 1/25/11, Philip Bennefall <> wrote:
> Hi Thomas,
> I certainly don't think that your engine is not marketable just 
> because BGT is around. I'm sure you do things totally differently as 
> compared to myself and BGT, and so your engine might appeal to some 
> where BGT has not done so and the other way around. I would definitely 
> say that you should give it a try, and ignore BGT's presence in that 
> sense. Besides, if we do end up competing, that's a good thing in 
> itself. Competition provides insentive for both of us to make our 
> engines the very best they can be, and then let the end user decide.
> Kind regards,
> Philip Bennefall

Gamers mailing list __ If you want to leave the list,
send E-mail to
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to

Gamers mailing list __
If you want to leave the list, send E-mail to
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to

Reply via email to