Spacy Shooty 2016

I've rewritten the example game from my blog. It's almost a full game now...you can play through it in 5-10 min. Eventually, I will make the source code available. This is a bit of a test version of it. It may still have bugs, and I'm going to tweek/rewrite the patterns and order.

http://dl.dropboxusercontent.com/s/70f8 ... Spacy4.zip

Let me know what you think. Thanks.

I'm pretty happy with the sprite object system that I came up with...I'm using a lot of structs and pointers. I'm using the 'metasprite' tool from NES Screen Tool, and I wrote a python script to take the metasprite output, and convert it into a format that works really well with my sprite rendering system. The OAM is completely dynamic, and is rebuilt every frame.

EDIT: link updated 8:23 PM EST

Left seems more powerful than right?

I'll iron out the bugs a little later. Thanks.

Then one more and I'll be off. I died and this happened:



I got hit near the edge while drifting right. My ship exploded and respawned halfway into the screen. No enemies could hit me there until the boss.

Link updated, made a few tweaks. It's a bit harder now. Added some random enemy bullets. And they kind of angle at you now.

Still need to clean up and comment the code a bit more before I post the source code, since it is supposed to be example code.

Link above now includes source code.

Also, if anyone wants to use this code to make a different / better game, go right ahead.

This looks so cool. I support this project and want to see you finish it! Maybe even a cartridge release.

The game looks pretty good. The only thing that does not convince me is the control of the spacecraft. It seems that when you move the sprite of the ship it moves with a certain level of inertia towards that same side.

In any case, thanks for including the source code of the game.

I'm still waiting for someone to use this source code to make a better game. 100,000 unique visitors to my blog, and not 1 taker.

Maybe I made it too complex, using tons of ASM functions, and a mid-screen Y scroll change.

Do you think I should redo it, and make it simpler? Maybe? Use only C code?

Agreed with Ryoga on the inertia - sorry to be so "absolute" about it, but it has to go. It works in games like Defender and Asteroids where it's a central gameplay element, but in a pure shoot/dodge'em up game, you want absolute 100% precise control of the spaceship. Galaga did it right, no reason to change that.
This might sound like nitpicking, but it's actually a big issue with anyone who's into that kind of games. It's a very common thing to add when westerners develop shooting games, and it's almost universally bad - a typical "euroshmup" trope. It makes the controls less intuitive and the game less fun to play, so why have it. There are much more fun ways to make a game harder.
Otherwise I think this looks reall promising and a lot of fun.

Oh yeah, another things shmup developers learned over time is that the hitbox of your ship should never be larger than it needs to. I'm not talking bullet hell style 1x1 px hitboxes, just something that's at least somewhat smaller than the visible sprite, to make the game feel more fair to your player. Whenever something feels off about the hitbox, you much rather want the player to think "whew, I don't know what happened, but I was lucky I made that" than "what the hell, I didn't touch that!"

The latter was a stable of many otherwise great, classic Konami shooters, and they would have been better off without that (ie. see the awesome PC Engine port of Salamander vs. the problematic arcade original)

I've been wanting to do some homebrew game for NES for some time and that's why I was interested in this thread. When I have more free time of insurance that I will get to it (and who knows if I can ever contribute in some compo). I'm interested in doing a shoot em up for NES since I made a game of this genre in C for the open-source console GP2X-Wiz years ago and I wanted to make a port of that game to a console like the NES, although during some time I was considering the option of porting it to GB-Color or GB-Advance, systems for which I have also programmed some games.



I downloaded the source code of the game but I have not yet had the time to study it carefully. In any case, the assembly language (in any system) is always harder to learn or understand than the C language. If you want to make your code more accessible to people, you may be able to consider the change but I do not think it is a priority. taking into account that nobody has really been interested in it in your blog.