gauauu

Kickstarter is live! Thanks for all your support all the way, everyone!

It's happening, but slow going. Frankengraphics is currently working on improving the world map graphics. We're still quite a ways out from being finished, but it's moving.

The core game logic of Anguna was ported from the Atari 2600 assembly, but most of the new stuff on the NES (new menus and splash screens, reworked darkness and how doors work, etc) was in C.

I'm sending Kevin a beta copy of Anguna Zero for the Spectrum Marathon fundraiser, so somebody's going to get to play it early

The tank animations definitely aren't 100% set yet. That said, there is a bit of an extension of the chassis to make it look like it's jumping. It is a bit on the subtle side though.

Oh man, yes, that makes me so happy to hear. And that's exactly why most of my compo entries have supported 4 players.

All this talk about Battle of Olympus. A fake sequel of it has been on my vague ideas list for years. But I've never figured out how to capture the sense of mystery that that game managed to provide for me.

Piko owns that IP now, he might not look too kindly on people using it....

Heh, the whole reason I'm making Halcyon is because I wanted a good Blaster Master sequel. It was originally going to be an unofficial in-universe prequel, but I got scared off by the new Blaster Master re-releases still using the IP. Yup. Agreed.

Neither has enough detail yet to be a very interesting announcement. Yet. I'm cautiously interested in seeing what the Retro Game Builder does. It could end up being a really well-designed system, it could be janky garbage, or it could just be vaporware.

I'm almost finished with Anguna Zero, a NES port of my Atari port of my Gameboy Advance game Anguna. It's a fairly direct port from the Atari, so it features the world, enemies, and layout of the Atari game, with improved graphics, and music from Thomas Cippolone. The game is mostly finished, and we're doing testing now. Hopefully will be released soon!

Been testing this side project, playing it over and over, hopefully will be ready for release relatively soon....

If it's the place I"m thinking of, I stumbled onto it before I even went into the other cave entrance. But there were plenty of other cave passages that I didn't end up exploring, so I'm not sure if it's the same one you mean.

I made it to just past the boulders, and didn't have a key. That's as far as I got. I think the feedback from nesdev forums (about being able to turn without moving) would really help also. Like someone else said, cutting grass is a PAIN. There was the rub. Apples cost money, money means grinding through grass or battles, but those were difficult enough that I avoided doing so. Keep at it though: with some tweaks, this could end up being really solid.

I played this for awhile on a flight last week. (Hopefully I'm not now infected with COVID-19!). I was pretty excited to try a new zelda-like, and it was clear from the towns/items/dialog/etc that you put a good bit of work into this! Some feedback: - after an hour or so of playing, I still didn't really understand the collision system. Sometimes an enemy would move at the right time and hit me despite me swinging the sword. Sometimes the enemy and I would both move into the same square at the same time, and neither of us took damage. Because of that, the combat all felt a bit frustrating. I never found a reliable way to dodge boulders (I just save state cheated to get past them), and couldn't figure out if there was supposed to be a way to get past the arrow traps in the caves, other than using the collision glitch to walk through them by timing it correctly. - I never did figure out what the cross is supposed to do.

You're not wrong, but with Atari, it really depends on what part of the code you're talking about. During the display kernel, cycle count is everything. You plan your entire code based on cycle counts of each instruction. You waste rom space aligning things to avoid the 1-cycle page-crossing penalty, or you waste loads of ram pre-calculating everything you can. But in the rest of your code, you often are doing everything you can to conserve rom and ram space. Many games end up at a point where your rom is full, and you want to add a small feature or fix a bug, and you have to spend an hour searching your codebase for places where you can free up the 8 bytes needed to make your changes. My code is filled with bne's where I originally had a jmp, just to save a byte. Or removing the sec/clc when possible. Or using the bit trick to skip 2 bytes instead of using a jmp. The trick that first blew my mind was abusing the stack instructions to quickly move data around. (ie by first moving the stack pointer to your data, then using pla to load the byte into A and move the stack pointer with one instruction). I assume this is what tepples' popslide library does on the NES, but the first time I saw it on Atari my mind was blown (the developersof combat used a similar but different technique of moving the stack pointer to a set of registers, and using the php command to push the zero flag into the register)

I don't think that's a fair characterization at all. Some of the people who were most welcoming to me when I joined this scene were folks who have argued in favor of a labeling distinction. You might not agree with their reason (and there are plenty of good arguments against a distinction), but reducing their arguments to petty elitism is just inaccurate and unnecessarily inflammatory.

I just played through it, and thought it was great. The way you managed to communicate a really heavy concept through a NES game is really well done.

It's a smaller event, but I'll be demoing stuff at the SixtySix Games / Bloomington-Normal Video Game Convention in a couple weeks. https://www.sixtysixgames.com/ If anyone from here happens by chance to be going, I'd love to get a chance to say hi in person!

We're still chugging along. The engine is mostly finished other than any level-specific or enemy-specific features that come up. Rough maps have been made of a little more than half of the world. Now we need to go back and refine all the maps and finish the rest of the world, and fill out some boss fights. And then polish, polish, polish. That said, it's been slow this month. Hopefully we'll ramp things back up in the next few weeks.

Possible? I mean, the demo is an actual NES demo by Kasumi. So what you're seeing there is definitely possible. But a full NES port would require a lot of changes and sacrifices. Note how flickery things get in that video when fighting a single enemy. It would be significantly worse than that if there was a lot going on on the screen at once. Shovel Knight was designed to look mostly nes-like, but pushes things a lot further than what the NES could actually do, in this and other various ways.

Yeah, if either player jumps out of the way, then the enemy reappears.

Thanks for posting! I didn't make it past the first level due to this bug though -- When 3 aliens and both players are on the same level, one of the aliens doesn't get displayed, so you have an invisible enemy wandering around. See the attached image. There's a 3rd invisible alien wandering around down there that keeps killing me. Is that something that could be fixed? It would really improve the gameplay, I think.

This is true.

That was one of my main things. If it fits your game design goal, you could compare the currently pressed buttons with last frame's buttons, and only shoot one bullet for every NEW press instead of any time the button is held. That would feel more like a lot of older shooting games where one press = one shot. (unless you'd rather let the player hold the button, which is perfectly acceptable, in which case yeah, rate limiting would improve the game a good bit). The other thing is the enemy movement, the way they jerk back to the top as they move. You could have a direction flag for the enemy, and have them move more smoothly upward then back downward, which would feel a lot nicer I think. Yeah, attributes can be a pain. I don't know how screen tool's C export works really, but I find it easier to include the nametable file directly into my binary instead of as C code, which then does include the attributes. The way I do it is to have an assembly file which just declares a symbol name, and incbin's the nametable, but there are other methods: .export _nametable _nametable: .incbin "../gfx/nametables/playfield.nam" If you assemble that with ca65 and link it with everything else, then you'll have a C symbol named nametable that you can access from your other C code: extern unsigned char nametable[]; //do whatever with nametable array That said, everyone's workflow is different, so you might have a different preference of how to work with these.