They came to wreak Hell - 8 direction scrolling top down shooter - RELEASED

[team_disposable]

THE BLOBS WERE READY WHEN THEY INVADED OUR PLANET. WERE YOU?

They came to wreak Hell is Team Disposable's entry for the Nesdev 2022 competition.

They came to wreak Hell is a top down 8 directional scrolling shooter in which you defend earth* from the blobs.

6 levels, 2 endings, 5 different weapons, it should take about 20 minutes to half an hour to complete to get one ending.

You can download the post-nesdev, refined version here:

https://team-disposable.itch.io/they-came-to-wreak-hell

It uses my engine (the Disposable Engine** ) originally built for an improved version of my entry in to last year's Nesdev competition, Trouble at 2a03.

I built this one kind of quickly as my original project for the compo, Project DDDD, was a bit of a washout due to not being able to get the combat system working how I would have liked it, although I do hope to revisit it.

Due to its last minute nature the GUI etc weren't the greatest, and sound effects were disabled. I've released an improved version since, and am very happy with the result.

All music, graphics, level design etc are by me, with the engine uses a modified version of Shiru's excellent neslib, and an unmodified version of Famitone2. It's a mix of assembly and really horrible C, designed to coax the best I can out of CA65/CC65 while still being somewhat legible and modifiable, with additional import tooling and general glue holding it together written in python.

A whole bunch of other excellent community resources were used in its creation, like YY-CHR, NESST, NEXXT, CA65/CC65, tokumaru's LZSS packer/unpacker, Tiled, and I am sure some other bits and pieces I'm forgetting.

All criticism positive or negative is appreciated.

*well, an office and a car park
**you can probably see a theme forming here

wreak_hell_2(1).gif

wreak_hell_2.gif

wreak_hell(3).gif

wreak_hell(1).gif

[team_disposable]

BEHOLD

1671477845970.jpg

some cheap carts I had made.

1671477974691.jpg

Definitely NOT APPROVED BY NINTENDO - I'll sand that off later.

1671478002369.jpg

[matthughson]

That's awesome! What board are you using?

[team_disposable]

Yeah! I'm dead curious myself actually - they're from a Chinese Repro shop on AliExpress so I'm a bit scared they've got the 3.3 voltage kiss of death. Everyone who has a copy has been sufficiently warned!

It's the Unrom from my itch.io page, so it supports ch-ram, whatever it is!

[team_disposable]

Version 0.4 Friends and Lovers Edition released!

https://team-disposable.itch.io/they-came-to-wreak-hell

I've finished a few other projects recently and so had time to cycle back to this one.

New features -

-2 player mode
-Run ability - double tap and hold a direction to run
-Numerous bug fixes

Let me know if anyone has any issues etc.

Barring bugs, this might be the last update for this one.

[team_disposable]

Version 0.5 released.

New title, continue, control and between level screens. Some bug fixes, a few other bits.

In 2 player mode the players and their guis are drawn quite early so I do intend to go back sometime and unpick those writes and make them later in the chain, but that time is not today, friend.

Enjoy, or at least passively observe, Version 0.5.

https://team-disposable.itch.io/they-came-to-wreak-hell

[oRBIT2002]

I'm pretty jealous at people creating stuff like this! I wish I had the patience to do something aswell.

I have suggestion/idea, perhaps it's just a general observation for many NES-games..It's pretty common that the character moves in a constant speed during movement. It would be interesting to see the effect of moving the character at a non-constant speed during movement instead. I haven't tried this myself in anyway but it's just a theory.. Like... "move the character usually at 2 pixels per frame, but every 10 pixel move it one pixel instead".
I get the feeling that a few Mario games uses this "technique" (not sure), it feels more like the character is actually walking instead of more "floating"..
Hope you get what I mean.

Anyway, awesome work!

[tokumaru]

Like... "move the character usually at 2 pixels per frame, but every 10 pixel move it one pixel instead".
I get the feeling that a few Mario games uses this "technique"

This happens naturally in games that use sub-pixel movement, which most do. If you set an object's speed to 1.9 pixels per frame, 90% of the time its visible position will move 2 pixels, but 10% of the time it will move just 1.

[v.depatie]

Like... "move the character usually at 2 pixels per frame, but every 10 pixel move it one pixel instead".
I get the feeling that a few Mario games uses this "technique"

This happens naturally in games that use sub-pixel movement, which most do. If you set an object's speed to 1.9 pixels per frame, 90% of the time its visible position will move 2 pixels, but 10% of the time it will move just 1.

you can do that ? raster?

[tokumaru]

Of course, this is called "fixed-point math", and it's something you can do in any programming language for any console. You normally have 1 or 2 bytes representing the position of an object in pixel units, right? The idea is you extend that with another byte, but the difference is that this one represents sub-pixel values (i.e. fractional values smaller than 1):

A value of 1 ($01) means 1/256 (or 0.00390625) pixels. A value of 2 ($02) means 2/256 (or 0.0078125) pixels. A value of 128 ($80) means 128/256 (or 0.5) pixels. A value of 255 ($FF) means 255/256 (or 0.99609375) pixels.

This extra byte does not affect the visual position of the object, since the display works in whole pixel increments, but affects its logical position and allows you to move it in fractional increments.

To move objects in fractional increments, you also have to extend velocity values with a fractional part - when you add a displacement/velocity value to an object's position, just add the fractional part to the fractional part, and the whole part to the whole part, propagating the carry like you would in any other multi-byte addition.

Here's an example of adding an 8.8 (8 bits whole, 8 bits fractional) signed velocity to a 16.8 (16 bits whole, 8 bits fractional ) position:

Code: Select all

  clc
  lda VelocityXFraction
  adc ObjectXFraction
  sta ObjectXFraction
  lda VelocityXLow
  bpl AddPositive: ;branches if the velocity is positive
AddNegative:
  adc ObjectXLow
  sta ObjectXLow
  lda #$ff ;simulates a negative VelocityXHigh
  bmi AddHigh ;(always branches)
AddPositive:
  adc ObjectXLow
  sta ObjectXLow
  lda #$00 ;simulates a positive VelocityXHigh
AddHigh:
  adc ObjectXHigh
  sta ObjectXHigh

This way you can have velocities ranging from -128.99609375 (going left/up) to 127.99609375 (going right/down) pixels, in 0.00390625 increments. For display and collisions you can keep using just XLow and XHigh like normal, the fractional part is just to improve movement precision and smoothness.

Signed velocities are very convenient because you can easily do left/up and right/down motion using the same code.

[Quietust]

Effectively, that's just using 16-bit values for position/velocity and then dividing them by 256 to get the values in "whole pixels", since dividing by 256 is trivially easy when you're using an 8-bit CPU (you just ignore the bottom-most byte). You can even use larger values if you want (e.g. 24-bit values, where the upper 16 bits are "whole" and the bottom 8 bits are "fraction", then subtract "camera offsets" from them to yield 8-bit coordinates that fit on the screen [or skip them if they're offscreen]).

[Anna_TeamRocket]

you can do that ? raster?

I've tried to program the movement for the slope downwards, and keeping the same horizontal speed seemed a little bit too fast. While I know there are platformer games that just do it like that, it have crossed my mind to make the diagonal vector, make the horizontal speed moving at 3/5 instead of 5/5, which would mean that every three times a character moves to the side, while the animation is kept in the same sequence, player has to spend 2/5 frames idle. It would only move every other frame like this: left, stop, left, stop, left - and repeat.

[tokumaru]

For smooth movement in platformers, the velocity is usually not constant, instead it increases and decreases based on input and other factors.

If you press left or right on the controller, that should add a constant acceleration value to the velocity. You may want to limit how high the velocity can get in response to input, to prevent character from going too fast from that alone - just test if the velocity is already above a certain threshold before changing it. If no direction is pressed, add a deceleration value to the velocity, making it move towards 0.

The environment can also affect an object's speed - air and ground should have friction forces that decelerate them. If you make this value dynamic for different ground types you can easily implement surfaces like slippery ice by using a low fraction value or sticky floors by using a high friction value.

Slopes should also affect an object's speed based on their angle, always adding a (positive or negative) acceleration to the velocity.

[team_disposable]

I've updated this quite a bit since I last posted here:

https://team-disposable.itch.io/they-came-to-wreak-hell


v0.7 "Bouffant Edition"

-New explosions

-Restored items dropping from defeated enemies

-New weapon graphics

-New hair

v0.6 "I didn't say when"


-New assembly routines for faster gameplay in packed scenes

-Items and enemies no longer disappear during two player mode because of overlap


v0.5 "You can if you freeze it"

-New title screen

-New continue screen

-New between level screen

-New control screen

-Dedicated but bland ending screens

-Some other bug fixes as well.

-In two player mode there is an overlap issue because of the number of sprites on screen and the gui. It's perfectly playable, but some of the enemies you are fighting will disappear. A fix for this will be in the next release.