FAQ Search
Memberlist Usergroups
Profile
  Forum Statistics Register
 Log in to check your private messages
Log in to check your private messages
Moonpod Homepage Starscape Information Mr. Robot Information Free Game Downloads Starscape Highscore Table
June-06: Black I.C.E.
Goto page 1, 2  Next
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary View previous topic :: View next topic  
 Author
Message
Moonpod Developer Diary RSS feed -RSS Feed
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Thu May 25, 2006 5:06 pm    Post subject: June-06: Black I.C.E. Reply with quote

Ghost Attack

Not much text this month (I'm sure everyone just wants pictures anyway Smile ), as I'm working overdrive on effects. Normally these will appear in ghost hack mode, but it's easier for me to set them up and test them in a dimmed room from the main game section, so all the screengrabs reflect this - you'll have to use your imagination and picture the effects occuring in a virtual reality world a bit like the matrix. When coming from a reference point of making something similar to the real world, e.g: the smoke trail from a missile, you always have that refererence point to work to. With ghost hack, the only criteria is that it shouldn't look like the real world Smile It's often hard to know when to stop tweaking an effect and several times I've made perfectly fine effects which then were transformed into something completely different after several iterations of tweaking! Moral: save often! Things are progressing much faster than with effects creation on Starscape. Mark has made sure effects reloading works off several buttons, which speeds things up no end. I actually value that approach to programming games more than I would the solution of writing a dedicated particle systems editor. Text files aren't hard to edit, but if you don't have the ability to see your changes instantly, then it takes an age to create even the most basic of effects. Mr. Robot: Multiple particle effect powers


Mr. Robot: Unistrike Launch Particle Effect

Mr. Robot: Self Destruct Energy Particle Effect

Mr. Robot: Self Destruct Particle Effect

Mr. Robot: Power Drain Land Particle Effect

Mr. Robot: Energy Drain Particle Effect

Mr. Robot: Power Drain Particle Effect

Mr. Robot: Firewall Particle Effect

Mr. Robot: Multi Strike Particle Effect

Mr. Robot: Misc Particle Effects

Mr. Robot: Misc Particle Effects 2



Last edited by Fost on Wed May 31, 2006 8:54 pm; edited 5 times in total
Back to top
View user's profile Visit poster's website
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Fri May 26, 2006 8:50 am    Post subject: Reply with quote

XML Storage Decisions
We already use XML for some file types in Mr. Robot, although it was more of an experiment in XML integration than something that was implemented in a sensible way. Whilst prototyping aspects of future games I've started to use it more and think about the best way to approach XML use in games.

I've not seen much discussion about what's considered best practice with regards to how xml is used to store data. There's 3 possibilities. E.g. storing data about a 3000 radius red sphere.

ALL CDATA:
Code:
<sphere>
   <radius>3000</radius>
   <colour>red</colour>
</sphere>


Multiple inline attributes in an empty element:
Code:
<sphere radius='3000' colour='red' />


Multiple empty elements with a single inline attribute inside a containing block:
Code:
<sphere>
   <radius value='3000'/>
   <colour value='red'/>
</sphere>


Whilst the use of multiple inline attributes in an empty element is the most tempting implementation, especially if you've come from using block files, it can get very messy if you have a lot and end up on multiple new lines. Once you start using a deditated XML editor rather than a text editor it starts to make a little more sense. Some commercial editors can even fold up container blocks making it easy to navigate and visually isolate data chunks (in fact, if you look at any xml file in the firefox web browser it will do this). So I've decided the last option fits most types of generic data. For single attribute empty elements I also try to stick to using the attribute name 'value' - it just makes things easier to remember. I'll still probably use several inline attributes for anything that won't break a line such as a particle system colour key like: <key time='0.5' color='255,255,0,0' /> .

Whether this is good practice is anybody's guess, it just seems to be the best compromise between compactness, readability, and parsability by dedicated XML editors, but then XML wasn't designed with games in mind...


XML Document Type Definitions (DTDs) for Games
Using xml files for just about every type of game development file is currently vogue amongst developers. The main reason it seems developers have chosen this method is because it's then easy to use a lightweight, off the shelf file IO system like tinyxml, so you don't have to write your own text file parsing system. Sometimes though, I get the impression that people use xml files just because it's trendy Smile. On the face of it, they are much more unweildy than something like a blockfile.

XML:
Code:
<colorkeys>
   <!-- this is a comment -->
   <key time="0" color="255,255,255,0"/>
   <key time="1" color="255,255,255,100"/>
</colorkeys>


BLOCKFILE:
Code:

colorKeys
   {
      //This is a comment
      key0   255,255,255,0
      key1   255,255,255,100
   }


There's a lot of duplicate text for closing tags, and the HTML style commenting system is a bit unweildy. However, as well as versatile off the shelf file IO code, there is one other major advantage to using xml files that I don't often hear game developers talking about - and that's free file validation by using document type definitions. Document type definitions (DTDs) define what elements and values are allowable in a specific xml file type. This means that you don't have to write your own validation code to check for errors; you can use an off the shelf xml file parser that supports DTD validation (whilst tinyxml doesn't support this so it can stay small in size, there are many other xml parsers that do, such as xerces xml. Better still - you just use the built in validation systems of a dedicated xml editor (like the excellent and freeware xmlpad) to validate the file as it is saved out. Virtually all xml editors will also do code completion using the DTD, so it's easy to remember what tokens go where because the editor shows you what options are available at the current position in the file:

XMLPad Code Completion
DTD based code completion in XMLPad.

Fost says that if he was still working in a big team as an art lead, he'd be pretty excited about this. Common errors that always crop up when text files are edited by non-programmers can be caught in the editing application before the game is even run. Normally this necessitates programmers adding lots of code to check the files on load and pop up suitably helpful and explanatory error messages. Automatic pre-validation of the files results in a massive time saving on both sides.

Writing a DTD is pretty easy too and it can be stored in a shared location; even on a webserver, so when the DTD updates anybody attempting to parse documents automatically uses the latest version.

Here's an example xml file representing some solar system data:

Solar System XML:
Code:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE solsys SYSTEM "solsys.dtd" >
<!-- Solar System data -->
<solsys>
   <config>
      <orbitScale value='25' />
      <startTime value='2451545' /><!-- 2442367 = Nov 15 1974 :) -->
   </config>
   <bodies>
      <body>
         <name value='Sol' />
         <radius value='695000' />
         <surface>
            <material value='Sun' />
            <diffusemap value='sun.tga' />
         </surface>
         <orbit value='static' />
      </body>
      <body>
         <name value='Mercury' />
         <radius value='2440' />
         <surface>
            <material value='Planetoid' />
            <diffusemap value='mercury.tga' />
         </surface>
         <orbit value='Mercury-VSOP87' />
      </body>
      <body>
         <name value='Venus' />
         <radius value='6051.8' />
         <surface>
            <material value='Planetoid' />
            <diffusemap value='venus.tga' />
         </surface>
         <orbit value='Venus-VSOP87' />
      </body>
      <body>
         <name value='Earth' />
         <radius value='6378.14' />
         <surface>
            <material value='Planetoid' />
            <diffusemap value='Earth.tga' />
         </surface>
         <orbit value='elliptical' />
         <ellipticalorbit>
            <period value='1' />
            <semimajoraxis value='1' />
            <eccentricity value='0.0167' />
            <inclination value='0.0001' />
            <ascendingnode value='348.739' />
            <longofpericenter value='102.947' />
            <meanlongitude value='100.464' />
         </ellipticalorbit>
      </body>
   </bodies>
</solsys>


The solar system definition contains
line1: xml header
line2: DTD definition - this will be pulled out by an xml editor and used for validation.

A <solys> top level container element which wraps all the information.
A <config> element with setup information for the application (I'd probably put this in its own xml file with it's own DTD though).
A <bodies> element, that contains multiple <body> containers.
In addition, each instance of <body> contains surface sub containers, and optionally and <ellipticalorbit> element.

My point in making it this detailed is to show how different structures can be defined in the DTD:

Solar System DTD:
Code:
<!ELEMENT solsys ( config, bodies )>
<!-- comment -->
<!ELEMENT config ( orbitScale, startTime )>
          <!ELEMENT orbitScale EMPTY>
                    <!ATTLIST orbitScale value CDATA #REQUIRED>
          <!ELEMENT startTime EMPTY>
                    <!ATTLIST startTime value CDATA #REQUIRED>
<!ELEMENT bodies ( body+ )>
<!ELEMENT body ( name, radius, surface, orbit, ellipticalorbit?)>
      <!ELEMENT name EMPTY>
                <!ATTLIST name value CDATA #REQUIRED>
      <!ELEMENT radius EMPTY>
                <!ATTLIST radius value CDATA #REQUIRED>
      <!ELEMENT surface (material, diffusemap)>
                <!ELEMENT material EMPTY>
                       <!ATTLIST material value CDATA #REQUIRED>
                <!ELEMENT diffusemap EMPTY>
                       <!ATTLIST diffusemap value CDATA #REQUIRED>
      <!ELEMENT orbit EMPTY>
                <!ATTLIST orbit value (static|Mercury-VSOP87|Venus-VSOP87|elliptical) #REQUIRED>
      <!ELEMENT ellipticalorbit (period,semimajoraxis,eccentricity,inclination,ascendingnode,longofpericenter,meanlongitude)>
                <!ELEMENT period EMPTY>
                          <!ATTLIST period value CDATA #REQUIRED>
                <!ELEMENT semimajoraxis EMPTY>
                          <!ATTLIST semimajoraxis value CDATA #REQUIRED>
                <!ELEMENT eccentricity EMPTY>
                          <!ATTLIST eccentricity value CDATA #REQUIRED>
                <!ELEMENT inclination EMPTY>
                          <!ATTLIST inclination value CDATA #REQUIRED>
                <!ELEMENT ascendingnode EMPTY>
                          <!ATTLIST ascendingnode value CDATA #REQUIRED>
                <!ELEMENT longofpericenter EMPTY>
                          <!ATTLIST longofpericenter value CDATA #REQUIRED>
                <!ELEMENT meanlongitude EMPTY>
                          <!ATTLIST meanlongitude value CDATA #REQUIRED>


The first line: <!ELEMENT solsys ( config, bodies )> tells us to expect a 'solsys' element first, which will contain only 'config' and 'bodies' elements in that order.

The 'bodies' tag is defined: '<!ELEMENT bodies ( body+ )> '

the '+' means allow any number of 'body' sub-elements.

Next we can define sub elements such as 'orbitScale':
<!ELEMENT orbitScale EMPTY>
this is marked as 'EMPTY' because is has no closing tag (i.e. it's written as <orbitScale /> rather than <orbitscale></orbitscale> )
Even though the tag is empty, it can still contain inline attributes which are useful for storing game data. The following entry in the DTD defines what attrivute names can be used (in the case, I'm using the attribute called 'value' ):
<!ATTLIST orbitScale value CDATA #REQUIRED>

The '#REQUIRED' keyword means this attribute must be present else the file won't validate.

If the attribute contains data from a predefined set, then we can define this here too, as with the '<orbit>' parameter:
<!ATTLIST orbit value (static|Mercury-VSOP87|Venus-VSOP87|elliptical) #REQUIRED>

This means you can insert any of the keywords: 'static', 'Mercury-VSOP87', 'Venus-VSOP87', 'elliptical' into the 'value' attribute. If anything else is present, then the file will not validate.

That's pretty much all you need for DTDs, at least as far as game data is concerned. The only other thing that is useful is the ability to define optional elements, by using a question mark. The 'ellipticalorbit' element in 'body' is optional:
<!ELEMENT body ( name, radius, surface, orbit, ellipticalorbit?)>
Back to top
View user's profile Visit poster's website
Magnulus



Joined: 08 Nov 2005
Posts: 556
Location: Bergen, Norway



PostPosted: Wed May 31, 2006 5:14 pm    Post subject: Reply with quote

Woah. Awesome-looking effects, Nick! Can't wait to see them in Ghosthack.

So you're using HTML-style tags and then the program interprets the tags not normally found in HTML in its own way? So it's like an HTMLplus kinda thing? That sounds fairly rad. Seems like you guys've put a lot of thought into a bunch of things.

I wanted to mention that I'm very surprised to see the amount of detail and emphasis goes into your development and planning thereof. From the outside, to an industry outsider, your production seems extremely professional and very routinely done. I'm impressed with this, and very pleased to see that you're able to merge some of the organisational aspects of an "industry" production with the creative freedom of an "indie" production.

This is all just me having wild guesses, of course, since I have no idea whatsoever how other indies develop their games. I guess more and more indies are starting to get very professional, which is why we're seeing such an up-swing in quality in the indie industry. This is probably because it seems as though many of the good indie dev houses contain at least a few former industry devs.

EDIT: What? No one posted a single-line post saying "AWESOME!" or "FINALLY!!" while I was rambling this time? Amazing!

Also, Wow! You were up early this time!
Back to top
View user's profile Visit poster's website MSN Messenger
icarus
Troll
Troll


Joined: 01 Mar 2004

Location: Olympia Washington



PostPosted: Wed May 31, 2006 11:12 pm    Post subject: Reply with quote

Que Hunter XI asking if I.C.E. is a reference to KNOTR for the 3rd time. Laughing
Back to top
View user's profile Visit poster's website
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Wed May 31, 2006 11:28 pm    Post subject: Reply with quote

Yeah! HUNTER XI:

Go Read Some William Gibson Books!!!



"ICE, ICE Baby..." (no! stop me!)

If only we could license that to play continually in the background of ghost hack mode...
Back to top
View user's profile Visit poster's website
Weeble
Starscape Jedi
Starscape Jedi


Joined: 25 Apr 2003
Posts: 1143
Location: Glasgow, Scotland



PostPosted: Thu Jun 01, 2006 12:34 am    Post subject: Reply with quote

I really need to learn DTDs at some point. Can the DTD enforce cross-reference constraints? Or is that left up to the program?

I like the effects, though it's hard to judge them when they're not in motion. Just looking at the still images, I think my favourite is the blue sphere of cubey things, with radial blue lines.
Back to top
View user's profile Visit poster's website MSN Messenger
Sorrow



Joined: 16 Jan 2004
Posts: 146
Location: Australia



PostPosted: Thu Jun 01, 2006 5:56 am    Post subject: Reply with quote

Awesome stuff there Fost.


Designing and creating effects is one of my favorite past times, i can't wait for my next game too be up to the stage where i can start on such things! Very Happy
Back to top
View user's profile MSN Messenger
Rup



Joined: 19 May 2003
Posts: 363
Location: London, UK



PostPosted: Thu Jun 01, 2006 6:44 am    Post subject: Reply with quote

Weeble wrote:
I like the effects, though it's hard to judge them when they're not in motion. Just looking at the still images, I think my favourite is the blue sphere of cubey things, with radial blue lines.


Yeah, that one looks pretty neat. It made me think of Anachronox from years back (but I might just be making that up - they had some sort of psychic attacks in that).

The green one at the top looks like Mr Robot's got an Indiana Jones-style staff Smile And the bottom left one of the four at the bottom caught my eye too, but they're all pretty spectacular.
Back to top
View user's profile
icarus
Troll
Troll


Joined: 01 Mar 2004

Location: Olympia Washington



PostPosted: Thu Jun 01, 2006 10:30 am    Post subject: Reply with quote

Fost wrote:
Yeah! HUNTER XI:

Go Read Some William Gibson Books!!!



Not reading gibson is one thing but do you have to ask twice. I was considering making an acount called Hunter VI and asking the question but i decided that would be going to far.
Back to top
View user's profile Visit poster's website
Fost
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 3734



PostPosted: Fri Jun 02, 2006 4:29 pm    Post subject: Reply with quote

Weeble wrote:
I like the effects, though it's hard to judge them when they're not in motion.

I'll get some flash vids up again next month - unsurprisingly, pressed for time this month Smile

Sorrow wrote:
Designing and creating effects is one of my favorite past times

I kind of have a love/hate relationship with effects creation. It seems to be a job I've always ended up with. The effects on work on gunmetal* lasted most of a year! Problem is, I'm always fighting little issues with effects systems. Just tiny things like one emitter allows you to fire things out at a certain angle, and another doesn't. Usually it's things that take no more than a day to fix, but in Mr. Robot's case, it's not an effects system we'll be using in the future so I'm wary of asking Poo Bear to do too much work on it. Even so, he's still ended up adding around 30 or more additions based on what I've asked him for. My ideal situation would be to have an effects system that stays with us across projects, and slowly evolves to have all these little requirements in place. Then we have a mature system where lots of small parameters come together allowing exponential variation.



*In fact, 'James' who posts on this forum from time to time, was working on the in house effects system shared by gunmetal and another project at the time, and I may have driven him partly insane with the sheer volume of request for that system...
Back to top
View user's profile Visit poster's website
Poo Bear
Pod Team
Pod Team


Joined: 14 Oct 2002
Posts: 4121
Location: Sheffield, UK



PostPosted: Sun Jun 04, 2006 9:17 am    Post subject: Reply with quote

Weeble wrote:
I really need to learn DTDs at some point.

If your tools support it, you may want to skip DTDs and learn 'XML Schemas instead' - they are likely to replace DTDs in the future. Schemas are DTDs written using XML (more proof that people are obssessed with using XML!) with the added advantage of being able to define data types (allowing precise control of what sort of data is passed in as well as where the data is passed in) and use namespaces.

Weeble wrote:
Can the DTD enforce cross-reference constraints? Or is that left up to the program?

There may be workaround to do it, but I'm fairly sure if there is, it wasn't part of the original design spec. Have a look at 'Identity constraints' in xml schemas though as I think they are probably the same thing.
Back to top
View user's profile Visit poster's website
Flumpaphone



Joined: 18 Sep 2003
Posts: 86



PostPosted: Sun Jun 04, 2006 2:27 pm    Post subject: Reply with quote

Wow! This entry went out fast Smile

I must tell you that I read many development diaries all over the internet (gamedev.net are not short of them) and the Moonpod ones trump them all. I think it is a combination of the small scale of your projects (I mean that comparatively with next generation teams, otherwise they are in fact quite grandiose designs!) and the industry level of professionalism and thought that goes into them.

Your thoughts on the use of XML in games should be required reading. There are a hundred articles on the how's of XML, but this is the first one I have seen that asks "why?" and "what is the best approach for games?".

Once again, because you are discussing a project within the scope of a small team, it makes a lot more sense to new programmers, or just people with an interest like myself.

Keep up the great work! Oh, and Fost - looking forward to seeing those effects in action, they look quite unique! Like abstract paintings of a magician in action.
Back to top
View user's profile
Sorrow



Joined: 16 Jan 2004
Posts: 146
Location: Australia



PostPosted: Tue Jun 06, 2006 11:01 am    Post subject: Reply with quote

Aah, well being the main programmer for all the projects i've ever taken part of the adding of new functionality is my problem Smile.

I also design my systems with specific effects in mind, so a lot of the brunt work is taken out there.... i guess Razz

Speaking of my new project i'll have to make a post in indy development when i have something to show off :p [so do not expect anything anytime soon]
Back to top
View user's profile MSN Messenger
Shagazar



Joined: 19 Oct 2005
Posts: 10



PostPosted: Tue Jun 06, 2006 10:45 pm    Post subject: Reply with quote

Nice to see Mr. Robot will have great special effects like Starscape. The effects were what initially made me want to buy Starscape, and it seems Mr. Robot won't disappoint either. Very Happy
Back to top
View user's profile
Doom III



Joined: 20 Apr 2004
Posts: 117



PostPosted: Wed Jun 07, 2006 11:39 am    Post subject: Reply with quote

ghost hack looks crazycool

i dont so much understand what the hell is happening in mr robot but i cant wait to find out

can i ask does ghost hack stand alone as a game itself Question

can we have a game mode for just ghost hack

like GHOST HACK> THE RPG Smile

looks like rpg to me anyway but you never can tell with moonpod

maybe there will be a racing game in mr robo next month or a card game or a fps

Wink
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    Discussion Pod Forum Index -> Developer Diary All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group