Hi Thomas,
This sounds pretty interesting. At RS Games, we are in the process of
beta testing a client that will allow users to play Monopoly (as well
as Uno, and several other games) through a protocol we created,
written in Python, using  wxPython, PyGame, and Pyttsx (which
automatically detects and uses Sapi, Speech-Dispatcher, or the
NSSpeechSynthesizer.). These tools have really simplified the work
necessary to cross-platform game development. This is a fantastic
option for games we host on our server, as they will mainly be
multiplayer card and board games. But for something like your engine,
Python might not be fast enough, and it would require a complete

I've had some experience with the Mono framework, and it has been
mainly positive. I'm not sure how hard it is to get speech output on
Linux/Mac working, as I haven't spent too much time on it, but it is a
must have feature. I should also mention that I think Mono is the best
solution here.

If you take the C++ route, most mainstream game engines allow Lua
scripting. I like Lua, but I've been looking at the AngelScript (which
does run on Linux and Mac) documentation, and it might be easier to
integrate into your engine.

Network support is certainly a nice feature to have, but there are a
few things I have to say about it. I don't find multiplayer games
appealing where you have to type in someone's IP address. While it
wouldn't be that hard to create a simple server to create a lobby (to
just transfer IP addresses. The game will still be P2P connection.),
this project is aimed at new and experienced programmers. Another
thing is that in order to make a fast-paced game, you need to use the
UDP protocol. UDP doesn't do anything to ensure datagrams are sent
reliably. Therefore, UDP is considered unreliable, as datagrams may go
missing, be duplicated, or be out of order. This can pose a serious
issue if the programmer isn't careful, as a die datagram may arrive at
the destination before a final shot datagram arrives. However, UDP is
used in many online games, because it is much faster than the other
option, TCP. TCP is slower because it is reliable and the packets
arrive in order (if packets arrive in the wrong order, TCP will buffer
the data that it out of order until it can be sent reliably again.) We
are in luck, because to my knowledge, SDL_Net supports both TCP and

Other things to consider is what license it would be under (I
recommended the GPL), and what kind of versioning software will be
used (I recommend subversion).

Another thing I really like about this project is that it is open
source. Assuming you go the .NET route, I'm sure there are quite a few
developers who would be interested in improving and helping to get the
engine run well. C# is a really great language, and I am definitely
excited about this project.


On Thu, Jul 15, 2010 at 6:54 PM, Thomas Ward <thomasward1...@gmail.com> wrote:
> Hi everyone,
> Since we have been doing a lot of talking about game engines and
> toolkits like BGT I thought I’d bring up one of the current projects I
> have in the wings. I’d like to get some end user feedback and
> suggestions on it as I plan for this to be more or less a community
> driven project not only to help aspiring game developers to get
> started with creating games, but also to begin cross-platform
> development of games for currently unsupported operating systems like
> Mac OS and Linux as well as the latest Windows releases too.
> The project is named Open G3D. That basically stands for Open Genesis
> 3D. A purely open source and free version of the Genesis engine that
> will be cross-platform as well as uses open source APIs such as SDL
> for game development. That’s the basic overview.
> However, before I begin releasing beta versions of the engine it would
> be helpful to know what features you potential game developers would
> like to see in the engine. For example, I have two different versions
> of the Genesis Engine.
> The first is the newer C++ version of the engine that is currently
> written in pure C++ which could be ported to Mac OS and Linux via SDL,
> OpenAL, and other open source libraries, but would be more difficult
> to program/use since it is written in pure C++. The Disadvantage here
> is that you would have to manually compile it on every single
> operating system and platform you intend to support. So if you wanted
> to support Mac OS  and didn’t have a Mac, for example, you couldn’t
> support the Mac platform until you purchase a Mac and use the Mac
> C/C++ development tools. This is, in my opinion, the principle problem
> with using C or C++ for serious cross-platform development.
> The other issue is at this time I haven’t added a user friendly
> scripting engine to the game, such as BGT has, so at the current
> moment if you don’t know C or C++ you can’t easily use the engine. I
> could easily fix this by creating a self-contained core like BGT and
> then use an open source script language like Lua to give the open
> source game developer something easier to tackle as well as speed up
> development time However, on the good side writing the Open G3D engine
> in C/C++ you have full access to native libraries such as
> Speech-Dispatcher on Linux, Sapi 5 for Windows, and the Mac OS Speech
> API. Not to mention access to the default graphical toolkits like GTK,
> Win32, or Cocoa. All are things that would probably be a good idea to
> have, but not exactly cross-platform friendly.  SDL has its own GUI to
> use instead so supporting individual graphical interfaces isn’t
> necessary most of the time.
> With C/C++ you can get better game performance, but usually at the
> cost of doing your own memory management or clean up. As pointers etc
> are an advanced programming technique and this is intended to be a
> community project I see this cutting both ways. Good in a way but bad
> for newbies in a big way.
> The other version of the engine is the .Net version of the game engine
> which MOTA used clear up to beta 10. It was written in C# .Net and is
> more or less stable except for Managed DirectX which could be removed
> and replaced with an open source API like SDL easy enough. It is
> already fairly along in development and with perhaps a month or so of
> work could be ported over to the open source Mono Framework and SDL
> which is cross-platform. This is in my opinion probably the best
> choice and solution for something like this.
> For one thing since Mono is open source and is supported on Mac,
> Linux, and Windows you don’t need to recompile your application to run
> the game on Mac, Linux, or Windows. You create it in the Monodevelop
> IDE, compile it for either 32bit or 64bit mono, and that’s it. Someone
> downloads and installs your game and runs it provided they are using
> the same version of Mono for their platform you are. This makes the
> task of creating open source games that you build once run anywhere is
> why runtime environments like this are important for software
> developers. It simplifies the task a lot.
> The other reason I think this is a good idea is the .Net languages
> like C# are very newbie friendly and are far simpler to learn and use
> than C++. You don’t really need a scripting language when using C# as
> the language is pretty simple in of itself. Plus having something like
> the Mono Framework it wraps the core libraries of Windows, Mac, and
> Linux giving the developer a single object oriented API to work with
> that is the same on all three platforms.
> For example, the Mono dll, System.Windows.Forms.dll, is used to create
> windows, buttons, list boxes, and so on. The nice thing about this
> library is that it uses the operating systems default GUI when
> actually rendering a window. On Windows XP, Vista, or 7 it would draw
> a window using the Windows API. On Linux it would render that same
> window using GTK. That makes the app screen reader friendly as well as
> uses the default color scheme etc of the operating system. On Mac I’ve
> heard they had some access problems with Mono, but as for the other
> two platforms it is a simple way to render graphical games etc with
> ease without having to support three different graphics toolkits
> directly.
> The primary disadvantage of things like C# .Net and Java is you need
> to download and install a large runtime library. For those Windows
> users running Windows Vista and Windows 7 don’t have to worry about
> this as they come with .Net Framework 3.0 and .Net Framework 4.0 so
> there aren’t any dependencies to install except for SDL .Net which is
> like 5 MB or something like that. For Linux users it isn’t hard to
> install as apt-get and yum can be used to download and install
> dependencies, but is still a pretty big download/install. I’m not sure
> about Mac, but I know from experience with .Net products before a lot
> of problems come up just from people not running the latest and
> greatest .ANet stuff. Although, as Mono is designed independently from
> Microsoft it might be a bit less of a headache as they aren’t
> releasing new versions constantly.
> The next topic of interest is an audio library. There are really two
> to choose from here. SDL’s SDL Mixer and the OpenAL API. Both have
> advantages and disadvantages from a programming aspect.
> SDL Mixer is a simple mixer with basic stereo panning, sound
> positioning,  and some built in support for ogg, wav, and some other
> file types. It is extremely easy to use, but is also a bit limited. It
> really doesn’t have much in the way of virtual 3d audio support, but
> will let you position the direction of the audio by passing it an
> angle of the sound and setting the volume. While primitive there isn’t
> any reason a game developer couldn’t create a wrapper function that
> uses some virtual 3d calculations to come up witht the correct angle
> and volume and pass that off to SDL more or less emulating a virtual
> 3d audio environment. Still it is generally not really made for really
> high-end games with advanced audio environments.
> That leaves us with the alternative. There is OpenAL which is
> supported on Mac, Linux, and Windows. Unlike SDL it was designed for
> high-end games using virtual 3d, some DSP effects, and so on. The
> problem is that it is a bit harder to use and I’d definitely have to
> create some kind of wrapper library to simplify it and add support for
> ogg, mp3, or any other compressed file types if we wish to support
> them. On the plus side though we can have 5.1 and 7.1 3d audio almost
> equal to XAudio2 or DirectSound on Mac, Linux, and Windows with this
> engine. Although, at the cost of a more difficult and advanced library
> to use.
> Another issue I would like to talk about is speech output.
> Triditionally, I use prerecorded speech files to sspeak messages.
> That’s fine as far as it goes, but I also wonder if it might not be a
> good idea to try and support some sort of tts system like Sapi as
> well. Sapi, Speech-Dispatcher, and so on would definitely come in
> handy for RPG games and so on where there are hundreds perhaps
> thousands of messages that need to be spoken. In other words in games
> where prerecorded messages would be in a very real sense unrealistic
> do to size or the number of messages that need to be strung together
> to produce speech output. .So what do you think about TTS support?
> Finally, I’ve noticed a greater demand for networked games and more
> player verses player type play. The obvious choice for this would be
> something like SDL’s Network API which covers the cross-platform
> angle, but how many of you are really into pvp type play. I’m not so
> that’s one reason I haven’t added network play to Genesis 3D, but
> apparently some are and having this feature seams almost necessary for
> a community driven engine. So any thoughts, suggestions, etc on this
> topic is welcome.

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