nesdev.com

Well its not a 4K game, its a 16K game I was trying to cut down to 4K, so yeah complexity was increased by me going for extreme optimisations. Doing it the normal way and its not very hard at all.

why do all of your scenarios start with this?

I'm thinking that the idea is actually to reduce complexity, by writing more generic subroutines?

My own 4KB game does this, with a single subroutine for updating every "object" used in the game. (player/monsters/items)
The code is small, cycle-efficient, and only omits bullets, that instead use crude angle calculations.


I would assume that this has to do with the fact that the 6507 (a feature-cut 6502), has no interrupts. (No pins for NMI/IRQ)

What the heck system is that? I counted about 40 tiles accross.

Wait nevermind, I looked it up and its a minigame in Splatoon.

C64
The screen is 320 pixels so 320/8 = 40 chars/tiles

I mean, it originally was. However, it looks noticeably different (for some reason, I couldn't find any native resolution images, but the Wii U Gamepad's 854x480 resolution is stupid anyway):




Yeah, he must have not been thinking there... I would make a list if there weren't 10's (probably over 100 including arcade boards) that used this resolution.

I see that a video was made for this demo: https://www.youtube.com/watch?v=TfQGcfEFOJk (this is the original Wii U version if anyone is curious: https://www.youtube.com/watch?v=sb0uezlTpxA)

I don't mean to be a jerk, but was the change in physics due to the reduced code size, because you couldn't figure out how to get the physics right regardless of size, or do you just not see anything wrong with it? You appear to hang in midair for a second in the C64 version.

1.) because I'm too lazy/stupid to remember the Background: clause which would allow me to do it once per file.
2.) because the 6502 part of the BDD is implemented on top of BDD, and my Java is not good enough to understand how to subclass it into a new jar file that I can then tell the BDD engine to use instead of the normal 6502BDD, and I would rather just copy-paste it than deal with Java.
3.) The original Java 6502 emulator used by 6502BDD did its best to run at 1Mhz for Accuracy, to which I made a mod. So you have Given I have a simple 6502 system and Given I have a simple overclocked 6502 system. Ideally I would also add a complex 6502 with VIC-II, or complex 6502 with CIA 1 that emulate various logic features. There is also another type of 6502 system build in with the emulator that has 6445( 48? I think it, something like that ) text CRT controller chip
4.) BRK is a standard 6502 opcode and hence it is from an emulators point of view, safe to do. However in 99.9% of cases you don't want to BRK and since RAM is filled with 00 in the emulator if I get a wrong index into my "On X" code then it will end up in BRK land, to which the emulator will just happily enter a infinite BRK loop. So I have this to say as soon as it happens, stop.

When you compress inline actually saves you memory, is some cases. as

JSR Thing <- 3 bytes

JSR Thing <- 3 bytes

Thing
RTS <- 1 byte

If you inline you save the 2 JSRs and the RTS, to which the compressor will notice the duplication and generally store it in less bytes. I've also done really backwards things like
LDX #4
STA Thing,x
STA Thing+4,x
STA Thing+8,x
STA Thing+16,x

because
STA Thing,x
STA Thing+4,x
STA Thing+8,x
STA Thing+16,x
is used a lot else where, so it compresses smaller than doing it the "right" way.

In this particular case the collision/physics FSM is utterly unique to the Squid player and the logic routines are basically unique or in that annoying unique where they are just one byte different here or there.
6507? VCS? I'm writing code for a 6510.

Indeed it is 320x200 from a Commodore 64.

Player controls are usually balanced at the mid way to the end depending on the game. So at the start I wanted to see the rough cost of doing the parabolic movement, but I didn't want to make it hard to play, I want to be able to zoom around and test quickly. Hence why you can do those little hops, good for testing the ends of a platform and getting your self in position. The "hover" also makes it really easy to land on anything you want, keeping my engine testing and speed test iteration speed high.
In other games you have other things to tweak to adjust the game play, enemy patterns, number of enemies, time limits, firing speed. Squid jump the game is basically judging how far you need to jump and how far the animating sprite is telling you are going to jump. So the levels,player movements and player animation speeds need to be designed and tweaked hand in hand. Since the "stolen" "crack" that video was made from, the player controls have progressed to having a "physicsy" FSM with a concept of momentum, i.e you slide off the ice platform and you don't just sink like a rock If you land on the conveyor belts of the opposite direction, you keep sliding in your original direction and slow down before getting thrust the opposite way.

If you made this a c128 game,you could release this with entirely different handling,physics and this would be their reaction.

Trying to swing back to topic:

I've read that some versions of Contra had pits, such as the NES version, and others didn't. Wikipedia's article states that the pits near the end of stage 1 aren't in the arcade version. Because addition of pits pushes it more toward platformer, perhaps this difference is part of the confusion about the extent to which run-and-gun overlaps platformers. People who grew up with Contra for NES consider the run-and-gun genre to incorporate those platforming elements seen in Contra for NES, whereas those who grew up with Contra arcade and Metal Slug might not.

I don't think so. The main difference between the arcade and NES versions of Contra (aside from improved controls in the latter) is that the NES version is much longer with every stage expanded, where in the arcade version they merely servered as simple gauntlets taking you to the next boss battle. Several individual stages on the NES were just different parts of a single stage on arcade. On the other hand, the over-the-shoulder "3D" stages were much bigger in the arcade, built sort of like little mazes.

Of course that also results in more actual platforming in the NES version, but the arcade definitely had platforming - including the iconic vertically scrolling stage which has you constantly jumping up from platform to platform. Even if no other stage has bottomless pits, there are platforms aplenty.

The much more simple explanation (Occam's Razor, really) for why people identify Contra as a platformer is because of the control scheme, which is simply straight up classic platform controls. And the same goes for Metal Slug, for that matter, and most other run'n'gun games in that vein.
I don't have a problem classifying Contra as a platform game for this reason, but if that's the only term you're using, most people will of course think of the classic Mario-style platformer focused almost entirely on platforming. If you talk about "run 'n gun" people will be more likely to know what you're talking about. Except that term also tends to cover the classic top-down Ikari Warriors/Commando style shooters. Genres are fun like that.

There are also plenty of games that are much more "borderline", too. Games like Ghosts 'n Goblins and Castlevania are definitely platform games too, and very far from the Contra style run 'n gun formula. But again they are much more action and combat focused than your typical cutesy Mario platformer. I think the fact that the platform game concept allows so much variation is exactly why it's not a bad thing that we are seeing a lot of them made.

...as long as you're not one of those people calling every game a "sidescroller" :3

My first impression was that it looks like an NES game, but then I noticed it looks a little too widescreen for an NES game. Then I counted the tiles, and I got 40 so I was thinking it must be a Sega Genesis game. But, then I saw talk about 6502 ASM and I was confused by it.

Something that threw me off was the fact that most C64 games run at 160x200.


If you don't think Metal Slug counts as a platformer, look at how many "platforms" are in the first stage.
http://www.vgmaps.com/Atlas/Neo-Geo/Met ... ssion1.png

Contra/Gyrzor is probably near the borderline. Were Rush'n'Attack is run'n'gun while something like Mega Man is platformer. There is no clean cut, its all sliding scales, with various levels of game play elements being combined. Where each of us draws the line will differ. Then you end up with some complete mash-ups like ActRaiser or Henry Hatworths...