civil-devel Mailing List for Civil

Hi Jan,

I've just completed the front of the website and the screenshots page. All
that's left to do before it's put up is the 'about' documentation and the
'Specification' pages, as discussed.

If there's no comment on the bible page I posted earlier, I'll include this
as is. Otherwise, it's just a quick clean up of the the game-mechanics docs
required before the site goes live.

The 'List of graphics' is underway, although I doubt I'll get this finished
tonight as I'm too tired...

Don't think I've forgotten anything... Speak to you tomorrow.

Cheers

G


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0

iQA/AwUBOV4dgWtL7e1IGHY8EQIZpQCgzcgfbemfYvuXxMGsIrE4GVkLOIYAoPpn
ygxEeOudynAwxqeYKjo7PhlF
=S/8P
-----END PGP SIGNATURE-----

On Tue, 31 Oct 2000, Gareth Noyce wrote:

>[SNIP]
>
>> level of thoroughness. But I will start doing better code... 
>> I promise.
>
>It may be worth a tidy up in the near future, but for now I think it's fine.
>I certainly had little difficulty understanding what was going on, so I
>don't expect any other Python savvy coder complaining...

:-) Ok, maybe not. But there will be 25kloc of more code, and then the
comments and organization will start to matter. But I'll try to keep it
tidy.


>What I intend from a hiearchy point of view for the site is:
>
>home -
>	Screenshots   -- Obvious
>	About         -- Your docs on gameplay...
>	Specification -- Bible, 'Things to do', code reqs etc...
>	Download      -- Empty for now
>	Contact	  -- Sourceforge list details etc.

Looks like a plan. Keep the thing simple. No extra fluff, we're a lot of
suckers still looking at the pages over slooow modems. God I hate those
things!

>> game play. They can be updated and given some more flesh 
>> (screenshots etc)
>> and be the main player manual(s).
>
>A good idea. If you produce them as Docbook (for distribution) I can convert
>to HTML easily enough...

Yep, Docbook is my preferred medium for documentation. Even wrote my
Master's using it. A bit ugly, but it let me work with Emacs.

>I figure the front page is a brief explanation of the game, including a
>screenshot (we need a shot of the actual game. One showing the status bar,
>and the 'play area' with a mix of terrains. Could you produce this please?)

I'll create more screenshots the next few days, as I get the editor
working again. Swing sucks too. A lot of things suck now. :-) Some day
I'll reqrite it using the normal game engine. Should be quite simple, or a
matter of some manual labor.

>and information about how to join or keep watch on the project. This will be
>kept short, so that 'news' style items can be added underneath

Yep, this is a good idea.

>I think I've spent too much time playing with Civil stuff today! I haven't
>got much testing done... :-\ Better work hard this afternoon...

Likewise. My indexing code still sucks... Please don't forget to mail the
list too, you don't need to mail me directly anymore. :-) This last mail
came to me only, afaik.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Ok, 

Here's a first draft of the bible. I've kept it basic so that things can be
added as we progress. I'll convert this to HTML when the list is happy with
it.

I'll leave it to your common sense to see where I will include links in this
document.

--

Civil GFX development Guidelines
================================

Overview:

Civil is an open source game depicting fictitious battles during the
American Civil war. The game is being developed using Python and SDL, for
the maximum in cross-platform compatibility, and is licensed under the GNU
Public License. 

This document is a brief set of guidelines for the successful contribution
of graphics to the Civil project. 

Bugs reports and requests for change should be forwarded to the Civil
development mailing list. 


Graphics overview:

The graphics for Civil fall into the following categories:

* Terrains -- The basic building blocks for the game world. Terrains are the
surfaces (grass, mud, sand, water, hills etc.) that are present in the game
world. All terrains in Civil are created using Hexes (See the hex definition
further in this document)

* Sprites -- Houses, bridges (etc.) and other in game 'fixed' elements that
are not required to be hex based. 

* Periphery -- Dialog parts, splash screens and other support GFX that are
required for the front end, or user feedback parts of the game.

The reader is referred to the Civil 'List of required Graphics' -- to see
the current list of requirements for any given release of Civil. If you
would like to contribute graphics, please choose a work package from this
list, and inform the Civil-Devel mailing list so that repetition of work is
avoided.

It should be noted, that the contributor of any graphic work should do so in
the spirit of the GNU Public License under which it will ultimately be
distributed. The contribution of work that cannont be distributed under the
GPL will not be accepted. 

--
Transparency:

All graphics within Civil us #ffffff (white) as the transparent color. White
should not be used in any other circumstance without consulting the
civil-devel mailing list for the specific requirements. It's often likely
that you will be asked to use #fffffe (or similar) instead as it makes
little or no difference to the 'look' of the final piece. 

To date, this has not been an issue.


Gamma:

As graphic development is likely to happen on various platform
(Linux/Windows/Mac) and through different packages, gamma can be an issue.
To save hassle, prior to any release, all graphics will be updated through a
single point to ensure they share the same gamma characteristics. Developers
picking up work packages from the 'Required Graphics' list, should also grab
any associated graphics from the cvs-tree to ensure that they aren't
producing anything 'above' or 'below' the average gamma of the existing
graphics. 

This is not expected to be a problem, but it is included in this document as
an 'awareness' primer.


Lightsource:

For consistency, all graphics, be they periphery, or 'main game' should be
lit from the North East -- or top-right of the screen. All shadows for free
standing objects should respect this origin. 


Anti-aliasing:

Sprites, and other 'free-standing' in-game objects should not be heavily
aliased to a specific background color, as they may appear on several
different terrain types. Care should also be taken that they do not pick up
attributes from the white 'surround' used to denote transparency.

This is left to the common sense -- 'best judgement' of the artist in
question! ;)  


File Formats:

All graphics (with the exception of animated pieces) developed for Civil,
should be saved as flat .PNG, minus alpha channels and/or masks -- unless
specific requirements for the work package being developed have been agreed
by the other developers.  
 

Civil 'Hex' Requirements:

All terrains for Civil are generated from 48px X 48px hexagons. [FOOTNOTE]A
mask for these can be generated from any 't-' prefixed graphic in the cvs
repository. However, we can send you one if you're lazy! ;) [/FOOTNOTE]
Unlike some other games from the genre, we are trying to make this
underlying hex base transparent to the user -- as it is likely that future
revisions of the game will not be tied to a hex 'based' world.

As such, terrains should provide the maximum flexibility, whilst minimising
the repition of the use of individual hexes. The common minimum for a 'flat'
terrain has been in the region of 20-25 individual hexagons, so any
additional terrain should aim to provide a similar number of tesselating
graphics.


Animation:

Animation has yet to be discussed in detail for the beta release. We have
several methods which we have yet to make a decision on. Discussion of this
topic is welcomed and should be directed to the Civil-Devel mailing list.


Naming scheme:

/All/ terrain and in-game sprite graphics have an individual number suffix.
This is the last 3 digit number in the file name. (Eg: t-sand-001-025.png)
Any new graphics committed to the cvs tree must respect the numbering
convention used, and increment from the currently highest ID number.  

It is common practice to use the prefix 't-' to indicate terrains, 's-' to
indicate sprites and for each 'type' of terrain (Eg: Grass) to have it's own
number identifier. 

Figure one explains this more clearly:
                 
             Terrain 'Internal'
                 No. ID
                   |
                   |
          [t-sand-001-025.png]
           /  |         \
          /   |          \
     Terrain  Type       Global No. Identifier

		Figure 1 -- Numbering scheme

Peripheral graphics (such as those for dialogs) do not need to follow this
naming scheme. /However/ they should follow the existing prefixing as used
to date:

Button-
Dialog-
Splash-

etc. etc. 


============================================================


Ok, that's what I have so far. I'm gonna have to get back to work, but I'd
like any suggestions on the above so I can clean it this evening...


Cheers

G

--
Gareth Noyce -- Applications Engineer
         Pennant E-Services 
Tel: 023 8090 8218; Fax: 023 8033 6117
--

On Tue, 31 Oct 2000, Gareth Noyce wrote:

>> Good. We'll do everything that way from now on. Use the list 
>> I mean. You
>> keep yourself busy, I see! It can be a lot of fun if more 
>> people join the
>> list, especially as it would not be too dead.
>
>I'm actually quite looking forward to working with another GFX developer.
>Although it's a bit scary not doing everything (I don't mean that
>negatively) as I've always been the 'solo' artist. But, I figure he must be
>pretty good to offer to help, and he does sound like a bit of an expert on
>the subject matter. Maybe this saves me some research? ;) 

It is probably the same as with me and coding. It is always easy to do it
on your own, but as soon as there are more coders involved things such as
how the code looks, naming etc starts to matter. My code right now is ugly
for my normal standards, but as development is easy and moves fast I
haven't had the time to do it thoroughly. In C/C++ it's easier to do fatal
and bad bugs, so more care must be taken to create really solid and good
code that is easy to read. Python is simpler and does not demand the same
level of thoroughness. But I will start doing better code... I promise.

>As for keeping myself busy; well, I figure we have to now we're getting
>interest. The easier we make it for other people to join, the more interest
>we'll get. We need this information between ourselves, and it allows Mike to
>pick what he is most interested and capable of doing. The bible just gives a
>framework for the styling of the game that is in place through my work, so
>he should have no problems following it. Basically it's just the
>lightsource, format, scales and hex sizes. I'll probably knock this up at
>lunch and send it to you. Maybe it should be included on the homepage?

The bible is a good idea. It is a kind of design document. It's a good
idea. More docs is better. Please send it to me too, I'd be happy to read
what you have.

Personally I think we should have a "Development" section on the homepage
with documents like this that are intended for developers. I have a few
things I need to fix up a bit and they can be added too.

Then I do have some (outdated now) docs that are more about the actual
game play. They can be updated and given some more flesh (screenshots etc)
and be the main player manual(s).

>Speaking of the civil homepage. I might spend some time on it over the
>weekend. Nothing special, just add a little color, a logo and some bits. I
>seem to recall you having an early design document that listed the troop
>types and required terrains, movement penalties etc. If this is up-to-date,
>forward me a copy, and I'll include it in the site...

Oooh, please do. It looks like sh*t now. I just put somehting there so we
could have a place to put the screenshots on. You have write permissions
to the page too, as you belong to the 'civil' group on
shell1.sourceforge.net. We should maybe think about what should be on the
front page, and what should be hidden on other pages. I'd go for a simple
front page with clear links to other places. 75% of all people want to see
the screenshots as the first thing when they enter a new site. I do at
least. So a link to them must be clearly visible. Maybe even a small
screenshot on the front page.

>P.S. It's been a lot of fun us working together on our own. I can't wait to
>share the enjoyment with others...

Yep, it seems it could be a nice experience. The onus is still on me to
live up to the gfx level, so I'd better sneak in a few lines this
afternoon too... :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

> Good. You are right about the fact that we should use the provided
> facilities a little bit more. SF also provides mailing-list 
> archives, so
> that we later can see who promised to do what... :-) I'm on 
> the list as of
> 10 minutes ago.

Kewl! Let the games begin...

Hopefully Mike will be subscribed soon. Although I don't actually know what
time-zone he's in...

> >BTW, I've informed Mike of what's going on, and I've asked 
> him to subscribe
> >to the list and checkout the latest from CVS. I'll do the 
> first draft of the
> >bible, and GFX requirements tonight. Then it's up to Mike to 
> say what he'd
> >like to do...
> 
> Good. We'll do everything that way from now on. Use the list 
> I mean. You
> keep yourself busy, I see! It can be a lot of fun if more 
> people join the
> list, especially as it would not be too dead.

I'm actually quite looking forward to working with another GFX developer.
Although it's a bit scary not doing everything (I don't mean that
negatively) as I've always been the 'solo' artist. But, I figure he must be
pretty good to offer to help, and he does sound like a bit of an expert on
the subject matter. Maybe this saves me some research? ;) 

As for keeping myself busy; well, I figure we have to now we're getting
interest. The easier we make it for other people to join, the more interest
we'll get. We need this information between ourselves, and it allows Mike to
pick what he is most interested and capable of doing. The bible just gives a
framework for the styling of the game that is in place through my work, so
he should have no problems following it. Basically it's just the
lightsource, format, scales and hex sizes. I'll probably knock this up at
lunch and send it to you. Maybe it should be included on the homepage?

Speaking of the civil homepage. I might spend some time on it over the
weekend. Nothing special, just add a little color, a logo and some bits. I
seem to recall you having an early design document that listed the troop
types and required terrains, movement penalties etc. If this is up-to-date,
forward me a copy, and I'll include it in the site...

If I think of anything else I'll let the list know...

Wooo -- the excitement of OS development! :)

G

P.S. It's been a lot of fun us working together on our own. I can't wait to
share the enjoyment with others...

Hi,

Yep, I thought it would be time to start discussions on this list. All
mailing has been private so far between me an Gareth, but now it will be
all on this list.

	Chakie

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

/. First post...

--
Gareth Noyce -- Applications Engineer
         Pennant E-Services 
Tel: 023 8090 8218; Fax: 023 8033 6117
--