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 disadvantages.

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 DirectX.

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

' 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 this.

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

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 <phi...@blastbay.com> 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 __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
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-ow...@audyssey.org.

Reply via email to