Mode 2 - Would a decent vector game be possible such as Asteroids , StarWars

[Puresox]

What is the feasibility of A Good Vector game in Mode 2 . Such as Asteroids , or Star Wars .Could someone explain The draw backs and Positives with this?

[TFM]

Well, IMHO, Mode 1 would be a better choice (square pixel), for example Starglider.
BTW. the Bollawares did some gamen in Mode 2.

[Puresox]

I wondered whether you could get faster action in this mode ?

[TFM]

You can use sprite routines which are much faster. And yes, I mean that masked stuff that can move over the background

So yes, you can get faster action.

[db6128]

Although the gain in speed is somewhat counterbalanced by the fact that you have to plot twice as many pixels to get the same width as in MODE 1. 

But it's a nice idea that I would like to see. Surely it's been done at least once on the CPC?

[MacDeath]

Vectrex emulator on CPC ? Wow...

[TFM]

Although the gain in speed is somewhat counterbalanced by the fact that you have to plot twice as many pixels to get the same width as in MODE 1. 

Ah no. If you would plot single pixels to plot a sprite, then you could make coffee between two frames 

It's done byte oriented, so it doesn't matter which Mode is set, because the width on screen is always the same.

[db6128]

Sorry, of course it is; what was I thinking?  Somehow I didn't factor in the added bytes required to encode colours in the other modes.

And I definitely wouldn't think about plotting one pixel at a time—even the fairly fast plotting routines I've coded take a long time to fill a screen, so yes, plenty of time for beverages.

[Optimus]

Ah no. If you would plot single pixels to plot a sprite, then you could make coffee between two frames 

It's done byte oriented, so it doesn't matter which Mode is set, because the width on screen is always the same.

I though he was talking about the line drawing routine and not the sprite routine.

[TFM]

No, (see his post before), but even drawing a line is much more easy in Mode 2, because you don't have to care about different colors (equals bit patterns). It's much more easy to set a bit instead of setting a bit pattern of a byte, when having nice routines for that especially

However two colors is not much, if you work with shades and different colors in different parts of the screen it can become a great game though

[Puresox]

It would be nice to see games like Tempest , Star Wars , Empire Strikes Back , which are great games in mode 1 but you can only go so far until the frame rate gets so sluggish that it makes the game unplayable, A nice fast Tron lightcycle game would be good also , with intelligent computer opponents.Take note any 16K developers  !

[TFM]

AI in 16 KB...  ... 

[Puresox]

  Was I  being over ambitious! Nevermind I am not a programmer. How much would you need to Incorporate reasonable AI in a Light Cycle game? Enjoy your Mock Doc! And give us some knowledge when you've finished.
I was bearing in mind , A light cycle game was developed which was  impressive on a BBC Micro. And plus the fact i am hoping that someone would think of random events within the game that would be supplementary, to computer AI.  [size=78%] [/size]

[Puresox]

I realise this has little to nothing to do with AI
Just wanted to show a 16K game which looks fairly impressive

[MacDeath]

not sure "vector graphic is that usefull on a much sich as the CPC which is completely bitmaped graphic mode.
I guess the Z80 being better than a 6502 at 3D could help?

Race car games used a few "vector" style tricks to get the road curves.
But I don't think Another World could be easily done on a real 8bit.


Vectrex uses an 1.5 MHz 68A09 (a 6809 but at faster clock).
The Thomson 8 bit MO/TO computers used a 6809E(1mhz only.
I've heard this 6809 is quite a good CPU for its time, quite better than the 6502, this 68a09 could most probably compete with a Z80B (the one at 6mhz).

[MaV]

AI in 16 KB...  ... 

For a lightcycle game that should not be much of a problem, as game AI does not equal AI as a branch in computer science. Game AI is much simpler.
Games basically just have a couple of rules of thumbs that determine how the computer player behaves; like: If your machine is ahead of a player's make a turn to his side to cut his path. That may already work effectively in a few hundred bytes. I'd be more worried about computational time, as ideally it has to fit in the time frame in which a screen will be updated.

[Sykobee (Briggsy)]

For a lightcycle game that should not be much of a problem, as game AI does not equal AI as a branch in computer science. Game AI is much simpler.
Games basically just have a couple of rules of thumbs that determine how the computer player behaves; like: If your machine is ahead of a player's make a turn to his side to cut his path. That may already work effectively in a few hundred bytes. I'd be more worried about computational time, as ideally it has to fit in the time frame in which a screen will be updated.

Annoyingly the simplest light cycle AI pretty much makes an unbeatable opponent - the AI being "is there a wall ahead of me? Yes - choose a random direction to turn".


However you could have an AI that splits the screen up into 1/16s or something, and assigns a weight to each one based upon player occupation, and then tries to aim the cycle at low occupation areas and away from high occupation areas.

[MaV]

Annoyingly the simplest light cycle AI pretty much makes an unbeatable opponent - the AI being "is there a wall ahead of me? Yes - choose a random direction to turn".

That makes for a pretty frustrating game, yes. The rule itself can be "softened" somewhat if it's connected to a few other simple rules. Say, for example the cutting rule above leads to the AI being "distracted". He also must not be distracted three pixels before a wall to make a proper turn. If he has been, he will crash into it. The cutting rule itself is activated whenever a player is very close. Combine that with perhaps a few other conditions and the AI will behave more human-like. And of course, the rules and their interactions need to be tested a lot. The next step forward would be to implement a proper finite state machine.
Since a lightcycle game is not graphics intense this still might be possible with 16k.

However you could have an AI that splits the screen up into 1/16s or something, and assigns a weight to each one based upon player occupation, and then tries to aim the cycle at low occupation areas and away from high occupation areas.

That's a good one!

[Gryzor]

Vectrex uses an 1.5 MHz 68A09 (a 6809 but at faster clock).

Not sure why you're comparing with the Vectrex (I've got one, along with the Multicart, I just love that machine). Maybe there *is* some meaning in it, that I don't understand, but I'd expect that using a purely vector monitor has some advantages over vector 'emulation'...

[TFM]

Was I  being over ambitious! Nevermind I am not a programmer. How much would you need to Incorporate reasonable AI in a Light Cycle game? ...

Well, first the 16 KB are not used up by the AI, I did express that wrong. But if you have a whole game inside 16 KB then this may not leave much RAM for AI.

Well 2 (hehe, couldn't resist ), a pseudo AI which is based a bit on accident and a bit on 'move closer to opponent' and a bit on 'turn right / left if you approach a wall can be put into few KBs.
But a real AI which is able to follow a strategy - especially favorable on a Tron grit - takes definitely some more KBs.
Just imagine who much questions an AI has to pose every 'cycle' or 'turn', and how to integrate all that answers, and how to do it in an hirarchy (which you need, to make decidions), then you have different ways to react. Now he AI has to plan a bit ahead of time... Well, there is no end.

I did an AI for my Giana Sisters, but then I took it out of the game and saved a looooot of KBs that way.
And this AI was a real simple one though

[TFM]

... this 68a09 could most probably compete with a Z80B (the one at 6mhz).

Yes it can try and loose

[TFM]

For a lightcycle game that should not be much of a problem, as game AI does not equal AI as a branch in computer science. Game AI is much simpler.
Games basically just have a couple of rules of thumbs that determine how the computer player behaves; like: If your machine is ahead of a player's make a turn to his side to cut his path. That may already work effectively in a few hundred bytes.....

No, that's not that easy, think it thoroughly. To take your example, it's not only to cut off the player, it's also:
- Is there another player?
- Is there a wall?
- Is there a trace of the player or myslef?
- Is there the end of the grit?

Now integrate all that data and calculate a strategy. If you can do that in few hundred bytes you get the price

But however, we've been talking about an AI, but we also see it's getting complicated quite quick.

[MaV]

Now integrate all that data and calculate a strategy. If you can do that in few hundred bytes you get the price

By the time I wrote the second post, I was already thinking in kbs.

Seriously, a lightcycle game is not a resource-hog, so if the game needs a generous 10kb, you'd still be left with 6kb for the AI, and that would make the game much more interesting (Those numbers are of course pulled out of my derrière, so who knows how much it'll actually be.)

[TFM]

Well, I see... the question here is when do you start to call something an AI. Or let's say how much IQ points are needed

Actually it would be a cool project to code a multiplayer (maybe 4 gamers...) TRON grit game and all the players are AI's.

So everyone of us has ... let's say..... 8 KB of RAM and .... 10.000 ys for calculatons.

And the game is played by four AI's. So we let them fight for us.

I could do a simple game and define how the AI has to interact with the game. But then we would need some volunteers to write AI's. An AI contest 

[steve]

Beware the birth of Skynet!