Nongram Devlog: PictoPuzzler
Here you can find all the posts, from the beginning, of my incremental progress on my NES Nonogram puzzle game, PictoPuzzler! I plan to make a longer technical break down when the game is completely finished – until then, follow along as I work on creating my first completed NES game!
You can find the source code for the game and extra tools here:
PictoPuzzler Source
NES assembly source code and assets.
Puzzle Building Tool Source
WPF tool for generating puzzle banks for PictoPuzzler.
Music Tool Source (WIP)
WPF tool for creating music compatible with PictoPuzzler’s sound engine.
-
I have an article series planned for this, but I figure since my brain works more an a “just make the thing why write stuff down?” mentality, I figured it’d be best to keep tabs on my progress here in the blog part of my website.
I’m currently working on an NES nonogram game to showcase and utilize the basic functionality of the MMC1 Mapper for the NES! I’ve gotten a lot of stuff out of the way- UI flow, storing and solving puzzles- but there’s a lot of things to do before it’s finished!
below is a video show casing the current state: we’ve got a main menu, a game screen, and even a game over screen- all lopping seamlessly into one another!
compared to most projects I start and abandon, this one seems to have pretty good start and stop points that make it easier to not over do it, and I think this will definitely be a personal project I finish.
-
I’ve got the menuing mostly successful, in that you can choose a bank and start at the first puzzle in the bank
next up, I’ll refine the puzzle solving to actually utilize the solved, colored image of the puzzle
-
It’s starting to come together- now I’ve got multiple puzzle sizes! one big issue though, as with all game developments, is the tech debt- I’m using full nametables, I’m using too many variables that could probably be compressed down, I’m using some copy paste code… etc. we’re closing in on the full design being finished, at least, which will give me a good base to refactor from.
-
Music is in! I tried to find a pre-made music engine with a supplemental tracker/music software for ease of use… but those engines are incredibly large and a little obtuse to deal with for this project. I opted instead to use the Nerdy Nights Tutorial sound engine, which is much more lightweight and debug-able, but requires me to input all the notes by hand… LMMS is a great prototyping DAW, though! made that a lot easier. All that’s left is one small time recording bug and making all the puzzles!
there’s a couple effects I might look into implementing on the music engine, but that’ll be a different project altogether 🙂
-
While I’ve got writers block on music, I figured I’d take the time to improve the ability of my nonogram tool to be… actually usable!
below is a video showing the tool and how it works – and how quick the iteration turn around is!
-
One thing I failed to consider (or rather, thought I wasn’t going to run into) was the solvability of my puzzles. sometimes, even with simple seeming puzzles, there can be multiple solutions that can frustrate players who will have to start guessing and checking every move. That’s no fun!
I was pointed in the direction of this simple nonogram creation/solving tool on github by Kniffen. Other solvers of it’s kind tend to be much more involved behemoths of code, but those tend to try and actually find EVERY possible solution. the great thing about this solver was that it didn’t tell you what all the solutions were, just that there were ambiguities within a given puzzle. Since that’s all I actually needed, I ported over the solver from Kniffen’s code base into my tool- Now we’ve got a live update on the puzzle showing where ambiguous tiles are!
-
It’s fairly common in Nonogram games to display the image of the puzzles you’ve completed. in Mario Picross, it was the final pixel solution, while in Konami Pixel Puzzle, it’s a the full color image. while I COULD do either one, It’s probably best to keep it simple and go with the former’s solution- I already basically create the CHR data info when parsing out the clue numbers, so just repurposing the data will work just fine!
-
Demo of Catfort Sound, a C#/WPF NES APU emulator It’s amazing the time you can lose to personal projects when you get like, “employed” or whatever it’s called. Now that that’s out of the way (even if I wish it still was IN the way), I’ve had some time to re-look at the engine – and I’ve got issues. Mainly, I created this game with only a few screens in mind- so few, that I thought I could get away with minimal ROM use by just throwing the full nametables for each game mode plain raw into the ROM.
Big mistake, of course.
I have ideas to optimize that to a large degree, but until then, the sound engine has to live in the swappable banks. This wouldn’t be too much of a problem, except that multiple copies of labels – even in swappable banks – doesn’t go down well with NESASM. To get around this, I have to compile the sound engine individually for every small change made to it – I can store songs per bank, but if I want to make a new arpeggio definition or note length or volume envelope or pitch bend effect… I need to do a whole list of nonsense to even see how it sounded.
by my calculations, I making some new drawing functions to deal with the screen drawing should leave me with MORE than enough room to insert the sound engine into the stable bank, removing the need to re-compile.
…But, that doesn’t necessarily make testing sounds any easier. I still need to try a new setting, make sure it’s defined everywhere it needs to be, put it in the song, recompile, play, and wait to hear the effect. If it’s a bust, that’s a whole new set of retweaks.
Luckily, I’m a programmer standing on the shoulders of much, much smarter giants – and I want to procrastinate screen drawing refactors. With a couple google searches and a LOT of time on the NESDEV APU wiki, I was able to create my own C# tool to test out making music for my specific engine. I wrote a custom API for the APU that can emulate the NES as well as I can get it to, including pretty accurate Pulse, Triangle, Noise, and DMC channels. Big fan of that EB0 bass kick and snare, So I wanted to make sure I could use ’em!I have support for the FDS wavetable stubbed out too, but that wiki article is much more involved, and I’ll need to dig into it’s implementation more before I can comfortably use it. There are some elements of DSP I’ve elected to not delve into further… It makes pretty dang clear sound as is, but maybe learning limited-band synthesis and how to make and understand a Fourier transform will be well within my near future.
I’d usually have posted the same updates here as I did on linked in, where you can see the progression of the tool – but here it is in it’s current form, where I’ve put in some familiar tunes for testing. Special thanks to Oscilloscope Breakdown YouTubers, the NESDEV community, MiniMeters, and one random guy on Codeproject for all being helpful tools in creating a working NES APU in a WPF program.
…Though, I hope someday soon to move everything over to C++ so I can make all this in Linux instead
-
Demo of Copy/Paste functionality in the engine For a while, I’ve been stuck on making progress on the music tool because I’ve been wondering if I should switch backends from WPF to something else – ideally, something more robust in terms of making custom widgets.
But, all the ones I like looked really complicated to get into, and would require a full rebuild of the engine from the ground up in C++. I was hoping to start moving all personal development to lonely little linux distro, but the sunk cost fallacy wins today – though, I think I got something pretty good out of it!
One of the main sticking points I had making this in WPF was the lack of a good copy paste method. whenever I’d look up documentation or tutorials, I’d just find API documentations of paid extentions – I’m looking to do it on a budget.
I was able to piece together a good many things, and refactor the data handling to work as an MVVM system with generics, reflection, manual serialization for more compact save files… the works. Too bad it… really doesn’t look like much changed. the next step will be to get it exporting files out that I can actually use in my game!
-
Demo of the effect editor, and exporting the song to the game With copy pasting out of the way, I was able to start a refactor on how effects or stored to work better in an MVVM environment to create a custom interactive editor. I’m no UI guy so maybe it’s not the… best? Design? But I think the functionality is pretty clear, and it isn’t a broken mess, which is the important part! Lots to do otherwise on streamlining and sharing effect tables between the engine and the app of course, but it’s on the right track.
Songs can now also be exported out and compiled into the game! It’s missing one VERY important feature (sub loops!), as well as features not in the sound engine yet (duty cycle effect tables, and channel start delays), but testing songs without that level of loop compression or fancy echo is at least possible and not very time consuming.
-
It’s been a bit, and this… more than a little late, but I was able to show PitcoPuzzler off recently at Spillkonventet in Norway back in June!
I had a WONDERFUL time meeting and talking with everyone there and learning more about the Norwegian game development scene- a small but clearly active, creative, and brilliant crowd of dedicated folks.
The game was a big hit with all involved, and I was able to get a couple extra things worked on to ensure a smooth experience- mainly, a couple bug fixes, and most importantly, cutting down graphics data to allow for the sound engine to live inside the static bank – no more weird compilation work-arounds!
And from a big crowd of testers, I was able to jot down the next set of QoL fixes to really help make this game feel finished and polished. I’ll try and get some work done and posts up soon for all that.