StarLight: Alpha

[TheMightyJodo]

Hi, I'm looking for feedback. 

The sample game is at:  http://www.bluefugu.info/private/Starlight_Alpha.zip

I have a general idea what I want: basically a space exploration game (ala SQ3) with updated graphics.

For each planet you come across, you will attain orbit.  But I want lots of planets.

The current planet animation plays too fast, and it's just too big.  I plan to manually change the speed of the animation in AGS (each frame).

Should I use 3 views and not render the 2 pillars? 

Can I slide the planets into view (like Flash with a Mask) or must I use sprites?  This is more of a graphics question for the game, not too technical, but the specs are definitely a consideration.

[TheMightyJodo]

If you can answer any of these questions it will save me time testing:

1.) Sprite Method is too big.  is there anyway to make it work with Sprites?  is slicing them up around pillars the only option.

2.) A Glide script that moves the sprites would be fine, but I would need to test the alpha-blending behind the pillars.

3.) Plan so far: each planet gets it's 'own room' with global ship functions.  Each room has it's own planet views.  Global ship objects (the interface panels) would have to be copied from room to room this way... any alternatives?

Thanks for your feedback. 

[Shane 'ProgZmax' Stevens]

Your questions pertain to the technical side of ags rather than art so I'm moving this to beginners tech.

1.  Check answer 2

2.  Make the pillars walkbehinds with a baseline below where the planet image would appear but higher than your character can walk.

3.  You could make this interface a single room and change the planet image displayed by doing simple variable checks.  For instance, when you go to a new planet orbit an orbiting_planet variable could be set to the planet GRAPHIC NUMBER in question (defines would simplify this by doing #define CETI_ALPHA_FIVE 20).  When it comes time to display that planet you would run a function like:

function Display_Planet(bool state)
{
     if(state==0 && object[0].Visible) //turn the planet off or leave orbit
     {
         //what this does:  it will move the displayed planet to the coordinates -320,0
         //and will take over control of the engine will doing so (eBlock).
         //eAnywhere allows it to move regardless of walkable areas.

         object[0].Move(-320, 0, 2, eBlock, eAnywhere);
         
         object[0].Visible=0;  //turn it off since it's not doing anything.

     }
     if(state==1 && object[0].Visible==0)  //enter the orbit of planet orbiting_planet
     {
          object[0].X=-320; //or whatever the max width of the image is
          object[0].Y=0; //or whatever is necessary to align the image with the viewscreen
          object[0].Graphic=orbiting_planet;
          object[0].Visible=1; //make it visible.

          object[0].Move(0,0,eBlock,eAnywhere);  //moves it back on screen.

          //now if you want to make the planet animate or something once it appears
          //you will need to animate it based on a view.  You seem to know how to do
          // this already, but instead of making orbiting_planet key to a graphic number
         // you could have it key to a specific loop instead and play a looping Animation
         //while it slides into view.  Basically, instead of setting object[0].Graphic
         // you would:

         //object[0].SetView(PLANET_VIEWS, orbiting_planet, 0);
        //object[0].Animate(orbiting_planet, 5, eRepeat, eNoBlock, eForwards);
        //where PLANET_VIEWS is the name of your view where all the planet
        //animations are stored or whatnot. 

     }
}

Basically you could call this function with a 1 or a 0 whenever you wanted to display the planet of choice or remove it (just remember to import it in the header).  The orbiting_planet variable would then be useful for using the ship controls to go to that planet.  If any of this is unfamiliar I recommend looking through the manual.

[TheMightyJodo]

Thanks for the feedback.

4.) If I make this one room, will it load the planets from memory using this method, or will it load the next planet view from disk?

Using 1 room, I thought all of the planet views would have to load in memory.  I'm already at 22MB with 1 animation.

5.) The character won't walk behind the pillar, but the planet slides behind the pillar. 

Right now it's all one animation, but if I slide the planet behind the pillar, would it anti-alias against the planet in the background?

[Shane 'ProgZmax' Stevens]

Just load your animations into the sprite manager and assign them to views which you will select as needed.  22 meg for one animation is way, way too large.  Either you're using far more frames than necessary or you're importing the image as bmps rather than an animated gif or sequence of pngs.

As far as aliasing goes I don't think so, and I don't think it's something anyone will notice. 

[TheMightyJodo]

Ah, you mentioned BMP, but I am using 256-color GIF.  However, I remembered that when I was creating the View, they were smaller loops than I anticipated.

But ALL ~347? images are still in my resource file.  The compiled game is including all of the sprites (even the ones I'm not using).  I'm 99% sure of this.  That would explain the bloated file size.  I can get rid of 300 of these images (or use them for other planets).  Thanks for your help!

I can use a different room for each 'system' (which can include 20 planets).  20MB works.

BTW: (Going Graphics Mode:) The pixelated effect looking out at a planet is very noticeable, since you are looking out of the window during the time a planet comes into view.  Here's a screen shot without anti-aliasing (vs. the test game, where it this is not seen).  For me, it's just something I have to do to keep up the quality level in the game (compensating for things I lack).



FOLLOW-UP: How can I use the new O-Code to make new areas of space?  For instance, I want to release the game, and then 6 months later, open up a new sector of space (with new aliens, etc).

Thanks ProgZmax!

[Gilbert]

Just a clarification, the format for the imported images does nothing to the filesize of a game. So importing a sprite/background from a BMP file will make no difference from using a PNG or a GIF (provided they're in the same resolution and colour depth), since AGS compresses its resources internally with its own schemes.

I'll say the large size of the room is quite obviously because of the large number of animation frames, in my opinion even after taking half from it the animation would still be smooth for most people. On the other hand, unless you'll do something very dynamic in the future, the current test animation wouldn't look much different if you use one single sprite and zoom it in.

If you want to expand the game after release, I have two rough ideas:
1. Use the RunAGSGame () function, so you may release expansion paks as separated AGS games, which are to be launched from the parent.
2. Use the "auto-patch" feature, that is, if you drop a CRM file into an AGS game's folder, the engine will load the standalone room instead of the one in the compiled game. So in the compiled game you may say, put a dummy room50.crm into it which does nothing, but in the expansion pak there's a new room50.crm with content, so if you drop the room file into the folder the new room file will be used. However this doesn't work for sprites so you can't add sprites to a game with this feature. You may, though, drop in image files in the expansion and load them in-game as dynamic sprites using the DynamicSprite.Sprite.CreateFromFile() function, but this would be cumbersome for large amount of sprites (which is probably your case) so this may not be an option for you.

[TheMightyJodo]

Gilbot V7000a:
Both methods are interesting.  Thank you for your feedback!

I updated the game at the same URL above (clear browser cache to get latest file)
Changes:
1.) Game size really shrunk after removing the unused sprites. 
(Next step will be to reduce the sprite size even more by making the columns transparent in the sprites.)

2.) Added a sample interface screen for the Navigation side.
(Next step: make virtual buttons on the Navigation screen that pops up).

3.) Added more text.  The 'taste' and 'smell' icons might come in handy... the Taste icon could be changed to a wrench or tricorder (to fix the ship or get analyze something)

Actual next step for me is to sit down and come up with a Universe.   I'm thinking of using actual systems, then make up planets.  Lot's of design work now.

Thanks for helping me tackle these issues!

[TheMightyJodo]

Looks like I will have to abandon this game in a month or so.  I just don't have time.  If you want to contribute, here's something that came to mind:

1.) This space game can be very basic or very complex.  If we keep it basic, I would like to offer it as the Blue Cup Demo game.  I contribute sound effects and graphics for other projects, so if you could continue reading....

2.) For a Demo game, here's what I'm thinking: We copy Roger and give him a blue suit, green suit, and a third character has a yellow shirt.  We add one or two and provide some sample character dialog for the demo.

3.) A lot of Quest games have maps.  I was thinking of a map screen for the planet; which only shows if you command Ops to take the ship into orbit.

Your thoughts?

[Ashen]

Since this is drifting away from technical questions, and since Jodo has abandoned it anyway, LOCKED.

Any interested parties, take it to PM.