Why code NES games in ASM in 2018?

So, there’s a few reasons as to why I’ve chosen this for 2018:

The Challenge
There’s something about learning a new language, one that’s so different from anything I’ve learnt before, delving deep into the NES registers seems like a fun thing to try out also.

It’s The First “True” Console I owned
Yeah, like most kids I wanted a NES for bloody ages before I could place my tiny mitts on a controller, heck , I even remember the guy at the store attempting to sell me a megadrive instead back in the day, but my love for Megaman 2 from play sessions at my cousins house meant that simply wasn’t an option for 8 year old Ryan.

Even then, I wanted to make games for the console and would happily spend hours drawing out sprites on graph paper, even cutting out and drawing up fake cartridge boxes for games that I wanted to make happen. A racing game in the style of F1 race for the gameboy ( Turbo Racing on the NES was a regular favourite also back then ) and a platformer involving some fairly Mario-inspired little characters.

Yeah! There’s a big chunk of nostalgia going on here, childhood hopes and dreams which never really left me. This year is certainly the year to accomplish them.

Now If you’ll excuse me, it’s back to the code for me 🙂

Wish me luck!

2018 is here and so is the year of NES Development in Assembly!

So, happy new year, I haven’t updated the blog in ages, my bad. A few things have happened since the last post. Christmas, Halloween and my beginnings of learning NES Development and the lowest level of language I’ll ever attempt to learn, ASSEMBLY (ASM)!

I attempted some ASM on the Atari 2600 a year ago to little success but decided, after a chat to the guys at Mega Cat Studios, to give it the college try.

The first 2 projects started and finished without really finishing, but that’s to be expected really, it’s a new language to me and I’m still learning a lot about it. Needless to say, it’s a lot more involved than C, as you’re dealing with the raw bytes and nothing else, which feels stark compared to anything else but I’m ableto understand a lot more of it now and feel that game #3, a port of the amazing Flapadiddle by Jayenkai, will be a worthy first completed game.

The first 2 games, taught me a lot about ASM and gave me some guidance as to how to organise my code as well as how backgrounds and palettes work. So, I put together the beginnings of a port of Invasion VS from my days of OUYA coding which got a fair way, then btibitjam came around so I decided to take what I’d learnt and put it into a gamejam.

invasion vs - nes eidtion - homebrew attempt #1super floofy sheepie - homebrew test #2 To be blunt, it didn’t work out, I ran out of time and spent most of August feeling pretty downbeat over everything, eventually picking myself up again mid October to retry again, but with the task of creating a procedurally generated game.

This meant creating a seeded linear randomiser in asm, that produces reasonably random, set values. After a while of researching I came across a simple one for 8-bit values which simply multiplied by 13 and added 1.

After protottypinmg some levels in PHP and GDLib I felt ready to tackle this in ASM and so far we have the following.

It’s actually playing pretty well and works in both emulator and on my PAL NES, there’s lots of features I want to add to this game and so far, it only has 5kb of game code out of an available 32kb, so ,there’s lots of scope available.

Each level is procedurally generated with a seed based on the internal framecounter and, whilst the platform placement still leaves much to be desired (and coded in properly) It feels like the game I’ve loved playing for a lot of last year.

You should check it out by the way, it’s both FREE and awesome [Download Flapadiddle]

More updates on the way.

Ludum Dare 38- Hives Postmortem

So, with the compo entry complete last night and a few hours of sleep behind me. Now’s probably a good time to look at what is feel went well and not-so-well with the game during it’s short development cycle.

ld38-gameplay-1So, what went well?

Firstly I was happy with the theme of “a small world” I had an idea ready pretty quickly so could get stuck into the development of the game and it’s assets quite smoothly, despite the challenges associated with development on the classic gameboy (CPU, RAM, deciding whether to build with ROM banking in mind or not, etc.)

My homemade tools worked well (fairly well anyway).

Despite a couple of hiccups at the start with tile mapping (I had to fall back to manually doing this on a tile by tile basis) importing the graphics worked pretty reliably.

There is a FULL game loop, with side-fluff!

I (probably foolishly) worked on the non-gameplay parts for the first part of the game jam. Resulting in a fairly nice menu system with not much gameplay present, just basic player movement.

Despite my focus on different areas of the game initially, the resulting game (whilst simple and rather short) I feel is pretty nice. Not anything out there but challenging enough with multiple enemy types being added as you progress.

I accepted that the main game was pretty much done come the 2nd evening and spent most of the remaining 6 or so hours on adding more fluff including:

A proper high score table (with initials)

Fixing the levels on the SFX, adding more SFX and explosions when needed.

Adding fading transitions between the screens where appropriate

And, just becuase I was feeling particularly crazy ( and most older console games have this) a Demo mode.

The Demo player isn’t the cleverest as the fake joypad input is largely randomized, but with a little bit of logic to feel more authentic. It appears if you leave the title screen alone for 10 seconds and will play itself until you either press start or the beehives reach below a certain level of hit points.

Coding went well, the initial scope of the game was fairly small so it didn’t shrink that much compared to the original idea.

What Went Wrong.

Whilst I’m happy that the game is fairly complete, it is missing some elements which I’d like to add at some point in the future, including background music, power ups and more obvious gameplay progression as your score increases. (I mean, there’s more enemies and more types later on but it feels more Atari 2600 than it does Gameboy in parts)

The game length is okay for a game jam game but the action isn’t as exciting as it was in other gameboy games (which admittedly, I’ve spent more time on) such as, Infinitron or Formula Racing. I could fix this later with other elements being added, such as roughly targetted enemy shots and perhaps a boss-style enemy, ROM space permitting.

All in All

I’m fairly happy with the game made considering the time available. It fits the theme, is pretty much as complete as I could make this time around but I really, really need to learn or make a music tool that works well for me!

Just so I can implement the tracks in my ROMs with ease and not eat up much CPU (or ROM space) at the same time, expect bit-by-bit optimisation I guess!

Here’s to the next game jam ( and possibly some more tools to develop in the meanwhile)

Also, play the gameboy game yourself! Clicky Here!