Q. |
Are you including support for any open source or
freely available game engines? |
A. |
Yes. Support for Fly3D
and CrystalSpace will
be included. V1.02 of the Fly3d engine will be released as open
source sometime after V2.0 is released (sometime around SigGraph
2001). CrystalSpace is available under the LGPL and is a very
mature engine providing too many features to list here. Check out
the CS web side for further information. |
|
|
|
|
|
Q. |
How do I become a member of the Qoole-AID Team? |
A. |
First you must meet the basic qualifications. You MUST know C++ and
fairly well. The entire design is Object Oriented and with the
exception of some Python support code, most of the editor will be
written in C++. Many of the features rely upon
templates and various aspects of C++ that many people consider to
be "advanced programming topics." From there it depends
on what you want to work on. If you want to work on one of the rendering engines (OpenGL, MGL, DirectX) you should
probably know the area you are working on. If it's the main GUI,
it is a MUST that you are proficient in developing in user
interfaces. The application is being prototyped in MFC and ported to
wxWindows along the way.. The
best way to become a member is to submit a request and include
some sample source code. |
|
|
|
|
|
Q. |
I am working on a similar project, will you help
me implement feature 'x'? |
A. |
In short, no. The Qoole-AID team is extremely busy
working on Qoole-AID. If there is a piece of code which will be
useful to you feel free to use it as long as you adhere to the
licensing. We try to document everything we do, so if there is a
specific thing you are looking for that we have implemented, please
see if the documentation for it is available. Since I'm fairly anal
retentive about it and I'm the one who compiles the documenation
together, chances are you will find all reference material included
or at the very least, links to where to find that information. This
may sound a little harsh, but unfortunately all of our development
time is devoted to working on Qoole-AID and playing Unreal
Tournament. |
|
|
|
|
|
Q. |
Why are you prototyping the application in MFC if
it's going to be cross-platform? Won't that create a lot of
unnecessary work in porting? |
A. |
Actually it won't. The cross-platform framework that
we have selected can be used at the same time as MFC when developing
applications. The portions of the GUI that will be used over the
next few weeks are simple placeholders anyway for validating various
functionality in the editor. This means that once we start on the
GUI, we can continue to prototype it in MFC or move to wxWindows for
all GUI development. If we continue to use MFC, all GUI
functionality will be ported over before the first major alpha
release. Given the constructs of wxWindows and it's compatibility
with MFC, the porting cycle will be very short. |
|
|
|
|
|
Q. |
Don't you think it's a little ambitious for only
a few developers to implement a world editor, cut-scene AND a model
editor when they only work on it in their spare time? That amount of
work doesn't make me want to join the Qoole-AID team. |
A. |
Hmmmm, I'm not sure if I even want to answer this
one :) The bottom line is that at least 90% of the functionality
needed to implement a model and cut-scene editor can be found
in a world editor. There are of course subtle differences, and there
is additional functionality required for things such as timelining
the cutscene or skeletal animations but given that most of the code
is done, why not include the features? All context object types,
object rendering, editing, and interfaces are done through plug-ins.
This will allow all of this to be done in a shorter time frame that
it would for other projects to do. |
|
|
|
|
|
Q. |
Isn't
QuArK extremely
configurable? Why don't you just focus your efforts into extending
that for game developers? |
A. |
Quark was developed for one thing - to edit Quake
levels (QuArK = Quake Army Knive) and it does a VERY good job of it.
It has even been extended to support other games. Unfortunately
QuArK is written Delphi/Kylix which is a version of PASCAL. Most
game developers I've met don't use Delphi. This inhibits the ability
to extend the editor in many ways. Yes, Quark uses Python just was
Qoole-AID will use Python, but there is only so much you can do with
Python before you hit a bottleneck. Plus Quark isn't available on
the Mac, and frankly there just isn't enough software on the Mac -
so we're doing out part. |
|
|
|
|
|
|
|
|
|
|
|