Tuesday, January 9, 2018


finally finished the tower d project, and i'm just waiting on steam to give the final review. i should be taking a break before the next school semester starts, but it just feels wasteful to be doing nothing?? next project's likely going to be a 2d action game in unity. no way am i using the laggy pos that is rmmv. lol so i've just been learning how to animate things in unity (even though i'm hoping i won't be the lead artist/animator).

Sunday, November 19, 2017

really notded

Redid the menu skin, and applied the same fading/sliding transitions to every menu screen.
gotta change that menu selection cursor, too.

If I'm going to be this far behind schedule thanks to school, maybe I should work on revamping the VFX, too.. So delayed.

Wednesday, September 27, 2017


alive (and basically on the last leg of dev?)

Friday, August 11, 2017

Copierre, progress

Area 2's technically complete (missing art assets and things haven't been recolored/polished), and working on area 3 atm.

Thursday, July 27, 2017

Copierre - demo?

itch.io link

After playing through the deployed version, it seems to suffer a LOT more performance issues than when playing it in RMMV. This might be an issue..

Sunday, July 23, 2017

Copierre, Bugfixing

RMMV makes use of on-the-fly loading very often. It leads to a bug when using Window_Base.drawFace() often.

It has to work this way, since it needs to account for any possible face image, but I already know for sure I'm using a single image each time, so I just load it once, and store it as a local variable. caching? preloading? something.

It helps with the frame hit when opening the menu, and solves this bug where my summoning menu wouldn't draw the faces at all.

I have a feeling I'd eventually want to do this sort of preloading/caching for every bitmap I use, because the asynchronous loading is pretty ugly.

Wednesday, July 12, 2017

Copierre, Damage display

I'm quite a fan of RO, so I made the numbers pop out in a similar manner. The x speed is determined by the angle of attack from the player unit to the target.

Right now, I have the most trivial implementation of this, though. New window objects are created and added to the scene whenever damage occurs. Once the window's faded out, it's then removed from the scene. This leads to very noticeable performance hits when several windows are constantly being created and removed.

This means my next task for these is to use a smarter implementation. I'll probably retain every window created, but if it fades to full transparency, then I'll mark it as usable, and then re-use it when damage is dealt elsewhere.