Hi Philip,
Exactly my point. In a sense the AGM is too simplistic a game
development tool because it is extremely limited in what you can
actually create with it. You are not able to modify the enemy AI or
use any kind of if type conditional statements to change the behavior
of any game elements. This is a huge drawback as you know conditional
statements are absolutely essentual for creating games where there are
several random variables involved.The point and click game development
tools don't give you that kind of control over the games creation and
behavior. Which was one of the reasons it failed to impress game
developers such as me.
I understand some users desire to have a simple point and click all in
one game development tool, but such a thing isn't realistically
feasable if we want the developer to be able to create new and unique
types of games. I think what you are doing with BGT is really the best
compromise possible. You have a scripting language with special
modules/add ons that helps simplifies the process of game development
while not giving up any features in the process. I think in the end
I'll probably end up doing the same thing with Genesis as well. There
really isn't any better way to do it.
I don't know about you, but ever since I mentioned I was working on
the Genesis Engine I often get asked if he/she will have to know any
programming to use it. Like you if I go with a scripting language for
scripting the engine the end user wouldn't necessarily have to know
how to program to use it per say, but they would have to learn how to
use the scripting language which some might find a little daunting.
That may put people off from buying it as they wouldn't be able to
pick it up, point and click a couple of times, and have a new game. It
still may require some scripting by hand to create a game which is a
big turn off for the common computer user, but is necessary to have a
fully featured game engine.


On 3/14/10, Philip Bennefall <phi...@blastbay.com> wrote:
> Hi Thomas,
> A good summary, in my opinion. The problem I have with a, shall we call it
> clicky-pointy tool is that it's ridiculously limited. Somebody asked on the
> audio game maker forum how easy it would be to make a sports game (I think
> it was basketball or socker or something). The response was, the engine
> doesn't support making a ball at this stage... I'll say no more.
> The way I'm doing it in Bgt, as I mentioned previously, is to build a
> powerful base that is capable of making pretty much anything. I still have
> to add a few things such as file IO, some processor demanding AI that can't
> be done so well through the script, parsing directory trees, encryption and
> decryption of files and strings etc, 3d vectors and advanced math,
> eventually networking and so forth. Though over-all, the core of the engine
> will stay unchanged and the only thing that will be added is extra modules.
> These, the script writer can simply include and use as though they were
> functions and classes that they had written themselves; #include, in other
> words. This will enable me to go as high level as I could possibly wish,
> even to the point of providing almost finished games where all you need to
> do is make a few tweaks to variables and supply sounds. This, however, would
> not be a good foundation for a core which is what the audio game maker tried
> to do. In short, I'm trying to provide the best of both worlds; extreme
> simplisity if you want it, and complete control once you've mastered the
> language operation enough.
> 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