Jump to content
IGNORED

City Defence (WIP)


TwentySixHundred

Recommended Posts

25 minutes ago, Kaboomer said:

Question: Should rev number have a 3 in it instead of 2.... so "City Defence 20200301.bin" ( the 3 for March, not 2 for Feb)?

Correct, thanks for pointing that out it was a typo and the latest build. I have edited the post with correct rev number ?

  • Like 1
Link to comment
Share on other sites

6 hours ago, TwentySixHundred said:

New build!

 

Changelog:

  • bug - fixed screen roll / jitter
  • bug - improved alignment of warhead explosion sprite in accordance to warhead position
  • code  - cleanup and improved flow

 

Latest Build:

 

City Defence 20200301.bin 32 kB · 1 download

If any bugs are found please let me know, cheers ?

Latest HS with Build 20200301.  No screen rolls and the game played well. The spawning locations of the warheads has definitely improved throughout your revisions. I played 3 games and noticed that sometimes there's a bit of a pause between the flow of the missiles. I like it, as it builds anticipation (at least for me) during the game.

 

Btw, how about giving "double point value" for hitting two warheads with one missile? 

MD 2020-0301.jpg

Link to comment
Share on other sites

11 hours ago, sramirez2008 said:

Latest HS with Build 20200301.  No screen rolls and the game played well. The spawning locations of the warheads has definitely improved throughout your revisions. I played 3 games and noticed that sometimes there's a bit of a pause between the flow of the missiles. I like it, as it builds anticipation (at least for me) during the game.

 

Btw, how about giving "double point value" for hitting two warheads with one missile? 

MD 2020-0301.jpg

Thanks yes it determines whether a certain bit is turned on for each of the three warheads from a randomly produced 8bit integer. If that bit is active and the warhead is off screen it will run the randomize routine for the xpos (horizontal position). From there it will respawn the warhead back at the top of the screen for the next drop. The check is ran 60 times a second so most the time there isn't much of a pause as that condition is usually met faster then the player will notice. I agree it's nice when that pause happens every now and then for the player to catch a breath ?

3 hours ago, sramirez2008 said:

New high score 34,302 (my best, so far) while continuing to test build 20200301. 

Btw, in one of my prior games, I had a couple of top floors remain after the buildings had been hit (please see below).

 

MD_HS.jpg

 

Building Tops.jpg

Yeah this is an issue i was hoping to avoid without having to do further checks to the playfield (playfield checks are costly). It happens because i am using float variables (8.8 fixed point). Meaning as the speed of the missiles increases it's done by decimal percentages. So each wave it will increase the speed of warheads by 0.04% IIRC. It's all well and good till the speed gets beyond 1.50 as collision detection is done by single integers and not decimal. So depending on the warheads position, sometimes the next 1.50+ increments will skip a full integer. The end result is the missile will completely miss that playfield pixel leaving it behind. This is how i understand it and how i think bB works, unless someone who works on bB's background operations can correct me.

 

The only way i know to fix this is by making further checks if a lower pixel is removed then to remove that free standing pixel. Very costly though as it would need to be in the main loop so it appears instantaneous to the player. Reading and switching pfpixels on or off is cycle intensive. Sadly there is a high chance i won't be able to fix this issue due to limited space remaining in that bank and im trying to avoid bankswitching in the engine loop for performance reasons.

 

Having said that if i do find a lightweight way that uses little code then will be sure to add it ?

Link to comment
Share on other sites

7 hours ago, TwentySixHundred said:

The only way i know to fix this is by making further checks if a lower pixel is removed then to remove that free standing pixel. Very costly though as it would need to be in the main loop so it appears instantaneous to the player.

 

Maybe you can unconditionally turn the PF pixel above the target off when the collision first happens? Either there will be one there in cases where a whole integer is skipped, or there won't be, but you can save the cycles from checking, and there shouldn't be a case where turning off the one above the collision would be detrimental, I don't think?

Link to comment
Share on other sites

31 minutes ago, Karl G said:

 

Maybe you can unconditionally turn the PF pixel above the target off when the collision first happens? Either there will be one there in cases where a whole integer is skipped, or there won't be, but you can save the cycles from checking, and there shouldn't be a case where turning off the one above the collision would be detrimental, I don't think?

That could definitely work to ensure the above pixel is turned off if any collisions are made. I think it would be possible to add this to the collision code with a bit of experimentation.

 

This issue had me thinking earlier today and i also came up with another idea without the need to manually alter pfpixels, however not sure if it would work without testing.

 

The way i have it setup is there is two float variables, one for the 'warhead_y' position and it's default droprate. Then another to increment the speed called 'droprate'. So when wanting to increment the speed i increase the variable 'droprate' value by a percentage and add that to 'warhead_y' default value.

 

My theory is to lower 'droprate' value back to default when the collision is first detected thus giving it time to remove any pixels (integers) it would have missed. This will then eliminate the need for reading and writing pfpixels manually. This should be a small cost of some ROM and very little cycle loss (in theory).

 

At the same time i was thinking it would be a nice added feature slowing the droprate on collision to simulate the resistance from the buildings. As of the moment the warhead has no resistance and freefalls straight through the buildings like they're paper-mache.

 

The only issue i can see without testing is the chance the first pixel may still remain (hopefully not). I might have some time tomorrow to look into both ideas and see what i can come up with. Thanks for the advice, much appreciated ?

Link to comment
Share on other sites

New build! Ok so after some experimenting around i finally have managed to eliminated the issue of left over buildings. Using a hybrid of the Karl_G's idea and my own it seems to work fine, from what i have tested. The idea i had of slowing the warheads to simulate building resistance worked however it caused another bug. Mainly due to the way i have things coded - down the track i may look into rewriting that code block. For now everything works as intended unless anyone can break the game ?

 

Changelog:

  • bug - pfbuildings - collision detection

Latest Build: City Defence 20200302.bin

 

Like usual any bugs please let me know - enjoy ?

  • Like 4
Link to comment
Share on other sites

14 hours ago, sramirez2008 said:

Collision detection appears to be working well?  No bugs to report.

20200302_HS.jpg

I have to say that score is truly impressive, i was spending some time tonight trying to atleast get close. Best i could get was 22,332 i have also noticed i tend to feel vulnerable and start to panic once losing the powerstation. Really makes the player cautious of venturing out too far from the inner city. Feels like my outer burbs just get hammered as i haven't the range to defend them whilst guarding the maingun.

 

646528703_CityDefence20200302.thumb.png.53e13e839bf4fac2d6f4abae7ada380d.png

  • Like 1
Link to comment
Share on other sites

10 hours ago, Karl G said:

I played a bit on my Jr. via my Harmony cart, and I didn't encounter any glitches that I noticed. It's definitely not an easy game for me, though.  ? 

Thanks for testing it out Karl and confirming all is good on a JR aswell ?. I have been using a gamepad or keyboard with Stella and sramirez2008 i think is using a short throw joystick. Im assuming you maybe using a cx40 which probably has a longer throw and maybe making it harder. If i had hardware i would test to see if the gamepad is easier then a cx40, either way it does get hard after about 10-15k.

 

Also losing the powerstation makes the player alot more vulnerable especially when the warheads get fast. Best tactic i have found, is to save as many buildings during the early stages for bonus points and wipe out as many warheads as possible. Later stages i try just looking after the inner city, maingun and powerstation when possible. Still gets extremely hard though

3 hours ago, sramirez2008 said:

New personal HS (34,426).

 

FC23351E-E529-44F5-B7EB-0156512F521C.jpeg

Nice work i can only imagine how fast those warheads are traveling around the 30k mark. As of the moment there is no cap on the increase of speed so the warheads will just get faster until it breaks the player. I have been contemplating whether to add a speed cap so it's always possible to hit the warheads and fair. So it becomes an endurance thing waiting for the player to make the wrong decision or lapse in concentration. Not sure if that would be a preferred gameplay method and more of a skill based thing?

 

I really should implement a wave display during the intermissions in replacement of "ready" so i can calculate at what wave it starts becoming unfair and breaks the player. Judging by your hi-scores im thinking after the 30k mark is starting to get pretty extreme ?

Edited by TwentySixHundred
Link to comment
Share on other sites

3 minutes ago, TwentySixHundred said:

Im assuming you maybe using a cx40 which probably has a longer throw and maybe making it harder.

Nah; I'm using a generic Sega-compatible gamepad. It's just hard for me because I'm not any good at it so far.  ;-) . I think maybe I'd do better if the target moved more slowly, although that also has its disadvantages.

  • Like 1
Link to comment
Share on other sites

12 minutes ago, Karl G said:

Nah; I'm using a generic Sega-compatible gamepad. It's just hard for me because I'm not any good at it so far.  ;-) . I think maybe I'd do better if the target moved more slowly, although that also has its disadvantages.

That makes sense, just need more practice ? Yeah agreed slowing the target is a disadvantage during the later levels as the warheads move so fast you need that speed ?

7 minutes ago, sramirez2008 said:

Yeah, I’d really like a wave counter. I’m pretty sure that last game was the most waves I’ve reached yet. The warheads were really raining down on me during the last few waves.

 

I’m using a Suncom Slik Stik.

Yep, i have been running it through my head on the best way to tackle this. Wave intermissions could display the new wave number which should work and i am hoping i can do the same at the gameover screen. There is a background wave counter so half the code is in place, it's just a matter of adding the sprites, placement along with a sub-routine to fetch that data.

  • Like 1
Link to comment
Share on other sites

New Build!

Ok so i have implemented a wave counter and the original plan i hit the abort switch on. For the cost of one variable and a small amount of ROM i decided that utilizing the existing score as a counter would be the smarter choice. This also gave me an excuse to implement a programming feature "the stack" because why not it's free storage :). Any reason i have to use extra features that can benefit by saving resources i will jump on it. Personally i think it was the better choice and like the way it turned out.

 

So during the "ready" screen (wave intermission) the score will display the wave number until back in game then revert back to the players score. On the gameover screen the score will alternate between wave number and your final score every two seconds. I can also change the colour of the score when displaying the wave number and have it revert back for the final score.

 

Changelog:

  • wave display - alternating wave number to score

 

Latest Build: City Defence 20200304.bin

 

As usual please report any bugs and or feedback as it's always helpful to know what others have found or suggest ?

  • Like 1
Link to comment
Share on other sites

5 hours ago, sramirez2008 said:

Hope to see this on a cart. I think the title screen would make an excellent label?

Would be great to see this as a physical release however i haven't the resources to do so. As it's DPC+ i would need help from the AA community and Albert for a cart release. I am also not the best when it comes to box art and manuals so would have to contact someone on AA who is whiling and knows what they're doing.

Link to comment
Share on other sites

15 minutes ago, Keatah said:

Why not have two versions. Selectable with GameSelectSwitch or Difficulty a/b. One where the game increases speeds till the player breaks. And one where endurance is key.

 

That's always a possibility i was actually thinking of having two difficulty settings, one for those who don't mind slowly making their way way through the waves. Another for those who want hard and fast gameplay so once they have their skills up, the difficulty is there from the get go ?

Link to comment
Share on other sites

So here is a test build with a feature i have been holding off on. Reason being it uses my last virtual sprite, some ROM and another variable. However i like the idea even though it's more for aesthetics rather then practicality. If i keep this feature im using some valuable space within the mainloop bank. I haven't much room ATM unless i can go through and have a clean up of any redundant code i can find.

 

So from what i had (590 bytes) i have used (320bytes) to add this feature leaving me with 270bytes remaining. I still have plenty in other banks but as this feature runs during the mainloop i have a rule of no bankswitching during gameplay for optimization. Like i said if i can swap some unnecessary code around and maybe rewrite some blocks it may free up some space. In hindsight the cost really isn't all that much it's just i haven't much left anyway.

 

Anyway enough of all that and more to the point, i guess i am asking for responses of whether others like this feature? Do you think it's worth it and does it make the game feel more rewarding? Does it suit this sort of game? Is it just annoying? Check out the ROM and if you can let me know that would be much appreciated.

 

Changelog:

  • on-screen score display - after destroying a warhead the score reward is displayed for a moment (sort of like Galagon)

Latest Build: City Defence 20200305-test.bin

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...