Smooth Times

This went pretty well. You can see from the video above the laser calculations are performed over several frames. However whilst this suits the Vectrex it's not accurate since it's not observing the speed of light!

The second video shows a close up of some debug counters. From top to bottom they show, frames taken to render, vectors rendered, beams processed. The good news is that they start counting but the laser doesn't appear until the end. (which is what we wanted.) The thresholds are all parametrised and the frame rate doesn't get affected when the beams are calculated. The only offset is that the sun needs to be a little higher in the sky for the beams to fire, and I think that's a nice side effect!

It all went smoothly today, which is lucky since there were several distractions. However I've firmed the code up for B1 to select object. B2 (held) enables J1 to move an object, or when released J1X rotates it. This has taken me to a junction to ponder on the game design. (I'll keep my ideas until next time though! ;)

Game play introduction

This video introduces a new concept and illustrates nicely what the sun is for! The weapons are solar powered and hence only activate when the sun is high in the respective player's hemisphere. Here we can see P1 and P2 weapons firing in turn as the sun moves. Note they are sharing components currently, but the results vary depending on the originating beam direction. Without moving components the effect would repeat so you can save bandwidth and simulate a successive "days" by hitting play again. Objects may be moved in real time independently of the turn based firing.

Incidentally the beams look very complication and only flash up for an instant. I suggest you use the blogger player pause button to examine the P1 and P2 laser configurations to see what's going on in a comfortable time frame. I will be using this object configuration to test the coding in step 2 below.

Tomorrow will be divided into 2 areas. 1) Removing the debug control mode and fixing the 1P and 2P controls. This will involve a little more design as I want to determine the features to permit a player to use. Currently my dilemma is whether to permit a free roving cursor for sabotaging enemy objects. My feeling is it will slow the pace down, we'll see what happens! The second area 2) Will be some reasonably hardcore code to spread the computation of the beam reflection calculations over multiple cycles so remove any display flicker. This will mean I need to freeze a computation status when time gets a little shy, and resume it on the next display cycle. It should be OK as I have used a lot of variables (bad me,) so saving the registers and adding a state engine should be all that's needed. Once that's in place the core engine will be complete, just needing improved collision detection (for which there will now be time if it is spread over multiple cycles) allowing me to concentrate on gameplay and making the game FUN!

Step 3 will probably be next week, which will be building the level engine so that difficulties and parameters such as object and their location may be controlled for each level.

Today's Progress

A good day today, first off I wanted to clear up the cities. My cycle counter showed that to draw 6 on screen at once I really had to trim things down. I liked Cecil's but it had too many vertices, so I took some inspiration from the cities in Patriots by the eminent JD. :) They're functional, look OK and are real quick to draw!

This first photo shows the cities nicely. Flipped for the 2P. Yep, this game is designed to primarily be a two player game. I'm pretty confident there will be a nice puzzle element for the 1P game option, but that will depend upon whether the 2P style can be maintained with some cool CPU AI. Note the second laser emitter too.

The huge square is a blocker, this will be one of the features to provide variety on different levels. These will essentially be laser-proof barriers. Some will be destructible some won't. They won't often be this large, but I just wanted to check the concept. you can see the laser just dies when it hits it.
I wanted to finish off the objects so I could move more toward the game play, hence I add the Splitter. This is a simple T piece. A laser hits the T vertical and is split into 2 beams perpendicular to the incident beam. In programming terms I kill the beam and spawn 2 new ones. This reduced beam wobble and gives me a chance to align both 2nd gen beams with each other more accurately. As you can see in this second photo, whilst the beam is indeed split to 90 degrees of the incident the spitter sprite is not currently rotated. I've no doubt I'll sort that out later, but for the moment I didn't want to waste the RAM. (Still need to reclaim the RAM spent on the sun, but I'll leave that for a dull day.) I'm pretty happy with the splitter, since my code was sufficiently modular that I was able to add it in only a few lines. In fact it was so easy I thought I'd add another object just for the fun of it. I hadn't planned to use it, so we'll see how it features in the final game, but I think it looks pretty cool.

This third picture shows the extra object.. the Prism. A nice refracting effect, and I think it will greatly increase the sophistication of game play strategies.

Visual alignment is not yet perfect, but that's because I wanted to get the code working rather than the cosmetics. It's a trivial thing once I determine how I want to sort the rotation. I'm thinking I may differentiate between the prism and the splitter, by only permitting rotation on the splitter.

The final pic looks rather busy, this is showing the game concept coming together nicely. Here we can see the original laser coming up from the bottom of the pic where it strikes the splitter. It branches left and right. The left beam simply hits a mirror and collides with city #1. The right beam hits a further prism which splits the laser into 3 beams. Nicely clipping cities #2 and #3. This would be a good result if it were being played for real here.

Normal services resumes..(shortly)

Hi Guys,

Sorry for the pause in updates, you haven't missed anything, I've just been a little busy with my day job! :) There are scheduled coding days Tuesday and Wednesday this week, so you should be spoilt for updates! :)

Meanwhile here's a submission of a city graphic from Cecil C. inspired by Missile Command. (Thanks Cecil, all submissions are much appreciated and will always be shown in this blog.) I'll be exploring the options on this one, but the number of vertexes is still an issue since there will be 6 on screen simultaneously.