UnderwareDESIGN

     I started this yesterday.  So far it's represents about two hours work.    The demo is created largely from (95%) cut-pasted tidbits from the PlayBASIC example pack.    The art work is stock PlayBASIC artwork.  The Tree.jpg ( Blink) and the ship is from the Trillion art pack (Pincho Paxton) that was given to us like two years ago.  ( I must put that together at some point, although i guess this is it :) )

    The example demonstrates the basic frame work of a horizontal shooter.   The player is  flying past a forest which is being  flooded by water.  (ie Ballistic Blaster Style (http://www.ballisticblasters.underwaredesign.com))  Looks a bit like an old psygnosis game which I still can't recall the name of.  

  Looking at the picture, it's probably difficult to see just what is going on in the shot.  Basically it's 3 layers.  Scrolling backdrop,  250 rotating sprites and two screen sized post processing effects to create for the flooding effect (Variable Alpha & sine wave -  Creative - not :) ).  The demo is locked at 45 fps btw - it runs quite nicely..

  Written in PlayBASIC V1.62.

   Get Source Code Here (http://www.underwaredesign.com/forums/index.php?topic=1896.msg15970#msg15970)


 

---

Watch

---

 Watch Thesius XIII Tech Demo Video (http://www.youtube.com/watch?v=CQeLthm4Zuw) on youtube

 


 

---

Related Links:

---

      - Thesius XII (Amiga Game) (https://www.underwaredesign.com/?page=programs.Thesius-XII)
      - Thesius XII (The Making Of) (https://www.underwaredesign.com/forums/index.php?topic=4479.0)
      - 20 Years since Thesius XII (https://www.underwaredesign.com/forums/index.php?topic=4142.0)

   It's a bit hard to see, but the blend and ripple get heavier towards the bottom of the image, sort simulating depth.   If you look closely the water line is running through the player.   

   I'm not exactly going to put a great deal of effort into this, just a proof of concept.  :)

Update V001

     Here's another hour or so of  messing about.    The main changes are that buildings in the foreground.  These are on the near plane, so the figther flies in and around them.  The idea is that  the tech is sort of simulating an underwater city environment.   The water line is bobbing up and down with sine wave  displacement.    Don't ask me what the forest  backdrop  represents now.   It's just whatever media I had sitting around thrown together.  :)   The buildings from the Trillion art pack also.

     Some of the builds are transparent, some are  solid.  The player sort of flies between them.    The score and the health meter are drawn direct to the screen, but I probably should post process them also.    Also need something to show the top of the water more clearly.   Anyway, here's a few pictures of the current running demo.

 Pic #2

Sounds interesting. :)

Pic #3

  This one has 150 sprites,  some explosion animations  + full screen cross fade running in & out.    Basically the drawing process is done, although i'm going to change how the buildings work.   Temped to make a little dropping tool to layout some level, but I really can't afford the time.     I'm not intending on spending a much time on this, it's just showing that with a little bit of thought you can make some interesting stuff.    Even in PB1.62.   

Will you be posting the code to this, so that others can "borrow" your routines to enhance their games with a bit of effect candy?

    I'll post the code at some point.  But there's nothing that is being done here that you don't already have in your example pack! :) 

Update V002

   Previous shots of this were a more a proof of concept than game demo, ie. while it moved you couldn't actually play.   Today my aim is to get a basic game  running.  So far we have  player controls / simple weapons / particles.   Next comes a alien frame work.    I'm not really writing much, more grabbing bits of AXIS framework and customizing it to suit.

   While traditionally these type of games have used a very snappy digital control mechanism via the keyboard, or digi joystick/joypad.  This time around I wanted to try something different (for me at least).  So I've been experimenting with mouse control.    While it's hard to tell how it'll feel when playing,  i'm pretty happy with the result on it's  own.

   Some more shots.

 pic #5

Update V002b

    In this shot you can see the make ship alien controller + alien bullet controller running.  It's a bit hard to make out due to virtually everything being alpha'd in the scene.. for no other reason than cause I can :). 

    Also, the tech now has full pixel perfect (rotated/scaled) collision between  player and aliens & alien bullets, and  course between player bullets to aliens. 

Update V004

   Finally getting back to this demo.  Current tasks are building an environment manager & level loading frame work.   I can't say a lot of thought is going into it, but the idea is to have a open set of document that the level designer could customize to build new levels.   

    Bellow you can see another fairly samey looking couple of shots but this time there's a basic version of the environment manager running.  The manager stores the passive scenery objects in the world.   It's job is to show what objects that are in view at whatever position the player is within  world.  It also handles perspective projection of the objects, so the scene is a little more accurate depth wise.   

      I've fine tuned the player a bit more, mainly how it acts when you collide with alien objects.  So now it kinda feels like there's real impact them you hit something and vice versa.   Also, since scenery objects can be in front of the player, the engine will alpha's foreground objects out, so you can still what's going on behind them.   Which is what the shot's bellow are trying to show. 

 pic 8 -  You can see the player/aliens behind alpha'd out full screen buildings

I presume this is all happening without any/too much slowdown? (http://www.retroremakes.com/forum2/images/smilies/a13.slobber.gif)

Excellent stuff :)

    In these types of extreme cases  the physical rate will obviously vary.   We're pushing  at least  4->5 meg of pre & post processed pixel data to produce one frame here.   Which is just overkill, but fun :)   If you look closely you'll notice there's 5 buildings lined up all each alpha blended over each other. I.e the extreme case.    While you can see and play fine while full screen stuff is front of you, it's rather disorientating to do so.     

Update V008

    I've been tinkering away this the past couple of afternoons on clean up duty.  A lot of this was simply throw together to get something on screen quickly.   So i've set up the program to start, play and finish a a very basic game.  Calling it a game is bit of overstatement really,  while you can play, and die,  the aliens are user generated at this point.  Ie. press F1 to get attacked..  :)     So i think that can be this afternoons little task.

    For aliens, i'm just going to throw in something to spawn convoy types at pre determined points throughout the level.   The spawning i think i'll making fairly random.  So while they're generated once you reach point X, perhaps their origin, direction, or number could differ.   Some objects could have predetermine paths, behaviors though.   Which I think would make a for a better mix of  game play in terms of the replay factor.  It's a difficult genre to make replaying not so samey thought. 

    The example now features some visual scalability also.  What I mean by that, is that display routines now can use some simple Mip Mapping when rendering the environment (the buildings in this case).  This means that objects that are further away from the camera (which is fixed in space) use a lower quality version of their texture.   Most textures have 3 sizes.   Full,  Mid (1/2 size), Small(1/4size)   So near objects render the highest quality version, mid objects render the 1/2 size version, and far objects use the 1/4 sized version.

    The end result is pretty much the same image quality, but it takes the computer less time and effort to render the mid/low quality versions of the environment objects.   The reason is that smaller textures fit in the cache better, which means the pixels are faster to access, faster to access means faster drawing. 

   You can also set the environment quality.    This scales the Hi Quality versions down by a factor of whatever you set.   The mipmaps are then generated from this smaller version to begin with.    The more you reduce the hi-quality versions though, the more finer detail and blocky near objects become.  But, it does reduce the work load for slower computers. 

   I think i'll also add a 'quality' tag on environment def's (the environment stuff is just randomly spawned atm).    So the user could select what backdrop quality they want.  This would allows the display engine to only display the important objects and remove any objects that are just window dressing to the scene.   I wanted to have tuffs of grass/reeds for example, but i couldn't find any.  But that stuff would be ideal for removal as well as building that are just there for something to fill out space.   

   Performance wise, since the game play runs at an predetermined rate,  so it's still playable as low as 10 physical frames per second.   My Duron 800 mhz system for example is struggling in highest detail,  but can get up to 15->20fps by reducing the quality.   It's never going to be super smooth on it, but still quite playable.   

   Other ideas to improve scalability would be to add quality reduction to objects.   For the much the same reason, the smaller the texture, better old computers can deal with it.  Do this we'd 1/2 the texture size, then Mult the sprites scale by 2.  So the object appears to be same screen size, just a little chunkier.    This will also improve the performance of things like pixel prefect collision.  For the same reason.  Small textures = faster to access the pixels.   

   Anyway,  I was going to post video of the demo running , the quality of video is horrible (captured on my little digital camera that's why - which needs LOTS of light of get a clean image..  ) , but you should be able to get some idea of what it looks like running in my secret lair.  Spooky  :)

 Pic,

  In this pic i'm just toying with a lazer beam type effect.   


 

That's looking excellent :)

Yeah,  It's getting there.  It's mostly a bunch of pretty media slapped in front of the camera.   I'm actually rather enjoying something 'different' to play with actually, but will no doubt have to get back to more pressing issue very soon..

I presume that you are using the new 3D sprites from the PB betas for some of those effects?

Nope...

Mock Up V010

   Had less than a couple of hours to invest on this today, which i've mostly spent trying to find some alien artwork, so I can at least have a few different aliens types for the mock up level.    Annoyingly the trillion pack is incomplete, and really only comes the player ship and the few buildings you see here.   It'd be great if it had ships,  at least then they match the style somewhat.   In this picture i'm just trying some other tidbits i found sitting around.  I had to change the perspective slightly so that the crab like ships (on the floor) appear to be walking on the ground within the scene.  But ya get that.

   Also, improved the level definition loading by 7 seconds just by using the replacement load textfile function thing - What a coincidence :)
   

 
   Finally found out who made the Trillion artwork, it was guy called Pincho Paxton from the DB community.   He also did the artwork for a number of Amiga games.  The Amiga port of Armalyte comes to mind. 

  Update V011

     Previously the game played from a fixed view.  It was fixed in order to keep the water alpha/wave illusion working.  As if the camera move up (above the water height) for example, then this would break the water/effect.    Since demo it was set up to draw the world in cross section. 

    So In another rather whimsical edit session today,  i've been experimenting with expanding the a players play area to be higher than the screen.  This not only means adapting the scenes perspective, but it changes the feel of the controls since their mouse based.  Which i'm not so sure i like atm.

     While I like the perspective change (even though it took a little longer than I wanted)  it breaks the original water illusion. Since it was plane masked in front of the camera.    The problem is that the player can now move from within the water to above it and vice versa .  When your above it, we need to render the top.  Which creates few little gottcha's, the result (when in this mock up)  does seem worth the effort.  So i can't complain too much.

And after a few more tweaks, you can go from above to bellow and vise versa

Update V012

     With each edit session this example is slowly transforming from a tech demo into a playable game.    The past few sessions i've been implementing some bonus stuff like a front end to the demo, plus the core nuts and bolts of some basic  behaviors for the objects.    There's only four alien objects (that's all the gfx i have :) ).  Which are the outrigger (the big star thing),  crab (green things under water), spin mines and homing missiles.   In keeping with the cut and paste nature of the demo, the homing missiles code was cut and paste from one of clever coder programming challenges.    Initially the missiles were classed as bullets,  which meant you couldn't shoot them.   This seemed a bit too unfair though, so they've been re-classed as alien objects.   Which feel betters, but still rather challenging to avoid them !

     In the shot you can see the homing missiles and that i've been experimenting with the player bullet count.  So now you fire 5 bullets at once.  The extra bullets aren't aligned to the ship, they're just spawned at some fixed offset.  It's just to get an idea of the potential  load the player might place on the demo if they had more weapons.     I've got some weapon pick up graphics that i might as well throw in to complete the frame work.   

     I really wouldn't mind making a full level out of it, i'm pretty happy with the feel of it, even though it's impossibly hard ATM :)..   but I really shouldn't waste too much more time on it now. Maybe later...

Added RawImage Animation Library

  Yesterday's session started out as a quick tinker to implement Power Ups, but soon turned into building an impromptu image animation pack format.  Which is something i'd been meaning to implement into this demo for while, but hadn't got around to it.   Previously image animation sequences were stored as a series of frames on common images (BMP,PNG) . To load them, we're load the image and cut out the fixed size frames. While this is a adequate enough approach, it's just not very optimal in terms of render speed (lots of dead pixels) or memory !

  To quickly demonstrate my point, imagine we have a 32 frame animation of the a character running.  You can no doubt picture that some frames will be wider or higher than others in the sequence (i.e when the character is at full stretch will no doubt be wider than when the character is standing).  But to make our lives simpler we'll often store all the frames as 128x*128y cells.     So regardless of how wide/height the actually graphics of a frame are, all frames will be 128x*128y pixels.

i.e


    --------------------------
   |                          |
   |          WWWWW           |
   |          o   o           |
   |            -             |
   |          \___/           |
   |          __|__           |
   |        /|     |\         |
   |        ||     | |        |
   |        ||     | |        |
   |        ||     | |        |
   |       **|=====| **       |
   |         |     |          |
   |         |  |  |          |
   |         |  |  |          |
   |         |  |  |          |
   |       ***** *****        |
   |                          |
    --------------------------





   Beautiful ASCII huh :) , anyway, if we imagine the above is one cell from our character animation. You can clearly see the actual graphic is only using about a 1/2th of the frame area.   The rest ends up as transparent pixels (wasted space).   While we won't see extra area when we render this frame (with a colour mask), this extra rendering (even though it's transparent) it will effect the speed of rendering.   Why ? - It's simple, every pixel you draw costs a pretty fixed amount of processing time.   So the more pixels you draw (the bigger the image), the more time the computer must invest in rendering this image.  The other factor is memory. The bigger an image gets the more memory it will require.  The more memory, the muscle the machine need to the deal with it.

    So for comparison sake, lets say the above frame actually is 64x*128y pixels, so rather than grabbing the entire 128*128 block, what if we just grab the used area instead ? Obviously, we'll be saving ourselves memory and this smaller frame will be easier for the computer to render.

   Original Frame size 128*128 = 16384 pixels in this frame 16384 *4 = 65536 bytes 64k)

   Clipped Frame size 64*128 = 8192 pixel in this frame 8192*4 = 32768 bytes 32k)


   That's a 50% saving, which is pretty considerable since we're only looking at one frame. While we probably wouldn't get the same level of saving on every frame in our character animation, we've no doubt be able to reduce the majority of them. It's not uncommon to get 25% saving on average.   Which really adds up.

   For example, if we have 32 frames of 128*128, that requires (32*65536) 2,097,152 bytes (about 2 Meg )

    If we trimmed the anim frames and reduced the animation to 75% of it's original size (a 25% saving) the trimmed animation would only require (2,097,152 * 0.75)= 1,572,864 bytes (about 1.5 meg) - That's a 500k saving for just a little effort. 

   
    Which finally gets me back to my topic,  so knowing that we can improve performance and save memory by optimizing our images for dead pixels.   I decided to write a simply library that would take pre-drawn, or dynamically created animations (stored in an array), trim the frames down and save them out  in a simple pack file format.   This has added advantages over the loading and separating method also.   The main one, is that it's far more efferent in terms of memory during loading, it's can also be faster (assuming your loading FX images).   Previously, if you stored many animation frames on a single image, this meant you need to load (and decompress) the image into memory first.  Next you'd grab the require frames and delete the loaded version.   During the grabbing  period though,  you've effectively got two copies of the image data in memory.     While this isn't a big problem on modern systems, it can make all the difference when running your application on older systems with less system and video memory.   

    So to recap the benefits of  trimming our animations of dead pixels,

    *) Faster Rendering due to reduction of pixels

     *) Faster Collision due to a reduction of pixels

     *) Minimizes the amount of memory each frame requires.  (This also has the added benefit of being more cache friendly on older machines - i.e can help with speed also)

     *)  Faster & more memory efficient direct to surface loading       

     The  main negative is the pack files aren't compressed, so they are larger on disc when compared to their compressed counterpart.   This is negated when the files are zipped into a package though,  as the resulting files generally (+ or - a few K) come of the same size. 

     Anyway, you'll find the RawIMage library ( HERE (http://www.underwaredesign.com/forums/index.php?topic=1896.msg13774#msg13774) or the Forest blaster source.   
 

Raw Image Pack File Library

    Here's a version of the pack file library that I mentioned above.  It's been tweaked a bit since last week and now includes a rough as guts palette mapped format also.  This could be improved, I really can't be bothered!    As for how to use it, there's basically four main functions,  a pair to load/save single images and pair to load/saves animations stored in an array().

   This is recommended for use with PB1.63 or above, but is compatible with older version also.

While working on the 1.63h release blend modes I ran into this error in 16bit mode.. Sorta liked it, so here it is :)

Thesius XIII Forest Blast  - Download

    Decided to release source code as is.  Basically it's the game frame work, without a real level to play :(.    I've decided to release it now as it's been some 3/4 weeks since I touched it and given that i'm currently bogged down updating old the demo/media packs.   This could have easily fallen by the way side. So here it is.

    The code was written in PlayBasic 1.62/1.63.  Feature wise it only uses a handful of PB effects, namely pixel perfect collision,  variable and alpha 50 blend modes (sprites and box) and Alpha colour addition for sprite flashes.  If you removed the 'linked list' controls in the particle library, it'd compile and run really old version of PB also. I.e.  PBv1.40 possibly as low as probably V1.30.

    This demo was largely created from cut-pasted tidbits from the PlayBasic example packs.  Most notably from the AXIS (http://www.underwaredesign.com/forums/index.php?topic=1278.0) demo,  which is what the whole thing is based upon.  The art work is a combination of stock PB artwork like  Blink's forest backdrop, combined with Pincho Paxton's Trillion art (Ship/buildings),  combined with some elements from TheMaskedCoder's  and various tidbit that were sitting in my GFX folder.  I've no idea where they're from..  

  Have fun working it out :).


Download

  [plink] Download Thesius XIII Forest Blast (Source Code only) (http://www.underwaredesign.com/getfile.php?file=pub/PlayBasic/Examples/UW/ThesiusXIII_ForestBlast.zip)[/plink] (2.4meg)

Amazing work Kevin.  The effects are phenomenal.  I had never considered a shoot 'em up where the ship goes above and below water, but not only does it look great, but I'm sure it would allow interesting possibilities for enemy design and gameplay.  Looking at your code I thought you might have some secret functions to keep the framerate high, but saw the same inkmodes and spritedrawmodes that we all use.  What was the reasoning behind not using either sine shapes or a water image instead of the box command for the water?  Would framerate have suffered too much?

"This example was written coincide with the Blaster Blaster competition. " means that it's not an entrant I'm guessing?  I'm sure it would rack up some programming points (but might suffer on sound ;) ).

 

QuoteAmazing work Kevin.  The effects are phenomenal.  I had never considered a shoot 'em up where the ship goes above and below water, but not only does it look great, but I'm sure it would allow interesting possibilities for enemy design and gameplay.  Looking at your code I thought you might have some secret functions to keep the framerate high, but saw the same inkmodes and spritedrawmodes that we all use.

  If only I had $1 for every time i heard that. :)

QuoteWhat was the reasoning behind not using either sine shapes or a water image instead of the box command for the water?

    Originally i just cut and pasted the sine water height demo into the axis demo. And that was it for a while.   I didn't like the way it looked with a perspective scene.  Mainly since the viewer can stand above the water line, so you can see over it.  Which breaks the illusion.    You could project a triangle mesh, then then you'd need  clip the triangles against various building planes.  Doable, but a bit messier.

QuoteWould framerate have suffered too much?

   There'd be a slight overhead in rasterization, but after that, they use the rendering code.   It's a little difficult to see now, but the blending level of the water changes the deeper you get. 

Quote"This example was written coincide with the Blaster Blaster competition. " means that it's not an entrant I'm guessing?  I'm sure it would rack up some programming points (but might suffer on sound  ).

    ahh, If only I wasn't judging the competition :)     

 Code Update - Changes

     If you've tried running the Thesius XIII source/demo in PlayBasic V1.7x revisions,  you've no doubt run into an odd sprite doesn't exist problem.   I'd assumed this was from some difference with how the sprite list is traversed in PB1.7x, but it turned out that older editions of the PB (1.63 and bellow)  let you to attempt to detect impacts against sprites that didn't exist without raising an error.   This is not the case in PB1.7x editions however.

      Anyway,  So in order to get this demo running in newer editions of PB you'll need to replace the UpdatePlayerBullets() function (found in the Player source Tab) with one provided bellow.  Effectively what was happening was when a bullet left the screen, it was being deleted but rather than continuing the loop, it was falling through and hitting the SpriteHit command.    There was another logic error which would occur when bullet hit an alien.     Rather than  grabbing the Next Sprite in the list prior to subtracting damage from the hit alien,  it was doing it after it.   This is no problem when the alien wasn't destroyed, by if it was, the code would  end up reading a none existent sprite and popping a runtime error.

      Moreover, the original source code used the SpriteImageRGB command which is obsolete  in PB1.7x revisions.   While it's not actually used in the demo, it's present within the source code, so you can just delete or comment out any such instances from the source and it should compile and run.    When I get some time, i'll build a version of the source that will work in both editions,  Which is just a matter of  adding optional compilation tags.





Function UpdatePLayerBullets()
For Bullet=0 To GetArrayElements(PlayerBullets().tPLayerBullet,1)
If PlayerBullets(Bullet).status

x# =playerbullets(bullet).x#
y# =playerbullets(bullet).Y#
Spr =PlayerBullets(bullet).sprite

Select PlayerBullets(Bullet).Brain
Case PlayerBullet_Directional
Angle#=PlayerBUllets(Bullet).angle#
x#=CosNewValue(x#,angle#,10)
y#=SinNewValue(y#,angle#,10)

EndSelect

playerbullets(bullet).x#=x#
playerbullets(bullet).y#=y#
PositionSprite spr,x#,y#

If SpriteInCamera(spr,Screen.camera)=False
Delete_PlayerBullet(Bullet)
continue
EndIf

KillBullet=False
CheckSprite=GetFirstSprite()
Repeat

HitAlienSprite=SpriteHit(spr,CheckSprite,CollisionClass_Alien)

If HitALienSprite>0

CheckSprite=GetNextSprite(HitALienSprite)


SpriteDrawMode HitALienSprite,2+4096
SpriteAlphaAddColour HitAlienSprite,RndRGB()

CreateExplosionAnim(ExplosionAnim_Small,x#,y#,z#,rnd(360),rnd#(5),rndRange#(0.5,1.5))

if GetSpriteCollisionClass(HitAlienSprite)=CollisionClass_Alien


; handle Damnage on alien LAST..
; get the player that fired this shot
player=PlayerBullets(bullet).player

; handle damage alien and return score (if any)
Score=HandleAlienDamageFromSprite(HitAlienSprite,1)

if Score
Players(player).score=Players(player).score+score
Players(player).ScoreRefresh=true
endif

endif


KillBullet=True
EndIf
Until HitAlienSprite<1


If KillBullet
DeleteArrayObject(PlayerBullets().tplayerbullet,Bullet)
else
Inc NumberOfPlayerBullets
EndIf


EndIf // end of Status check
Next

// The Number Activate PLayers bullets this update
Game.Stats.ActivePlayerBullets=NumberOfPlayerBullets

EndFunction


It's back again

    It's been a long time between drinks for Thesius XIII, while this demo wasnever intended to be 'complete' game,  I'm in the process of adding a few more nick knacks so that this can be used as feature game in the upcoming re-release of the PlayBasic Demo.    Thesius XIII is of course a bit of shout out to a shooter I wrote some 15 years ago on the Amiga.  How time flies!


Object Manager

     So far, I'm just  tinkering around with adding an dynamic object trigger/management layer.  This object manager controls the activation of dynamic objects throughout the world.    In other words the engine stores all the objects in a list definitions or triggers if you will,  these  objects are effectively sitting in hiatus when in this state.    When the player reaches a particular point, the object manager triggers (adds) this object class to the scene, with the required properties (position, scale whatever)  and hey presto the character appears where-ever you've defined in with the world space.

    The level definitions looks like this.   So far the parser only supports the Mine trigger, but it's all seems to be working ok.  There's only 4 or 5 objects (all the GFX i've got) anyway :) 


<Triggers>

Mine=1100.0,200.0,400.0
Mine=1200.0,300.0,400.0
Mine=1300.0,500.0,400.0

Mine= 700.0,000.0,400.0
Mine= 800.0,000.0,400.0
Mine= 900.0,000.0,400.0

Mine=5300.0,500.0,400.0,0.0,0.0,0.0

</Triggers>


Do you use UFF for the definition file or something else?

BTW: Is there some XML parser for PlayBasic flying around?

I will look at this game tonight - I completely missed it during my year of PB absence but it looks great!

Cheers,
Tommy

QuoteDo you use UFF for the definition file or something else?

  See the source.

QuoteBTW: Is there some XML parser for PlayBasic flying around?

  not that i know of.

  Thesius XIII V0.16  - Bunker Objects

        Slowly picking through this in my spare time.  Adding a new object class bunkers and some more triggers, so that objects that are already implemented can be positioned in the level.   To save design time ( even I find that funny :)), objects can be triggered in two ways.  Individually or via random batches.    Obviously individually is where you trigger each object at a particular spot (ie. tedious), while random batches allows you to create an invisible objects that randomly spawns objects into the scene for a certain time.     Anyway, here's another piccy.

Thesius XIII V0.20

      Finally got back to working on this after various interruptions.   First thing on the agenda has been to change how the game engine deals with the world & screen space.     The previous editions the game engine had various ways with dealing the objects.   Some objects worked in world space coordinates others worked in screen space.   This was causing a few issues with syncing the camera movement as well interactions with the player.    Which was largely due to the hacked together origins of the demo.  Ie. Cut and paste     While such changes aren't slap in the face obvious (but you can notice while playing)  it now means everything (hopefully) uses the same system.   This means the player can now stop/speed up etc and game engine manages objects better.

       The picture bellow is another fairly samey picture.  It's simply showing a couple of new ship object types I've managed to scrounge up.    So far they have no behaviors, but they're likely to be pattern based (See Here (http://www.underwaredesign.com/forums/index.php?topic=2253.0)).    Basically canon fodder.   Also implementing some fragment explosions in static mines (more cut and paste :)).  Got a few other ideas but don't want to get two far ahead of myself..   Can always implement them later.

 Thesius XIII V0.21 - Fragments

   Been tinkering with adding fragments the past couple of hours.  These are particle type that generate a temp 'burnt' image when an explosion occurs.   The piccy bellow is overkill, stress test if you like.   It won't be used at this level in the actual demo.  Anyway,  it's simple but effective

 Thesius XIII V0.21 - Demo

    Since the last session I've implemented most of the object types.   All that really remains now is the boring level layout stuff.   Since current there's no real fixed level to play, so most of it's random..

    One of the new alien controllers is generic path follower (It uses this code (http://www.underwaredesign.com/forums/index.php?topic=2253.0) - surprise surprise ). ATM the falcon V ships (the sorta wedge looking ones) use it.   But they all use the same (odd ball) path from random spawn points.   If there's time i'd like to  set up the objects to run sets of paths. So you can make longer paths from smaller fragments. A bit like lego.   Which is an idea from my  original Thesius XII  game (Amiga).  In T12  the path/animation engine had controls to make random choices, even comparisons, animations triggers and loops.   This enabled objects to move through common junction points at will.   The idea was to give the fixed behaviors a more  dynamic feel.  

  Anyway, I've attached a demo for you tinker with. Have fun!



Controls

  Mouse = Control PLayer

   F1 = Trigger random spin mines
   F2 = Trigger random crabs
   F3 = Trigger random path based falcons.

   F5 = Slow down
   F6 = Speed up

   F8 = Add bullets to player

   Space = Trigger Homers

   Enter = Show Stat's

   ESC = QUIT



Download

[plink]Thesius XIII  V0.21 (http://www.underwaredesign.com/files/demos/ThesiusXIII_ForestBlast_V021.zip)[/plink]


 Built with PlayBasic V1.63v

mmm thats nice,very smooth

Cool!!!!its good game and good demonstration for playbasic!!!!!!!!!!!!!!!!

Thesius XIII - Pattern Editor

  Yep back working on the Thesius XIII tech demo, so I figured I might as well throw together a bit of pattern editor. Those with a keen eye will no doubt notice that it looks a lot like this Path Movement (http://www.underwaredesign.com/forums/index.php?topic=2253.0) combined with this BackDrop (http://www.underwaredesign.com/forums/index.php?topic=2343.0). That's because it is :) All i've added to this version is a camera so I can move outside of the 'game' viewport. This allows paths to be defined that start and end off the screen.

 ThesiusXIII V0.25

      This version setup to play a real (well thrown together) level now.   So objects are spawned through the trigger list, paths etc etc.. It's funny how much of a difference that makes, as all of sudden it's starting to feel like a real game.   All be it, a very one side game at the aliens are much stronger than the player.. but ya get that :)

Anyway, here's a few more pic's

  Thesius XIII V0.26 - Smarter Triggering

        Been stuck in the email backlog (hell) today,   so I haven't progressed much further visually.    Have made an interesting change to the trigger list format, well the trigger list parser anyway.  Previously when you  triggered an a new object, the object was spawned at a fixed location.    Which is fine most of the time, but it does get a bit too semey, in particular when spawning patterns.     As such, i've added rough and guts parser so that the coordinates can be use some internal variables in basic expressions.   So if you want the object to spawn at the games viewport top edge, you can now use the VPTOP variable.   If you want to be offset by 100 (above it).  Then you'd set it's Y pos to  VPTOP-100.   Moreover,  there's random functions also.  So you can now trigger a animated object (not that i have any animations really),  and assign it random starting position.  Which gives it a little more dynamic/chaotic feel.   

         Here's the current trigger data for something a bit different :)





; ----------------------------------------------------------------
; These are alien triggers.
; ----------------------------------------------------------------



; ===================
;  Cordinate Constant Tags
; ===================
;       VPTOP = Game Play Viewport Top cord
;       VPBOT = Game Play Viewport Bottom cord
;       VPLEFT = Game Play Viewport Left cord
;       VPRIGHT = Game Play Viewport Right cord
 
; VPRNDY = Random Y pos within the game player viewport


; ===================
; Trigger Event Types
; ===================





; Bunker = TriggerPos,  Xpos#,Ypos#,Zpos#
; Crab = TriggerPos   ; These are randomly spawned at either

side of the screen.
; CrabSpawner = TriggerPos,Xpos#,Ypos#,zpos#, LifeSpan   ; These are

randomly spawned at either side of the screen.

; Mine = TriggerPos,  Xpos#,Ypos#,Zpos#
; MineSpawner = TriggerPos,  Xpos#,Ypos#,Zpos#, Objects lift  ; These

are invisible objects that randomly
; add mines to the scene for a number of

frames

; OutRigger = TriggerPos,

Xpos#,Ypos#,Zpos#,TargetXpos#,TargetYpos#,TargetZpos#


; GenericAnimPath = TriggerPos,  Xpos#,Ypos#,Zpos# , ShipName$,PathList$,

SpawnCount, SpawnInterval




<Triggers>

    Mine=1100.0, 0, 200,400
    Mine=1200.0, 0, 300,400
    Mine=1300.0, 0, 500,400


    OutRigger=1500, 50, 100,400,-400, 200,400



; GenericAnimPath = TriggerPos,  Xpos#,Ypos#,Zpos# , ShipName$,PathList$,

SpawnCount, SpawnInterval
    GenericAnimPath = 1200, -200,VPTOP-150,500,falconV, Swoop3,20,8

    GenericAnimPath = 1400, -300,VPTOP-150,500,Xwing, Swoop1,40,10


    GenericAnimPath = 1300, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10
    GenericAnimPath = 1310, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10
    GenericAnimPath = 1320, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10
    GenericAnimPath = 1330, 0,VPRNDYtopHalf,500,FalconV, Rush1,5,10
    GenericAnimPath = 1340, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10
    GenericAnimPath = 1350, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10
    GenericAnimPath = 1360, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10
    GenericAnimPath = 1370, 0,VPRNDYtopHalf,500,Xwing, Rush1,5,10




    Bunker=2000, 0, 600,400
    Bunker=2400, 0, 600,400
    Bunker=2800, 0, 600,400





    MineSpawner=4000,  0,400,0, 2500


    CrabSpawner=1000,  0,400,0, 500



    Bunker=4000, 0, 600,400
    Bunker=4200, 0, 600,400
    Bunker=4400, 0, 600,400
    Bunker=4600, 0, 600,400
    Bunker=4800, 0, 600,400


    CrabSpawner=5500,  0,400,0, 1000


    Bunker=6000, 0, 600,400
    Bunker=6200, 0, 600,400
    Bunker=6400, 0, 600,400
    Bunker=6600, 0, 600,400
    Bunker=6800, 0, 600,400


    Bunker=8000, 0, 600,400
    Bunker=8200, 0, 600,400
    Bunker=8400, 0, 600,400
    Bunker=8600, 0, 600,400
    Bunker=8800, 0, 600,400

    Bunker=9000, 0, 600,400
    Bunker=9200, 0, 600,400
    Bunker=9400, 0, 600,400
    Bunker=9600, 0, 600,400
    Bunker=9800, 0, 600,400

</Triggers>




  Thesius XIII V0.26 - Source Code

  This is the current 'as is' state of the Thesius XIII demo with source code.   I can't really recall everything that's changed since the last demo,  but this version is now playable.   By that i mean all the objects have behaviors can you don't have to trigger them yourself.  The only problem now is that's pretty one sided :)  So you might want to press the F8 key a few times when you start the level.  This will give you a little more fire power.      

  I've also included the pattern editor, which as you'll see is just  hacked together form the other posted examples.  
 
   Anyway, Have fun!


Controls

  Mouse = Control Player

   F1 = Trigger random spin mines
   F2 = Trigger random crabs
   F3 = Trigger random path based falcons.

   F5 = Slow down
   F6 = Speed up

   F8 = Add bullets to player

   Space = Trigger Homers

   Enter = Show Stat's

   ESC = QUIT



Download

[plink] Thesius XIII  V0.26 (http://www.underwaredesign.com/getfile.php?file=pub/PlayBasic/Examples/UW/ThesiusXIII_V026.zip)[/plink]



 Videos

 This is more mature version.  Although the full game demo has more features
 Watch Thesius XIII Tech Demo Video (http://www.youtube.com/watch?v=CQeLthm4Zuw) on youtube

 


 This is video is from the first start of development on Thesius XIII
Watch Thesius XIII Tech Demo (http://www.youtube.com/watch?v=NWKqosbPHPI) on youtube.