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.

On 8/12/2020 at 8:26 AM, dale_coop said:

I red it this weekend. Great interview! I really want to play Anguna Zero... looks awesome!

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

21 hours ago, Dr. Morbis said:

This game looks so awesome, but please add a little jumping animation for the tank thing (if you haven't already).  The other animations of the character moving and whatnot look so wonderful and fluid, but then when he gets in the tank and jumps in the air, it's like the tank just magically rises.  I'm not saying rip off Blaster Master and have the wheels move all the way inward, but do something to show that the tank has the power to rise in the air like that (puff of smoke/flame/fire under the vehicle for a second when it leaves the ground??? I dunno...).  I'm really looking forward to playing this game, but when I watch the trailer, this one little issue is all I can think about!

If it's too late, just ignore this post.  No worries, I'll still buy the game...

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.

On 7/2/2020 at 12:46 PM, toma said:

I always kind of thought doing Spiritual Warfare 2 as a Zelda 2 clone would be a fun project. Not one I'm going to pursue any time soon but if anyone else gives it a shot you've got my full support hahaha

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

On 6/20/2020 at 2:07 PM, toma said:

 If it were possible to land a license to develop a sequel or spin-off to an existing franchise, what would you guys want to see? Asking for a friend.

 

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.

On 6/24/2020 at 3:49 PM, Sumez said:

can only say I'm really jealous... 

Yup. Agreed.

3 hours ago, Scrobins said:

What are everyone's thoughts on either or both announcements? Anyone thinking of backing one, the other, or both?

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....

On 3/17/2020 at 4:08 PM, olddb said:

BTW: How hard was it to find the hole to the cave?

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.

23 minutes ago, olddb said:

Once you clear the boulders the game is about 1/3 done!

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.

24 minutes ago, olddb said:

The idea was for the player to use apples (which replenish hp) in this part

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.

On 1/22/2020 at 6:55 AM, Sumez said:

Yeah sorry. I just stupidly assumed 6502 implied NES programming. On Atari, every byte matters. I'd say cycle count is more central though.

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)

On 1/23/2020 at 10:38 AM, TheNew8bitHeroes said:

Anything that imposes a petty or pretentious layer of elitism which might be detrimental to that goal, I am adamantly against.  I'm not sure how that's not the position of everyone who is part of this passion, but...I've just come to accept that there are people who do this that just don't want anyone new in their clubhouse.

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!

6 hours ago, WaverBoy said:

Any updates on progress?

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.

58 minutes ago, johnvanderhoe said:

I'm already using the sprite flicker solution (linked above) in my base code. I can't recreate the issue on my end because I seem to have lost my second controller. But I believe it has something to do with the solution giving priority to the two player objects (when playing two players). What happens when one of the players leaves that bottom row? Does the invisible enemy reappear? They should of course be cycling based on the code I'm using, so I don't know. This will take longer to figure out on my end.

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.

33 minutes ago, erac said:

^ that should be const, you're not going to write to it in ROM.

This is true.

9 hours ago, chromableedstudios said:

-rate limiting the player fire a bit so the stars don't always overlap

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.

9 hours ago, chromableedstudios said:

-figure out how to write the attributes properly? Ok this sounds really dumb, but I just took a 'game jam' kind of approach and glossed over anything that put up resistance to get to min viable product (I guess it's just nv ram like any other? Confused why nesst doesn't include the attributes in their generated c? Or maybe I'm using it wrong)

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.