Indivisible on NES (Playable ROM inside/Image Heavy)

Thanks for the encouragement!

Nah, that can't stay KaboomKid. It's like... if the enemies didn't have a kill timer, they'd just be stuck like that forever. It happened because enemies can only store any one thing they got hit by, and there's two attacks out. So they just keep replacing each other, refreshing hitstop.

All Ajna's movement is "done". There's some hard things left to do for when she dies, still. And there will very likely be tweaking. But... there's no longer code from nine months ago with small problems I never bothered to fix.

It was numerous small things, rather than anything brain breaking. I'll just do a bunch of befores (left) and afters (right).

Attack now start in the direction of the direction on the d-pad you're pressing, rather than just her facing direction.


Jumping attacks can no longer change direction based on speed. I did this 9 months ago to make it easier to axe hang because the above (the direction you're pressing mattering) wasn't true.


The crouching attacks now check for down when the press of B happened in the input buffer, rather than if down is held when the attack actually started. Very small, but I think it's how it should be.

Both are passed the same input. B and Down in the same frame. The left (before) gets standing axe because it needs you to be holding down when the attack starts.




Fixed a long-standing crouch attack quirk. (If you were facing right, and pressed left, you would start crouch turnaround. If you let go of left, and pressed B you would get a right facing attack, because the crouch turnaround only turned you around on the second frame of it. Now it turns you around immediately and flips the art, so she'd be facing left for the entirety of the crouch turnaround animation in the above case.)

Even before, you'd get left if you were still holding left when B was pressed. So this was small, but had also sort of bugged me for a while.


Fixed the flickering sprite on her crouch frames. This drove me crazy FOREVER, but it's very small.


Look at her hand. That's not the result of the scanline stuff. It's because I messed up on a sprite tile. Two pixels of different colors are overlapped, so when the sprite priorities change, different colors appear on top.



Lots and lots and lots of axe hang changes. Special thanks to Mike for streaming/explaining how some of the stuff worked to me.

The way it has worked since literally before yesterday is that if the axe hang sprite would visually have the axe in the wall, the axe hang was possible. This meant her range was just the sprite... pretty weak. She now magnets to the wall, and so she also has more range. The reason I didn't do this in the first place is because it's more likely to cause a collision detection issue. I didn't have time to give it the thought it required for build one, and I never changed it.


There's now a palette effect when the axe hang is possible. The time for the axe hang is no longer fixed regardless of how long you hold B. (You can see the palette effect in the above gif, not worth making a gif for the variable time.)

The axe hang now checks another point. It used to only check one, allowing for annoying stuff like this to happen.


It also allows you to grab walls for more frames. (I actually thought the original was literally one frame, but it seems to be two.) It's still not quite as easy as the original game, but there's a point where even I have to say, "Well, this is NES."

Finally added landing friction. This was in the post I based the first build of, and I just... forgot to do it. And never changed it until now. (No gifs.)

Ajna's direction can now be locked. This keeps her from turning around after getting hurt, fixing a visual quirk I have hated since I added getting hurt. It also allows post axe jump to look more like the original game.

Notice how in the before she switches direction when she lands. It drove me nuts, seriously. (It can still happen, but not in a way that annoys me as much.)

And here's post axe jump facing the same direction for a little bit:



I had no idea this was even possible in the original game (low quality gif to make it less huge. Still huge, though.).


I've replicated it, but I've got a compile time define to disable it. Not 100% sure I wanna allow the one-two to switch directions for Indivisible NES.


There's a buffer to jump after falling.



Her collision box now shrinks when she's crouching. I never bothered to do this because there wasn't really a plan to do enemies. 9 months later, there it is.



You can now jump cancel crouching axe on hit. I need to fix the launch trajectory now. The current one was designed for hitting the launched thing on the way down after the animation was fully complete.

There are other cancels in the original game, but I'm not sure I'm doing them. They make some stuff a bit too easy for the real time combat. Even the jump cancel kinda wrecks one thing, but... it's so cool!

So now that Ajna's "done", I can finally tackle the tweaks the AI need. I may also make their interactions a bit more complex. There's also a problem with how they're loaded. With that done, the game is ready for testing.

Also, wow, that was a lot of gifs. Let's... not do that again, took ages... Edit: Hah... even forgot two...

Bit of a non update, but I'm only about 40% done with the "before testing" tasks. Trying to get to 50% by tonight.
There's basically two halfs, and some side things that are basically non factors.

Half one has had a bunch of dumb unexpected things due to its immense complexity (and that I've never done something like it before). Half one has been stupid enough that I just drew most of last week instead.
Half two is a similar kind of task, but far less complex. (I hope.) Plus, because of half one, I'll have at least done something like it before.
The side things, I basically know how I want to do them.

Ideally I'd like to be the "game parts" to be done by October 24th for a number of reasons... That doesn't include the graphics and music, though. We'll see if I get there.

Half one is indeed done, except for one... Heisenbug... There's also like... a design problem that I may puzzle over even after I hand this to testers.

I'm working on the side things, now. While doing so, a post worthy thing happened.


I discovered I broke crouching hitboxes when I shrank her collision box while crouching. I'd... probably have never noticed this had I not needed to fix some things up for hitstop. As you can see, the left one is high up enough that it'll still hit. To be honest, it scares me what else might end up not working because of some change that I don't catch. Hopefully if anything, it's only things that are only wrong in theory like this. In practice this doesn't really matter. (But I'm still fixing it, of course.)

I also wrote the credits for this yesterday. Release is starting to feel like a real thing, but there will still be a fair amount to do even when the gameplay is done. OTL

It's been a while. I took a week off from this. Didn't get done by the 24th, which would have been cool for a number of reasons. This is... quite the project folks. And the speed runners will beat it in two minutes.

In the spoiler is a list of all the not secret stuff I did since the last post.
Even with all the above, it doesn't feel like I'm making much progress. Roughly the same stuff needs to get done that needed to get done in the last post.

Other things have happened since the last post. I had a couple of local friends test, because it was convenient. One thing I was a touch worried about will seemingly be fine. There's still a decent amount of stuff to do before it's where I intended to start testing. :D

Here's some gifs of some of the above changes.

There's now code that keeps Ajna from getting locked into hitstop. The situations that would cause it shouldn't occur in the demo, but eh. Was easy to do.

In this gif, a new vine is created every other frame. A hitbox won't hit the same object twice, but because new vines are constantly being created she's hitting the new vines while in hitstop from previous vines. Hitting anything sets hitstop, so her animation would essentially be stuck. This just stops hitstop getting set once it's detected she's been in hitstop too long. You can see the timer counting hitstop in Vals. She can still get stuck in hitstop for a while, but not forever (if I did it right) while still maintaining the ability to hit two things in one strike and have the second hit still slow the animation.

You can now knock enemies into each other. It doesn't do damage, it's just a neat effect. (Not really the best gif to show it, but oh well.)

You could hit a hungry ghost into an Ahp, and the Ahp will be flung backwards. I sort of regret doing it. I assumed it'd be easy because my other game handles this sort of collision beautifully. But Indivisible enemies weren't built assuming their speeds could be changed in this way. There are a lot of tiny things I'm not happy about with it, but I probably won't fix them. Worst part is, there won't even be a lot of opportunities to try this. Simply not enough enemies placed close together. (Ajna is invulnerable in the gif to make it easier to set up the knocking.)


Ajna Levitation for debugging.

Won't be in the release obviously, but still cool.

Hitbox/Hurtbox changes

It used to be if you touched the white box on the left, you got hit. Now you'll only get hit if you touch the white box on the right. But you can hit the white box on the left with the axe and that will still hurt the Belu.

I'm currently working on screenshake.

It's providing some challenges I didn't foresee, but nothing nuts. It should be done soon. Then I can finally start on roughly the last thing before real testing. Really hope to get there soon, so I can work on some fun stuff. I'm sure you're all sick of the debug grid backgrounds. ;)

Still not done, but done enough that I'm writing up tester documentation. If all goes well, it should go out to a few people sometime this week. Sadly... it's also the week of US Thanksgiving...

The last really big thing I have to do is some AI tweaks. Other things I may not bother with are cleaning up death a little (the game currently requires using debug commands to restart if you're killed/etc.) and remapping areas. Things are... narrow? But I don't want to really focus on remapping until I have the final graphics, so it may stay that way for the first round of testing.

Okay, well, some people have it access to it now. Like a half hour after I sent it out, I realized one debug command I left on for testers to use was relying on another debug command I didn't leave on for testers to use. So that was a good start. Fixed before anyone actually got it, probably?

There will probably be a slightly more open testing later.

Some of the recent things I did before sending it out were:
1. Making New Game Plus actually work.
I've had a debug define that says, "This is a new game plus game." but the end screen was basically a softlock so you couldn't start with axe after a regular game. Now you can!
Old/New

Running out of room for the logo. >_>

2. Making it so that a debug command isn't needed to restart after death. The game is now playable from start to finish even in release mode, which hasn't ever really been true assuming you died.

I don't really know what to do next. I guess I need to write a better program to get new graphics into the game, but I'm probably just gonna draw or something until all the feedback rolls in.

I had planned to make a post very near when this topic turned a year old, but I slept through it!

Anyway, it's a year old now. It's weird to think about. The quick thing I made in like five days was actually reasonably feature complete, all things considered. And just the same, the project has taken more than a year. The ninety-ninety rule is true, I guess. Also goes to show why Ludum Dare games that go on to become full games take so long.

I've been making slow progress since the last post, but I haven't really worked on it. There's so little left that I can't reasonably avoid some things I've put off until the end now. It's a weird state to be in. I'm working on the thing I'd least like to do, and I'm at maybe 25%.

The remaining tasks when that is done are:
1. Fix that thing testers showed me was wrong/have them retest if interested. (Maybe open testing more?)
2. Finish background graphics. (Title Screen/Dungeon)
3. Write a program so that the title screen fading and some other graphical things aren't hellish to get in the actual game.
4. Put the graphics in the actual game.
5. Remap the dungeon. Things are really tight with the new physics, the dungeon was made for the "made in five days" physics.
6. Reanimate some of Ajna's stuff? I really don't wanna, but I think I have to. T-T
7. Sit on it for a few days, playing a bit throughout while reviewing code to make sure there's no dumb bugs.

Also somewhere along the line, I broke how double hits set the direction of hit objects so that has to be fixed. It was really cool seeing testers play the game through input recordings. Thanks guys!

Hi! Hello! Happy New Year!

I didn't quit yet!

I actually worked on another quick project with Hawken. (Actually quick, not Indivisible-thought-it'd-be-quick-but-here-we-are-a-year-later quick.) Here's a tweet about it:
Here's another tweet about it:
It's done and I'm back on Indivisible for the foreseeable future. I'm about... 45%... done with the things that aren't really in my skillset?

In theory the last half is easier. In theory.

When that's done, I can at least work on stuff worth showing, until then lame text updates. T_T

I definitely prefer cartridge development to FDS. There are cool things about it, but most you can also do with an existing cartridge type. The really neat advantage it has (arbitrary "file" sizes) is ruined by the several seconds it takes to load things. On cartridges, "loading" is essentially instant. Indivisible loads like 14 things every single frame. It's possible to do 1,000s of loads in a frame on cartridge even, but you're unlikely to need to.

In Indivisible news I'm done with "half one". I feel like I've been working on it for months! (Because I have...) I'll probably start "half two" tomorrow. Despite being a "half", it should take a fraction of the time.

This lets me attach webm, but doesn't give a preview. Sorry for the viewing inconvenience, but gif wouldn't have got it done here.


Got as many as 32 sound effects left to do, or as few as 20. Depends on if I do a lot of unique sound effects per enemy or not. These aren't really final, but hey, progress that's not text.

Edit: Alright, it's on youtube now. I used webm because I wanted to get a new youtube account before this drops and I don't... have it yet.

Tiny video format trying to replace gif. Sound, better compression, more than 256 colors etc. VLC will play it. I could add an mp4 version I guess.

Edit: Well, now it's on youtube.

It's been a while since I was able to be silly with this project.
I wanted to do something even more iconic, but most of the really good ones were too much trouble to get working.

I'll take that out now, heh. There is another sound effect I took that will probably stay until at least the next round of testing. I know it can't stay forever, but it's so good and I'm not sure what I want to replace it with. :P

Sound effects should be done enough later today or tomorrow.

Man, this will never be done. Let's do an actual dev log post (kind of) rather than lame, short text updates. Although... it won't show much related to the actual game.

So I have been working on a program to make background graphics easier to put in. I tried for a while to keep it reasonably generic so I could use it for future projects. But at this point my will to finish Indivisible before another year passes is winning...

There is one hardware thing about NES that makes it really annoying to work with in programs not built specifically with NES in mind. Tiles are 8x8. Palette regions are 16x16. (There are... exceptions. Let's not talk about them.)

Any tile can use up to 4 colors. Any palette region can use up to 4 colors. Here are tiles in Castlevania since I happen to have them handy:

Essentially any pixel is just a number from 0 to 3. It is the palette that determines which actual color that number represents. (0 could mean black, or pink, or whatever depending on the palette) Notice how the font is displayed in different colors in the gif. The tiles are not changing, just the palette.


Here is a ? block from Super Mario Bros:

It is 16x16 (Also shown at 2x). It uses four 8x8 tiles. It uses 4 colors. (Blue for the corners, black, orange, and brown.) This works. Only 4 colors per tile, only 4 colors per palette region.

Here is the ? block again:

It still only uses 4 colors per tile. That checks out. But it uses 9 colors in the palette region. That doesn't.

Note that this 4 color "palette region" restriction is why quite often there are not smaller structures than 16x16 in NES games. You basically have to define at least a 16x16 structure with 4 tiles and the palette for those 4, so it makes sense to tie your collision, etc to that size as well.

In any case, this is where the trouble starts. There are a few pieces of software that let you draw/edit tilemaps. And usually this means you stick to one tilesize. If you choose 16x16, it's easier to keep the palette areas in check, but then hard to get the 8x8 tile count. (Which, if you go over 256 can matter.) If you choose 8x8, you can export a level or whatever that doesn't obey the 16x16 color restrictions. (A super annoying thing that happens a lot is you create a 16x16 piece of the level that would work if it was shifted over 8 pixels...) There's also that if you use a program that supports drawing and editing tilemaps, but does not support palettes (like Pyxel Edit) you can have two tiles with two different colors that are meant to be one tile and Pyxel Edit won't recognize this. (For instance, if you had both versions of the ? block above in your map, Pyxel Edit would think it was seven 8x8 tiles, but it's four as far as the NES is concerned.)

I wrote a really cool program to help with the map making part which Indivisible barely uses due to its complicated nature. (I didn't think I'd be working on Indivisible very long. I wanted to keep it simple T_T)

You can see that program here: http://imgur.com/QCsImfw (The collision info boxes look wrong because that stuff wasn't needed for what those graphics were used with)
The graphics themselves are a mix of Prism's and Phoenix849's.

Even this fairly cool tool depends on the tiles being already made, though. And even once you have the tiles made, you still need to tie additional information to them (collision enabled? Ladder? Water?). This tool is happy to tie information, but only for that specific game's format.

I set out to create a tool that would let me import an image, check if the image is valid (under NES or any sane restrictions), and then create tiles/larger tiles. Then tie collision info to those tiles.

This was an early version:

The Mario image is 9 colors, so with a limit of 6 the three least used colors get marked as errors. The gif then shows checking 2x1 and 1x2 regions for more than 1 color and marks that in different ways.

What I'm stuck on right this minute... is animation.
Check out this gif of Kirby's Adventure:


A bit like how a tile's pixel is just a number from 0 to 3, a tile in the map is just a number from 0 to 255. And just like how changing the palette would change the pixel color, changing the tile itself would change what is displayed in the map. Here are Kirby's tiles in memory during that animation:

(Mario's ? block changing colors does roughly this same thing, except it changes the palette rather than the tiles. Either way, the NES draws the change magically!)

I had written my program without animation support thinking it'd be easy to add later. And... it wasn't. So I'm writing this post instead of working on it. :P

In my Aseprite Love Letter I noted how many programs did not support both frames and layers. And I've... begun to experience why.

Anyway, once I... refactor animation into this so it can figure out where to put animated tiles like the above, I need to add a way to add collision info to the things and export it Indivisible's format. That should be easy. Ultimately this program is taking way longer than I wanted. Just... getting started with it took forever because I tried a new framework... At the end of the day, I wanna import 4 pngs like the frames from that Kirby gif, get a stack of tiles, and then slap information to the grouped palette regions in the image so I can use them in the game.

To end this post: I called the program Tilizer, then Tyler, then Tiler Durden, then was upset I was beat to that pun by some other program.

Edit: Oh. Right. Music and sound effects have been done for a whhiiiilllleeeee... just like gameplay, more or less. It's maddening that the game itself has been done forever, but it hasn't been pretty enough.

Part of why I am writing this program is because I'm changing how vines work, and the new way would be significantly harder to do with the current process. But also this program will help with future things entirely separate from Indivisible.

Also: Testers, not that the game has been updated since November, but the testing link is down, because dropbox killed all of that sort of link. If ever I finish background graphics, I'll contact you all again, I suppose.

Hmm... I think this whole topic is becoming more for me than for others. The planned postmortem posts might be more interesting, once all the secrets are out. This post is like the last one. Not very much about the game. But it adds that human touch. Or something. :P

For a very long while I had wanted to write a small animation program. Many a year ago (2009?), I followed a user of TVPaint quite closely. TVPaint is very good, and very full featured. So, naturally, it costs a lot. At the time, I did not even have a PC graphics tablet. I primarily used paper and Colors! on Nintendo DS. Nintendo DS (and Lite) actually has a pressure sensitive screen (in a roundabout way), so painting on it was like having a portable, very tiny Cintiq.

I still prefer the Colors! painting experience to the tablet I do have (since it is not a tablet monitor)... but Colors! on DS is limited to a 512x384 resolution. So PC gets use for that sweet high def!

There's another homebrew art program on DS. Animanatee. Animanatee was like Flipnote released later on DSi. Except better on the art side for a lot of things. You could choose 60 colors instead of being locked to red, blue, black. It's a very good program that I still use a bit today. (I even wrote an Aseprite->Animanatee, Animanatee->Aseprite converter so I could more easily work on things on the go.)

Unlike Colors!, Animanatee didn't have pressure based opacity and color blending. I wanted an animation program that would allow me to paint like Colors! that didn't cost a lot. In my Aseprite Love Letter post (woah, another mention of it!) I said I had tried all these animation programs... and that's why.

I discovered Aseprite much later than Animanatee and Colors! (2012?) It was basically everything I wanted then, as far as animation workflow, except no antialiased brushes (it's a pixel art program after all), and no pressure-based opacity. (Though it totally does have all sorts of color blending.) I vowed that if Aseprite didn't beat me to it and the things I worked on were finished, I would make the program. Even now, I think a LOT of people would take notice if Aseprite added that sort of painting...

Then, Krita came out of relative nowhere with its animation support, beating longstanding hopefuls like cinepaint to updated Windows release. Aseprite still has a more agreeable animation workflow, but Krita has what I looking for while trying boatloads of painting software. (There was stuff like GIMP, that kinda sorta had animation support with plugins, but... eh. Fire Alpaca... there's a lot that got close right before Krita came from behind with something good and free.)

How does any of that relate to Indivisible on NES? Well... This silly Tiler Durden program has basically become the start of the animation program I didn't want to write because I was too busy making games. Indivisible NES has made me explore programming in lots of ways I didn't intend to commit to. I've got mixed feelings about a lot of it.

Here's a chunk of Letter to Momo playing in what was supposed to just be an NES tile checking program. :P

(The red is because I wanted to make sure the error checking layer was still working.)
And here's what it looks like doing something that's more like its intended purpose:

As I found myself writing code to create slices of an image, I realized color blending isn't that far off of a step. I even learned how to do it to help a friend with his game a month or so ago. Even though this totally isn't an animation program (you can't actually draw on the image), the classes that have been created could totally work with one. It even autodetects an image sequence. (momo0000000072.png will load momo0000000072.png-momoXXXXXXXXXX.png). It does it in the worst way possible, though! Don't have %d in your filename ;). It's really weird... I kind of... accidentally starting writing this animation program I've been thinking about for a while.

Why do it when Krita exists? Well.... Krita doesn't run on Nintendo DS Lite. 8)

At the end of the post, down to business. The time between this post and the last post was getting the program to do what it already did, plus animation. I'm trying to finish this tile thing by the weekend which will finally free me up to do the final graphics. I haven't written like... real... c++ code in years due to all the 6502 assembly, so I'm learning/relearning a lot. I'm trying to at least not write bad code in case I do turn this into an animation program, but there's still things I'm not... doing in the best way for time's sake.

This tool was also made to slightly change the level format, so the final graphics will require some code changes within the game. They should be quite easy. If it was just graphics, I probably would have done them manually again instead of writing this tool. At the end of the day, the real delay is that I'm primarily drawing instead of working on this. ¯\_(ツ)_/¯

Sorry for the long post and brain dump. <3 for reading. Maybe soon you'll all finally get to see what the temple will look like.

Hah. Wow. Looks like I'm failing to finish this before the only "deadline" I had left! Or I might finish just in time...

I did a lot of work making this look like this prototype, the backer update kinda obsoletes that, RIP. ¯\_(ツ)_/¯

I actually gave an impromptu talk on this yesterday, which may have been recorded? I honestly kinda hope not, it showed a very small thing not yet shown here. Beyond that, this topic is way more in depth.

But I also showed this, which is new, and I may as well post.


They may end up looking way different, we'll see. Full disclosure, the creature statue is a cleaned up color reduction. Aiming to release this sometime in May, we'll see if I even make that...

<_<
;>_>
Did I say May? Mmmm. So something I've kept secret is that fact that the game scrolls. Why? Heh. Because it's not easy to do on NES, the way the game is doing it.

Astute thread readers may have noticed I totally have a scroll position in the debug script, though.

I actually removed even this in early posts.
Nothing to the left of the mouse position:

Kasumi said:

View attachment 13302

Scroll position next to the mouse position:

Kasumi said:

View attachment 13824

I'm so used to seeing it that I forgot to remove it. (The scroll info is displayed in the same place for my other game that I started before this, even...) I stopped caring about it being there after I realized I posted some stuff with it (rerecord or edit for that, really?), but I did make sure it was always 0, 0.

But... there was still a way to figure out the game probably scrolled, if you really paid attention. ( ͡° ͜ʖ ͡°)

Here's a gif:

I've got a post draft about why scrolling is tough, but... trying to finish this thing, I am genuinely feeling the pressure of that backer update coming out. Short version: There's (usually) no offscreen buffer to update the new parts of the level scrolling in one of the directions. Super Mario Bros. only scrolls horizontally, and so it has an offscreen buffer horizontally. Ice Climber only scrolls vertically, and so it has an offscreen buffer vertically. Metroid scrolls either horizontally or vertically (never both at once), it switches what type of offscreen buffer it has when you go through a door. Kirby's Adventure, Super Mario Bros. 3 and a reasonable amount of late gen games did figure it out, but let's just say scrolling on NES isn't even the most fun when you do have an offscreen buffer to update to.

The colors are not final.
"Why aren't the colors final?"

(Excuse the very old versions of some of these emulators)
There's a joke that NTSC stands for Never The Same Color. The palette I'm using to draw with looks like none of these, what my NES looks like on my TV looks like none of these, and what my NES looks like on someone else's TV doesn't look like my NES on my TV.

It's uh... kinda hard to win. NES doesn't have RGB values for its palette, the colors are at the mercy of the TV.

There's about 10 things left on the todo list. None of it is big, but some of it is medium. I am definitely trying to beat the backer update out. My next update post, which is hopefully not a month from now, should be that the game has entered a second round of testing.

What other things besides scrolling are hidden away deep in context of posts I've already made? Find out next time. (´・ω・｀)

Kasumi said:

...the game has entered a second round of testing.

Currently, only two people have access just to make sure it's not broken in some obvious way. When I hear back from them, I will begin to send it out to more people. Maybe some people in this thread might get PMs! Who knows?!

I'm probably gonna work on the graphics now, or add PAL support. (European consoles run at a different frame rate. It will make the game play slower. I can at least make the music play at the right speed/pitch, but I won't change the speed of literally everything else for them.)

Edit: Okay, seems fine. Now more people have it. Still not done sending, though...

Edit2: Now I think all the people have been asked... if you didn't make it, I may open this up a little more once it's even closer to done than it already is.

And now it is sleep time, my goodness...

Another lame text update. I hope I actually still want to write about the stuff I did after this is released, I might just lose all interest afterwards. >_>

Testing went well, it seems like the changes I made since the first round were in the right direction.

I have just made what could be the final gameplay change. So what's left? Well, there are some code changes I want to do separate from gameplay. (Medium difficulty? And could still break the game.) And the tilesets.

If you've been following this thread silently and want to give this a shot, PM me. You have to be prepared to record gameplay using the emulator FCEUX. (Instructions for doing so will be in the pack.) You have to keep the test builds and their content private. You have to... kinda get to it soon? Heh.

I don't guarantee everyone gets in, but hey, it'll be out soon anyway. I'm not sure when I'll get back to people. Hopefully this weekend, it depends how long those final non gameplay things take. (Otherwise, there's... not really a build I'm in need of new testing for.)

Assuming no bugs are found as a result of those last code changes the only thing keeping this game from release will be my tileset creation speed.

... Well, then. In the relatively small amount of time since the last post, I have touched very large portions of the code. So I'm sure some stuff I did broke something I won't notice until after release.

Anyway, I'm calling all the code done. There is nothing left on the code todo list (that is worth doing), except for like one thing required to display the logo on the end screen... when I... make the logo tiles. There's also some stuff I might still change based on tester play, but they'd be like... change a number kind of things, not tread on eggshells hard stuff.

After I sleep, I will be trying the game a lot just to be sure I didn't do something really dumb and obvious with the recent large changes. Then I'll communicate with test people again, so if you want in on that and haven't already hit me up, now's the time to ask.

Tomorrow, I (finally) start the remaining tile work. Assuming testing doesn't go horribly wrong, it is all that remains.

Graphics finally started. (And like everything else, not on the day I actually said. I found a bug that I thought was huge, but it was nothing and only revealed a very small animation error. Now fixed.) I played through the game 30 times and nothing bad happened so now some people have it.

So that Indivisible game has a very not pixel friendly logo... It's part of why the title in the very first ROM was so small. It minimized tile count. (39 tiles.)

That's 115 tiles, basically half the budget. Which would be less of a problem, except there's also like... a whole outdoor area associated with the title screen. It may be possible to get it down a bit without changing it just by shifting it.

I really don't want to go back to the tiny logo, but if things end up tight I may just remove the ornate rings and such. I could also just do advanced stuff to draw more than 256 unique tiles, but that is similarly complicated by this being an area and not a static screen. I'd rather not mess with that this late in the game.

Some of the letter spacing is to save tiles, though it was shifted to then try to save on the circle.

The 'i's used to be right bound for reuse, and shifting up could make all the purples match. I'd rather keep the circle where it is in the original game if it stays.

No worries, I don't mind replies.

It's all in the background right now, but it could be split between background and sprites if it got really dire.

It's now 103. Aligning how I originally had it ('i's rightbound) seemed best tilewise after all, but other cute changes were made.

The top left of the 'd' now shares a tile with the top left of the 'n', the top of the fire was moved a pixel left (that one pixel was the only thing in its tile in the before picture). The 's' also got pushed further left so the third 'i' could share the bottom tile with the first two. Also, I filled in the second 'i's top, which is technically not "correct", but looks better to me.

It's possible to design the bottom edges of the circle and those... things on the left and right to share tiles, but I won't really know how I feel until the tile demands of the mountains and trees start to become clear.

Consider the S killed!

So, the graphics were done, but I ended up not liking how one of the sets turned out, and then slacking on redoing it. I'm going to try to force myself to commit to a plan for that problem set tonight, because realistically I can't tweak it forever.

There's software called Pyxel Edit, that lets you make tiled backgrounds somewhat easily. If you draw on a tile that's reused, that tile is updated everywhere you use it in real time. Here it is working on the font.


Note the E is updated everywhere instantly.

It's very useful to reduce tiles, by copying similar ones and drawing on them until they look good in both unique places. Here's the temple tileset:

Note that at the beginning when I draw on the solid gray tile in the relief around the sculpture it also affects a brick to the right. Now solid tiles are easy to reuse, but you can also work on one tile until it links to many different kind of things:

(Obviously a quick example just for the gif, but that tile was worked on with more care in this exact way to get what it currently looks like)

NES can have 256 background tiles in memory at a time (there are ways to draw more in a scene, but let's not cover that now). Pyxel Edit helps a lot getting rid of single use tiles to get under this count.

However one thing Pyxel Edit does not do is care about palettes. Look at the gif with the full statue again. Notice that there is a solid red tile (on the top and bottom of the column by the window) AND a solid gray tile. Depending on how the palettes are arranged, those two tiles could be one. (NES tiles aren't stored tied to specific colors, just different ones. Think of a paint by number page. All the 1s are filled with a color, and the 2s are filled with a color etc. But WHICH color isn't part of the original paint by number page.)

If you have just 4 solid color tiles in the set, you can display them 13 different ways in the background.

Pyxel Edit would say that is 13 tiles, NES would say it's 4. If I had a solid color tile of the darkest blue, it could also be used to display the white or red or greenish-brown.

So Pyxel Edit's tile count is usually a little higher than NES', but that's fine. Once I get close to 256, I run it through my own software which does respect palettes to get a real count.

What ended up happening with the "problem" set, is that I struggled quite hard to get it under 256 according to Pyxel Edit. When I ran it through my tool, the count was 233, leaving about 23 extra tiles of wiggle room to play around in. It was a bit frustrating, because I already committed to worse structures to get under a limit I was apparently already under.

So... now I'm redoing it and checking more often. There are a couple of programs that let you do what Pyxel Edit does AND respect palettes, but... quite simply I don't like them more than I don't like Pyxel Edit.

This one tileset (the last tileset) has been the holdup. The next update is either it's done, or the game is done depending on how quickly I finish it.

I'm not home, because last Thursday was an interesting day. All the graphics are done, really the whole game is except some color stuff for the newer graphics. (See "why aren't the colors final" in this post) The game has been in this "done" state since Thursday.

Testers who have access, hey, redownload it! I snuck up a new build.

I need to look at the color stuff and the game in general on real hardware, and I don't have a way to do that at the moment, so hmm. That and some promotional materials are all that's left. I hope to be home in a week at latest. I'm gonna try to make a trailer thing which could take some time, I'll also sit on it a bit just to really make sure I didn't miss any problems caused by the new graphics.

If the world doesn't have this in #twoweeks, I'm going to go nuts.

I was away for about four days longer than I planned. The two weeks passed, I'm nuts.

Maybe trailer was the wrong word. I needed a tiny thing to work on twitter, with the goal that it would not be destroyed by its compression. (A <15MB GIF, not mp4 for the looping.) Anyway, I did it.

Here's a cropped piece of it:
http://i.imgur.com/MemBJhC.gif (Linked, so as not to add 3MB of loading to this page)
It also has a download link and such, which isn't public yet. So the game is done, the accompanying documentation is done. (Maybe? There's only emulator setup instructions for Windows, not Mac or Linux.) The download page is done. My two promotional giffy things are done. I'm waiting on a couple of things, but I think I'll hit the button to release this on Friday, (#fanartfriday :P) regardless of how those things pan out.

"Indivisible will NEVER be done."

I've been saying that for months, whenever anyone I knew asked me how this was going. I kept thinking I was close, but I was never right. So that seemed like the best answer.

Kinda weird that now it actually is done. In some world where time wasn't a factor, I'd probably keep working on it. But... hah, the big things that would make it better at this point require more time than I'm willing to put in.

You can follow me on my barely-there twitter: https://twitter.com/kasumidirect But I'll also post here when you can grab it. Know that it's certainly a short game for how long it took. T_T Cya Friday... (or... earlier?)

It's out! You guys are my first call (except twitter)

https://kasumi.itch.io/indivisible

If you like it, consider retweeting one of the two tweets. We've got a trailer tweet comparing the two games:

And an animation tweet to catch pixel artists:

Know that the game is a bit harder than I'd like, but I believe in you all! I'll update the first post in a bit, there's a lot of places to post...

Edit: The link is right, I promise. itch.io just seems to... randomly give 404s for it? Trying to get that fixed.

Whelp, it did alright. @SkullMan has been rocking it with youtube playthroughs. This one shows a secret, so don't watch if you don't like spoilers:
I think in about a week I'll release a video with my best time. I still kinda plan to do some post mortem writing, but there's some stuff in life I need to take care of first.

Does anyone have any clear times? Or is everyone dying to the boss? :(

Well, in keeping with the theme of this topic, when I say "about a week" I mean "about a month." Here's the speedrun video!
(The death is intentional.) I guess even its title is a spoiler 'round these parts. ;) There's still something hidden. Maybe I'll spoil it eventually if it's not found. (Testers... shhhhhh) I still do want to write more development posts. Trying to clear up some time for it.

I did make a really successful NES restrictions tweet on twitter: