Vectorzoa/Eurocon 2007 Donates £1000 to Starlight Charity

A little late, but well worth waiting for. All monies are now received from the 2007 Eurocon Charity Event Auction. Vectorzoa's Joust raised £713, and a further £45.21 from Jeroen and Martijn's items. I've added an extra £23 personal contribution which, after UK Gift Aid of 28% hits a massive £1,000! Thanks to all involved especially Mat and Pepijn for bidding high and Jon for identifying the charity in 2006.

If you wish to help the Starlight Foundation Brighten the lives of seriously and terminally ill children click here to read how and/or make a donation online.

I include the donation confirmation message below. Note the £781.25 is before Tax is credited.

Dear Mr Nicholson

Thank you very much for your donation of £781.25

On behalf of everyone at Starlight Children's Foundation, I would like to thank you for this generous gift which will be used to enhance the quality of life of our Starlight Children.

This year, Starlight will brighten the lives of over 500,000 seriously and terminally ill children by granting their wishes and by providing entertainment in hospitals and hospices throughout the UK. All Starlight’s activities are aimed at distracting children from the pain, fear and isolation caused by their illness. We are very grateful for your contribution: currently there are hundreds of seriously and terminally ill children waiting for their wish. Starlight receives neither government nor lottery funding and relies entirely on the support of people like you.

Thank you also for signing up to Gift Aid. This means that the Inland Revenue will pay an extra 28p to Starlight for every £1 donation you make. No further action is required by you.

It is only through the generosity of the public that Starlight is able to fulfil the wishes and needs of its Starlight Children. Your donation is a valued contribution towards the provision of that care and your support is very much appreciated.

Yours sincerely

Neil Swan
Chief Executive

Starlight Children's Foundation
Macmillan House
Paddington Station
London
W2 1HD

Tel: 020 7262 2881
Fax: 020 7402 7403
Web: www.starlight.org.uk

Thanks again to all. - Alex (Vectorzoa)

December Update.

Hi All,

A small delay on development, nothing to worry about, just been busy with work, family and the recent frenzy of Vectrex auctions! I have some very intensive training at the beginning of January which will consume my efforts for the next few weeks but then I anticipate a light 6 weeks during which time I hope to progress and release Solar Wars. Thanks for all your support and interest in these recent months.

Happy Christmas to all Vectrexers (retro fans, and everybody else,) remember you can download your Vecvox Christmas Carols from http://vectorzoa.com/downloads.html and last years present at http://www.vectorzoa.com/pubbins/ZOAXMAS.BIN (check out the 2006 xmas blog entry.)

Cheers Alex

VecOS by Revival Studios (Eurocon demo)

This post refers to VecOS by Revival Studios. It is not a Vectrozoa release, and merely reflects my own opinion formed at Eurocon. VecOS is detailed at http://www.revival-studios.com/

VecOS is a very ambitious project to produce a form GUI Operating System front end and a variety of features that one might expect from a modern OS. The key point of VecOS is that all media and components are prepared on a PC, then they are assembled together into a single giant ROM which is booted on the Vectrex. The current limitation is that everything must fit within 32K, the advantage is that data format conversions, interpretations and pre-processing can all be done easily by the PC and presented in a efficient native Vectrex binary. Naturally since its a ROM the OS is effectively Read Only in terms of it's media, but it can hold many components (including traditional GCE binaries - remember most releases were only 4K)

The demonstration contained 4 distinct sections

• The GUI OS. Impressive skinned GUI, a PSP inspired look and feel was demonstrated, although Maritjn indicated Windows, etc would follow later. This was able to navigate the media elements, and launch traditional binaries.
  
• Bitmap display. Displayed a variety of images sourced from gifs etc, apparently full screen. Clearly limited by monochrome dithering, but superb in terms of the size of images. I think we knew Martijn was the master of Vectrex Rastering!
  
• Sound player. A surreal demo. Martijn played samples of Prodigy and Jnr-Snr tracks. Martijn was very apologetic of the quality of these tracks since they were sampled at only 3kbps however they were playing on a Vectrex! Click here for an exclusive Ed209 wav sample as produced by VecOS. It might sound a bit rough, but remember this is running on a Vectrex and produced using VecOS automated tools. (sorry but Martijn won't let me relelase the ROM itself.. yet)
  
• VecOS BASIC. This is the shocker, not to be confused with Ken Gibbons recent and superb Vectrex BASIC which provides a full embedded Vectrex BASIC editor and interpreter benefiting from the vectrex keyboard adaptor by Richard Hutchinson. VecOS BASIC is a different animal though. You write the BASIC program on your PC in a standard text editor. The language is pretty rich and even allows standard Vectrex vector drawing commands. I read the draft manual, it was very simple to understand and even simpler to learn than old school Spectrum or BBC Micro BASIC. You then compile the BASIC on your PC for the Vectrex although it turns it into a form of bytecode, and then VecOS writes it to a ROM to run on the Vectrex. All the ease and convenience of BASIC meaning literally anyone can write for it, and the power of pre-parsed code. Martijn demonstrated Pong that he had written, the code was simple to read and understand. Very much easier than ASM but running at a good speed. VecOS BASIC also contains automatic VecVox speech translation as a bonus. It will be very exciting to see the first 3rd party VecOS BASIC development. Final thought: It was very impressive, but I wonder if Martijn has missed the Vectrex killer app here? If he could just compile it to full machine code with reasonable optimisation the speed would increase the potential even further! Maybe that will follow soon?
  

An amazing combination of features, which also included support for Chip8 and other obscure languages. I even heard rumour that Martijn has reverse engineered some of my Vectrex Logo for VecOS!
VecOS could be the best thing to hit Vectrex in a long time or it could be a curiosity; clearly it works hard to make the Vectrex do stuff it was never intended to do, and as a technical achievement it is already incredible. What happens will be down to us and how we receive this. Let's give it the reception, appreciation and support it needs to ensure it becomes a landmark in Vectrex development history! Great work Martijn!

Solar Wars Controls for the Pre Release

(Below are brief control instructions courtesy of Mr Wenting beautifully transposed from my plain notice.)

Solar Wars Play Testing

Many thanks to those who took time to play and discuss Solar Wars with me on Saturday at Eurocon 2007. In particular notable contributions came from Sijmen, Pepijn, Jeroen, Mat, John L. and John M.

There were 8 copies available for purchase. The actual game will be released in about a month or so with all game play issues changes implemented and features such as 1 player mode, superior collision detection, SFX and music added.

Points raised during play testing included:
(Likely response in italics, please comment)

• The controls take some getting used to. Perhaps a tutorial or at least a reminder to put them on the overlay.
• Player error e.g. overzealous mirror creation. Creating a mirror will require a large quantity of energy, this will slow down the player's creation and reduce cluttering.
• Player error e.g. spurious mirror creation. It was suggested all mirrors "die" over time. I'm not sure I like the idea of them deteriorating even when not struck my the laser, as this is a key strategy point, also it would be hard to guage appropriate lifespan. A useful mirror might die to soon and a bad mirror to slowly. I propose a delete mirror feature enabled by holding B1 (select) and pressing B3 (on/off)
• Mirror quotas. Currently the number of objects is capped. This is a performance constraint and might be relaxed when I optimise the code. The current number is 12 which would well enough, however this number is shared between players. One play can "hog" all the mirrors. I propose to cap each player evenly to prevent one player being denied mirrors by a greedy opponent
• Extreme defensive play. It was discovered that a losing player might take a 100% defensive stance, leading to a frustrating stand off. Solution currently unclear.
• The game is great fun in the middle of a battle, especially when prisms are involved, but some levels can prove plain awkward. Apply more thought and quality control to level design.
• Prisms really do add an excting danger element. The splitters don't seem so great. Consider better level design for splitters or swop it for a new object.
  
• The final furlong can prove a little unpredictable when the laser leaves the cursor area. This is already quite tight to prevent easy wins, but the line gradient can bend slightly. Check the collision detection near the cities and remove the "bend"
• The prism apparently "breaks the laws of optics". (Possibly since it is an icon and therefore to represent a prism and was not intended to rotate correctly.) However to clear this up I will consult a "laser/optic geek" (his words not mine!)
• To be continued...
• 
  

A quick Eurocon note

I'm rather pressed for time tonight, so this is a place holder for a few entries I need to write. In particular I will cover in detail what was for me the highlight of the weekend, which was Martijn's presentation of his VecOS.

I will also detail the suggestions made and conclusions drawn by Eurocon attendees who were kind enough to spend time play testing Solar Wars.

Joust Evolution Auctioned

(This article in a draft pending a little more time to complete)

In a somewhat unplanned move, but inspired by the rekindled memories of the charity auction of Spike's Circus in the last Eurocon and following lengthy discussions with John Macallan (who made the physical carts) I found myself auctioning Joust Evolution for the Starlight charity which provides Games Consoles for children who are ill in hospital.

The item actually auctioned is a combination of Vectrex items which occured to me at Eurocon and are listed below: (this may change as further items come to light)

• The unique sand filled transparent cased Joust Evolution Cart originally intended for CGE2007
• A unique solid yet transparent cased Joust Evolution Cart used as a prototype for the above.
• The binary of the final state of Joust Evolution
• Miscellaneous other development Joust related binaries
  
• The transfer of the rights to the carts, binaries and Joust Evolution itself (excluding original source code)
• The promise that no Joust Classic or Evolution will ever be released by Vectorzoa in any format at any time.
• The promise that the source code will never be released without express permission of the auction winner (and also at the discretion of myself)
• The 5 (# TBC) Joust overlay prototypes that were produced by Madtronix
• A short breakdown of the ROM binary explaining parameters and addresses of note for possible customisation by the winner.

The auction itself took place around 3pm on Sunday 04 November 2007.

An edited version is shown below. This can be removed if anyone objects to its publication.

• The starting price was 50 euros.
• The auctioneer is Hakan
  
• The ebay charity reserve was quickly hit by SS at 250 euros.
• We join the bidding as PB astounds the room with a bid of 800 euros!

The final winning bid was 1025 euros by Mayhem!
(this equates to 713 GBP or 1484 USD)

Confirmation of the donation will be published here when received by Starlight.
(Similarly I will also post when I receive full payment for Joust)

Note: Martijn Wenting and Jeroen Sanders were both kind enough to donate items to the same charity. This raised a further 65 euros which will also be forwarded to Starlight.

Eurocon 2007 - Game Over (1518 km later)

(..that's 943 driven miles)
Just back, I notice there's lot of news already on the net, but I'll be adding my own contributions pretty soon!
Many thanks to Sandra & Sijmen for their professionalism and passion in arranging the event!

Pre Eurocon Tuning

Last session before we leave. I've added a bunch of levels and realised a new feature where I choose whether or not the players can share items. It adds a whole new dimension for strategy. It's clear to me the level design is a real exciting time. I've put in about 25 for now, but I will reconsider for the final release. I also added the game over test! (So it stops when some wins.)

So this is it for Eurocon 2007!

I've sent the ROM image off to be EPROMed. (My programmer is offline at the mo.) Hopefully I've get half a dozen to demo/sell at Eurocon. This will be a pre-release, which if we consider what happened to Joust, might be well worth buying! :) Seriously I'll check out the gameplay with the Euroconners, tweak it when I get back, add the 1P mode and look to release it end of November(2007.) I've enjoyed playing it today, so I want to take the time to get it just right.

If you're in the Netherlands 2-3-4 November pop by and say "Hello!"
If you're not, then add a comment to this blog! :)

Eurocon link:
http://www.atari-shop.nl/eurocon2007.htm

Compiled code size 9,946 bytes

Twice the fun!

2 days before we leave for Eurocon 2007. I've just cloned all behaviour to Player 2. So now the game actually plays! Normally this is the point where I release I've shared a variable or been lazy with my ASM labels. Fortunately it went smoothly, I guess I've learnt enough lessons from the past (especially Art of War.) This was the first time I could actually play it 2P and a few things occurred to me. I've discovered a nice game variation by limiting how far the player can move up the field. I also speeded up the energy recharge. I found a effective limit on the number of objects, I'll look at this again later, but for the moment it's capped to 12 which is plenty I think.

8K barrier passed

Few more hours on Solar Wars today. I built upon the previous sessions level loader by producing a few levels, and added a level select feature. (Which forced the title screen too; below) I tried some fairly complex scenery which enabled me to encounter the accumulative error shown below (the beam on the left should bounce off the mirror.) I've improved this so it doesn't occur any more, but I'm not convinced its perfect yet, and will test further another time.

The 3 screen shots below show some aspects of game play. The left frame is the P2 laser firing into some fixed scenery, the centre frame shows the P1 laser firing into the same scenery but with a single mirror object present, and the third frame shows the orignial P2 laser bouncing on the same mirror in the same position. (Emphasising that the same mirror can be used by both players independently.)
The next session will involve fully cloning the P1 functionality onto the P2 joypad (and disabling the debug scope that shows along the bottom and is controlled by the P2 joystick at the moment.) Then some two player game testing will commence!

Compiled code size 8535 bytes

Taking it up a level

Quick entry today. Found a few hours to progress Solar Wars. Nothing visual to show really so I'll describe what I added. The level loader is now present, I can write an Nx8 byte array to control the layout of each level. Clearly some levels have more objects than others hence the ragged length N. The objects that can be defined are:

• Standard mirrors (placement, orientation, ownership, starting condition)
• Really Big mirrors (placement, orientation, size)
• Blockers (placement, orientation, size)
• Splitters (placement, ownership)
• Prisms (placement, ownership)

Yep, I added big (fixed) mirrors, I think this will make the levels more challenging (read dangerous) on later levels.

Now I need to sketch a few. This won't be a big deal as they are really just a few hurdles to provide variation for the players. I imagine in the 2P mode there will be favourite levels that will be played repeatedly. At the moment I'm not sure whether to allow the player free selection of the levels or to unlock them progressively like in Spike's Circus.

I've also been pondering the AI off-line. To respond to cNp's query: it always depends on the game and what heuristics the programmer can devise. The Joust AI was really easy to write, even the skill levels of the various CPU opponents and their personalities. On Solar Wars it's a little harder since there are literally more dimensions to consider. I have figured a few methods for the CPU AI, but first I'm going to finish the 2P version and study how real humans play against each other (to get a bit more variety in style.) At Eurocon I'll do some 2P play testing and then add the AI ready for the full release shortly afterwards.

Putting the game together

A few more hours today, all went rather well. I'm pleased that the code let me add the odd test/branch here and there to begin shaping the game play. Today was really about behaviour and adding constraints to improve the player experience:

• added energy bars to the solar emitters / players
• added damage to the mirrors
• added visual bars to show their status
• switched the object indexing from integer to pointer based
• enforced cursor switching
• restricted moveable objects to those owned by each player
• restricted moveable objects to those not being fried by a laser
• restricted object movement to when the player has sufficient power
  
• out of bounds collision detection for the cities
• status of cities
• mirror destruction
• mirror spawning
• All 4 buttons mapped and functioning.

The screen shot shows an energy bar for solar emitter and separately for the specific mirror at P1's cursor. Some of the P2 cities have been destroyed.

Oh, and I finally got around to moving the sun into ROM, freeing up about 100 bytes of RAM!

Next step: Designing Levels!

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.

Pitcher's Duel

Just a quick video clip in case anyone's curious.
I wouldn't dare review it since I'm British and therefore know nothing of Baseball. :p



Note this is not a Vectorzoa game-
Just a clip of the recently released Pitcher's Duel title launched at CGE2007.

Quick update

Hi folks, No updates in while, been a combination of work commitments and holiday over the last few weeks, and then finally this weekend just as I was limbering up for a Vectrex day.. serious back probs! :( Hopefully be back in the saddle for next weekend. The Eurocon release is in no danger.

Meanwhile though, my Pitcher's Duel finally arrived. Thank's to Sean for the black one and (a no doubt reluctant) Mayhem for my greenie! ;)

P.S. Looks like Blogger are now supporting movies, so expect some clips as things develop.

Day 7 - Improving Presentation

A productive session. Firstly as promised I improved the collision detection. The 3 frame pic above shows: (note the blazing sun!)

1. how bad it was
2. overzealous detection
3. just right
   

I added the parabolic reflector, I think it looks pretty cool. Note also how I have removed the collision clash zone boxes as I thought they were offending the eye. Of the two bars at the bottom the higher one shows "how hard" the Vectrex is working, clearly a good sign that we appear to be on about 60% remaining output at the moment




This final pic shows again the laser emitter and also three cities at the bottom, these will be Player One's lives. I'm not entirely happy with these at the moment so if anyone wants to offer a Vector sketch of a "missile command style" city then feel free to email me. I'm looking for something of less than 24 lines, preferably that can be drawn without taking your pen from the paper. :)


As you can see the cities have taken a fair bit of processing cycle to draw. (We're down to about 40% remaining.) I'll need to keep my eye on them.

Compiled code size 5785 bytes