It's been a couple of days since my last update so I thought I'd give you guys an update.
It doesn't feel like I've done so much lately, but I have done some stuff...so it's not like I've been completely laid back. :lol:
I've implemented lives and level counters and have them placed (as I said I would) in the top right corner of the screen.
There's also now collision detection between the enemies and the player and you can lose a life which will give you an intermission sceeen and then continue the game...or give you a game over screen if it was the last life.
Last score is also being checked against the highscore and all that.
So, all in all, nothing too exciting...but nevertheless things that needs doing.
The flickering is starting to annoy me, but I haven't looked into that yet - for now I just want the game to work...and hopefully be fun too - and then I'll look into that once those things are in place.
The next thing I'll be looking at is probably going to be the pathfinding for the enemies.
I've been working on the pathfinding for the enemies today and I've almost got it working. I'm a bit tired now but I'll work some more on it tonight and hopefully get it finished then, so that's a really big thing (almost) out of the way.
I'm only three weeks into the project at this point, and there's still lots of tweaks to be done - especially to that pesky sprite routine, so it'll be a little while yet before it's finished. But it's coming along nicely and it shouldn't be that long.
Visually it still looks the same. I got the first batch of graphics from Mark yesterday,but I haven't imported them into the game yet. I think I'll wait until I have a bit more. ;)
I'll post more pictures once I've got some new fancy graphics to show. :D
Lots of progress being made, but for now I'm agonizing over some code and I'm not too proud to ask for help if it shortens the time I have to spend working on it. :lol:
So...
The bit that is giving me problems are calculating when and where the enemies should be able to shoot. It's a problem in two parts.
Facts: I have the player and the enemies. And some items that the enemies can shoot at the player. All have X&Y coords and all entities are 16x16 pixels.
Objective: I'd like my enemies to be able to shoot at the player if the player is between 8 pixels above the enemy or 8 pixels below the enemy. In other words - mostly lined up, but not necessarily exactly lined up with it. Vertically and horizontally.
However, the even more tricky part is that the enemies has to be able to shoot only while lined up with the corridors so I don't get items flying across the tiles.
This is an example;
Notice the white fish to the right of the player? Currently the enemy will shoot at the player if they're on the same X or Y coord, and in this case the enemy on the right lined up with the player on it's way up, and fired at it. The result: a flying item that moves outside the 'corridors' and over the level-tiles. That's no good.
And very importantly (although it can be read from the picture above) - the enemies should only be able to shoot at 32 pixel intervals (although there's an 8 pixels offset on the X axis and 24 pixels on the Y axis).
So the enemies has to fire only at certain coords in one axis while being able to shoot always on the other axis. And reverse. But again...that's not always. *sigh* Damn..I can hardly descibe it. :lol:
It seems easy (the first part anyway), but...it's really doing my head in. Of course all this is because I'm allowing the enemies to fire at the player in any direction - even in the opposite direction of where it's moving. :-(
Now, how the beep do I fix this. Can I fix it? Even the first part should be real easy to do, but it is my first project after all and I'm drawing a blank.. ;)
...or should I just limit the enemies to only being able to fire in the direction they're moving?
That'll check to see if the sprite is on a 32-pixel boundary position, and if not, exit your subroutine. If the top of the play area is not exactly aligned to that grid, you may ADD or SUB the offset first. But personally I'd have all the co-ordinate systems use 0,0 as the corner of the play area, and just offset them to the right screen locations in your sprite routine.
Given that there's so much fruit in the horizontal rows, having enemies only fire horizontally along the clear alleys probably looks better anyway.
That'll check to see if the sprite is on a 32-pixel boundary position, and if not, exit your subroutine. If the top of the play area is not exactly aligned to that grid, you may ADD or SUB the offset first. But personally I'd have all the co-ordinate systems use 0,0 as the corner of the play area, and just offset them to the right screen locations in your sprite routine.
Given that there's so much fruit in the horizontal rows, having enemies only fire horizontally along the clear alleys probably looks better anyway.
Thanks guys,
But, heh, that little piece of code is basically what I have already ;), but it's those offsets that's screwing things up for me. I'll work some more on trying to get it to work before changing things to use 0,0 as the corner.
Technical question:
I've gotten my enemies running around now...currently 4 of them (but only one line needs to be changed to allow less or more). So far they're just following simple up/down or left/right paths, but I need them to navigate the labyrinth, but the question is: what would be the most efficient way of doing that on a Spectrum?
I can think of several ways of doing it.
A* (A-star pathfinding) which I've used on several PC projects - including Dingo, but that's not good for a Spectrum program.
Have them randomly chose if they want to change direction everytime they get to a junction. Not too crazy about this...it's never been satisfactory to do it this way for me earlier (therefore A*).
Code in a bunch of routes and waypoints and then have the enemies jump between them.
I'm not a big fan of any of them (but y'know..whatever it takes ;)).
Anyone got some better ideas? ;)
In WorldBar, the arcade version I have the computer calculate the path to the right place. On each junction, based on the difficulty (n), the computer takes the right step (n/4 times) or a random move ( (4-n)/4 times). Works fine for me!
Haha, not needed anymore though. Mark has redrawn all the fruits and here's how they're looking.
I've solved part of my problem with the flying items, so they will now only fly along the clear alleys.
It was solved quite easily with a SBC A,8 (or 24) before each AND instruction. Easy as pie. :lol:
...amazing what a good nights sleep can fix. :D
I still need to make that "shoot anyway, if not quite lined up" function work, and still have them shoot only inside the clear alleys, but one problem at the time. :)
You don't know how chuffed I am that these graphics have gone in. These are the first Spectrum graphics I've done since when I worked on 'total recall' in 1990/91. Glad you like them, it responses like that that can only go towards encouraging me to do more. I was so nervous that I just wouldn't be able to do it again!
You don't know how chuffed I am that these graphics have gone in. These are the first Spectrum graphics I've done since when I worked on 'total recall' in 1990/91. Glad you like them, it responses like that that can only go towards encouraging me to do more. I was so nervous that I just wouldn't be able to do it again!
Haha, not needed anymore though. Mark has redrawn all the fruits and here's how they're looking.
I've solved part of my problem with the flying items, so they will now only fly along the clear alleys.
It was solved quite easily with a SBC A,8 (or 24) before each AND instruction. Easy as pie. :lol:
...amazing what a good nights sleep can fix. :D
I still need to make that "shoot anyway, if not quite lined up" function work, and still have them shoot only inside the clear alleys, but one problem at the time. :)
Beautiful graphics there. Looking forward to this. Top work guys. (also probably fairly different to wizball and total recall!).
I think Whinberries & gooseberries are very underrated, perhaps if there's room in a 128k version? ;-)
You don't know how chuffed I am that these graphics have gone in. These are the first Spectrum graphics I've done since when I worked on 'total recall' in 1990/91. Glad you like them, it responses like that that can only go towards encouraging me to do more. I was so nervous that I just wouldn't be able to do it again!
I hope you would instead, if you manage to come up with something like this :) Great work indeed.
I'd like my enemies to be able to shoot at the player if the player is between 8 pixels above the enemy or 8 pixels below the enemy. In other words - mostly lined up, but not necessarily exactly lined up with it. Vertically and horizontally.
A little more progress. I've decided to drop the above. When I'd finished making the items fly only along the clear corridors, I realised that combining that with the above would be counterproductive and make things needlessly complicated. In the arcade version the enemies only shoots while fully inside the corridors anyway.
Besides, the main reason for wanting to implement that inaccuracy when the enemy shoots, was to make it harder, but I think it's plenty hard as it is. Okay, so the enemies has unlimited ammo right now - which they of course won't have for much longer - but I think it'll work just fine once the enemies has to pick up items themselves before being able to shoot.
...and that's the next thing I'll be implementing - the last major thing that needs doing - having the enemies stop up and stomp on a fruit to pick it up, and getting their ammo that way.
I also have collision checks between shots fired by the player and shots fired by the enemies, done now.
Not really - the 'blackcurrant' sprite looks great, like a small bunch of blackcurrants.
A 'blackberry' needs to consist of lots more smaller round bits.
Yay, today is a good day. Not only is it exactly one month since I started this project, but I also have an almost complete game - which is more than I ever expected to have in this short amount of time (still lots of work to be done though..and still hoping for someone to do some music for me, too). ;)
And if that wasn't enough, I just got the animations for the koala, from Mark, a little while ago, and they look really great.
...he's still got it. ;)
The function I'm working on at the moment is screwing ingame things up a bit, so here's a picture of the intro - showing off one of Mark's frames for walking right. Isn't he cute? :)
..I presume by music, you mean something AY related rather than beeper (we talking ingame, right?)... Were you thinking of a copy of the arcades "music" (I use that term broadly, of course) or wanting something more sophisticated?... Cos, if you wanted the original, then maybe any ol' tom,dick & harry could contiribute, but if wanted something more like MUSIC (you know, REAL music), then your gonna have to shout a bit louder, or drop some more explicit hints, or... heck... just target some talented musician-type WOSers here...
(sorry, Im in the talentless "tom,dick & harry" category!) [Id love to hear something ground breaking for a game like this... ANY TAKERS OUT THERE???]...
:grin:
Comments
Pain?...LOL, don't worry - it takes a bit more than that. :lol:
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
It doesn't feel like I've done so much lately, but I have done some stuff...so it's not like I've been completely laid back. :lol:
I've implemented lives and level counters and have them placed (as I said I would) in the top right corner of the screen.
There's also now collision detection between the enemies and the player and you can lose a life which will give you an intermission sceeen and then continue the game...or give you a game over screen if it was the last life.
Last score is also being checked against the highscore and all that.
So, all in all, nothing too exciting...but nevertheless things that needs doing.
The flickering is starting to annoy me, but I haven't looked into that yet - for now I just want the game to work...and hopefully be fun too - and then I'll look into that once those things are in place.
The next thing I'll be looking at is probably going to be the pathfinding for the enemies.
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
I've been working on the pathfinding for the enemies today and I've almost got it working. I'm a bit tired now but I'll work some more on it tonight and hopefully get it finished then, so that's a really big thing (almost) out of the way.
I'm only three weeks into the project at this point, and there's still lots of tweaks to be done - especially to that pesky sprite routine, so it'll be a little while yet before it's finished. But it's coming along nicely and it shouldn't be that long.
Visually it still looks the same. I got the first batch of graphics from Mark yesterday,but I haven't imported them into the game yet. I think I'll wait until I have a bit more. ;)
I'll post more pictures once I've got some new fancy graphics to show. :D
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
So...
The bit that is giving me problems are calculating when and where the enemies should be able to shoot. It's a problem in two parts.
Facts: I have the player and the enemies. And some items that the enemies can shoot at the player. All have X&Y coords and all entities are 16x16 pixels.
Objective: I'd like my enemies to be able to shoot at the player if the player is between 8 pixels above the enemy or 8 pixels below the enemy. In other words - mostly lined up, but not necessarily exactly lined up with it. Vertically and horizontally.
However, the even more tricky part is that the enemies has to be able to shoot only while lined up with the corridors so I don't get items flying across the tiles.
This is an example;
Notice the white fish to the right of the player? Currently the enemy will shoot at the player if they're on the same X or Y coord, and in this case the enemy on the right lined up with the player on it's way up, and fired at it. The result: a flying item that moves outside the 'corridors' and over the level-tiles. That's no good.
And very importantly (although it can be read from the picture above) - the enemies should only be able to shoot at 32 pixel intervals (although there's an 8 pixels offset on the X axis and 24 pixels on the Y axis).
So the enemies has to fire only at certain coords in one axis while being able to shoot always on the other axis. And reverse. But again...that's not always. *sigh* Damn..I can hardly descibe it. :lol:
It seems easy (the first part anyway), but...it's really doing my head in. Of course all this is because I'm allowing the enemies to fire at the player in any direction - even in the opposite direction of where it's moving. :-(
Now, how the beep do I fix this. Can I fix it? Even the first part should be real easy to do, but it is my first project after all and I'm drawing a blank.. ;)
...or should I just limit the enemies to only being able to fire in the direction they're moving?
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
I'd do it in following steps:
1.Check if enemy is enemy is at good position for shooting
If not -> END
You can do it with something like:
LD A,(EnemyX)
LD B,A
AND 11100000b
CP B
to check if enemy is at "equal" position (your 32 pixels intervals)
2. Check if player pos-8<enemy pos<player pos+8
If not ->END
Easy:
- subtract 8 from enemy X, compare to player X, RET if not carry
- add 8 to enemyX, compare to player X RET if carry
3. Test which direction should bullet go by comparing the second Y coordinate. Store that direction.
By the way you don't need to write 2 different subroutines for bullet going left and right as you may do:
LD A,(BulletSpeed)
LD B,A
LD A,(BulletPos)
ADD A,B
Set speed to 1 for going right and 255 for going left - adding 255 is the same as subtracting 1 if we ignore carry
And my final advice:
If coding it all seems hard, make the enemies shoot only horizontal or vertical bullets first.
You'll later discover that for bullets going in another dimension you'll be able to reuse about 95% of your code, just by changing some variables.
AND 31
RET NZ
That'll check to see if the sprite is on a 32-pixel boundary position, and if not, exit your subroutine. If the top of the play area is not exactly aligned to that grid, you may ADD or SUB the offset first. But personally I'd have all the co-ordinate systems use 0,0 as the corner of the play area, and just offset them to the right screen locations in your sprite routine.
Given that there's so much fruit in the horizontal rows, having enemies only fire horizontally along the clear alleys probably looks better anyway.
- IONIAN-GAMES.com -
Thanks guys,
But, heh, that little piece of code is basically what I have already ;), but it's those offsets that's screwing things up for me. I'll work some more on trying to get it to work before changing things to use 0,0 as the corner.
I'll let you know how I get on with it. :)
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
In WorldBar, the arcade version I have the computer calculate the path to the right place. On each junction, based on the difficulty (n), the computer takes the right step (n/4 times) or a random move ( (4-n)/4 times). Works fine for me!
I've solved part of my problem with the flying items, so they will now only fly along the clear alleys.
It was solved quite easily with a SBC A,8 (or 24) before each AND instruction. Easy as pie. :lol:
...amazing what a good nights sleep can fix. :D
I still need to make that "shoot anyway, if not quite lined up" function work, and still have them shoot only inside the clear alleys, but one problem at the time. :)
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
Yeah, don't they. It's his shading that does it. On the Speccy shading is the key to greatness. :D
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
Ex-Ocean Software graphic artist -
Download my FREE PDF 'LOAD DIJ DIJ' (180,000+ words): https://ko-fi.com/i/IG2G3BEJZP
ZX Art page: https://zxart.ee/eng/authors/m/mark-r-jones/
https://twitter.com/MarkRJones1970
https://www.facebook.com/OceanSoftwareLtd/
https://www.facebook.com/ultimateptg/
Games List 2016 - Games List 2015 - Games List 2014
Beautiful graphics there. Looking forward to this. Top work guys. (also probably fairly different to wizball and total recall!).
I think Whinberries & gooseberries are very underrated, perhaps if there's room in a 128k version? ;-)
- IONIAN-GAMES.com -
Ex-Ocean Software graphic artist -
Download my FREE PDF 'LOAD DIJ DIJ' (180,000+ words): https://ko-fi.com/i/IG2G3BEJZP
ZX Art page: https://zxart.ee/eng/authors/m/mark-r-jones/
https://twitter.com/MarkRJones1970
https://www.facebook.com/OceanSoftwareLtd/
https://www.facebook.com/ultimateptg/
Hah, luckily that's one of the easier bugs to fix. :-P
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
A little more progress. I've decided to drop the above. When I'd finished making the items fly only along the clear corridors, I realised that combining that with the above would be counterproductive and make things needlessly complicated. In the arcade version the enemies only shoots while fully inside the corridors anyway.
Besides, the main reason for wanting to implement that inaccuracy when the enemy shoots, was to make it harder, but I think it's plenty hard as it is. Okay, so the enemies has unlimited ammo right now - which they of course won't have for much longer - but I think it'll work just fine once the enemies has to pick up items themselves before being able to shoot.
...and that's the next thing I'll be implementing - the last major thing that needs doing - having the enemies stop up and stomp on a fruit to pick it up, and getting their ammo that way.
I also have collision checks between shots fired by the player and shots fired by the enemies, done now.
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
Ex-Ocean Software graphic artist -
Download my FREE PDF 'LOAD DIJ DIJ' (180,000+ words): https://ko-fi.com/i/IG2G3BEJZP
ZX Art page: https://zxart.ee/eng/authors/m/mark-r-jones/
https://twitter.com/MarkRJones1970
https://www.facebook.com/OceanSoftwareLtd/
https://www.facebook.com/ultimateptg/
A 'blackberry' needs to consist of lots more smaller round bits.
- IONIAN-GAMES.com -
I've switched the two items around and it looks a little better too.
...it's still the same ones, though. :)
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
......
is it ready yet?
.....
is it ready yet?
I can keep this up all day y'know ;)
Ex-Ocean Software graphic artist -
Download my FREE PDF 'LOAD DIJ DIJ' (180,000+ words): https://ko-fi.com/i/IG2G3BEJZP
ZX Art page: https://zxart.ee/eng/authors/m/mark-r-jones/
https://twitter.com/MarkRJones1970
https://www.facebook.com/OceanSoftwareLtd/
https://www.facebook.com/ultimateptg/
And if that wasn't enough, I just got the animations for the koala, from Mark, a little while ago, and they look really great.
...he's still got it. ;)
The function I'm working on at the moment is screwing ingame things up a bit, so here's a picture of the intro - showing off one of Mark's frames for walking right. Isn't he cute? :)
Enjoy. :D
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
(sorry, Im in the talentless "tom,dick & harry" category!) [Id love to hear something ground breaking for a game like this... ANY TAKERS OUT THERE???]...
:grin:
- IONIAN-GAMES.com -