Well, for once something I thought would take a week actually took a week! The intro came together pretty quickly since I had it all planned out, and I had most of the timeline together within a day or two. I had to create a couple of extra assets for background elements, and create a little bit of architecture to control how it starts and finishes, but all in all creating the intro went remarkably quickly – disregarding, of course, all of the time I’d already spent on making illustrations, each of which is visible for approximately 2 seconds in the intro.
[youtube https://www.youtube.com/watch?v=2cgYFbYl5Y8&w=560&h=315]
There will probably be a few improvements made to this in the future, but it’s definitely close enough to what I want that I can feel comfortable stating that I’ve definitely made a discrete chunk of the game – admittedly, one without any gameplay, but not a terrible start. Now, whether one ought be satisfied with “not a terrible start” after working on a project for half a decade is, ah, a question we will bypass for the moment.
After creating the intro, I fell down a sort of technical rabbit hole. After the intro plays, the game proceeds to the first area – however, the question of how that happens is one I hadn’t wholly considered, and one that could potentially have big ramifications. Right now there’s only one or two rooms in the project, but by the time the game is complete it will probably have a few hundred, each of them full of high-res assets. This is potentially a huge technical issue, and if I don’t figure out a good approach to it could result in big problems with memory usage and load times. I built a system for loading each room in separately as needed, that will load each room quietly in the background whenever you’re in adjacent rooms – however, I don’t actually know if it works yet, because I don’t really have rooms ready to test with.
Which brings me to the last thing I ended up working on this month. If I need rooms to test the loading of assets, I need assets to put in the rooms before I can test – so the last week or so was spent on drawing textures for the insides and edges of Unity’s sprite shape, a tool for creating arbitrary 2d terrain shapes. So far I have working sprite shapes for rough rock areas, smooth rock areas, dirt/mud areas, and grassy areas. Some of these could also probably use some improvement, but they’re at least nice enough to start planning areas out.
Afterwards, and for the last couple of days, I’ve been getting into the weeds of color-processing. A rock sprite shape is nice and all, but it’s very inconvenient if I need to create a separate asset every time I want to change the look of an area. While the default sprite renderer has the ability to tint the sprite any color, this is an effect which can only make a sprite darker – whereas if I have the full range of control offered by hue/saturation/brightness/contrast sliders I could change the render in a lot of interesting ways. The math behind this stuff is fairly straightforward, it’s just a pain to implement – but I’m most of the way there now, probably a couple days of work left to go.
Next month is going to be about finishing the color transform code and creating a few relatively complete rooms to test room loading. I hope to be there within a couple of weeks (though I keep on finding problems that need to be fixed and promising side-paths), and once that’s done I can work on building the entire explorable area of the first chapter and creating and implementing all of the basic character movement animations (run, jump, crouch, roll, and other transitional states between them). This is probably more than enough to keep me occupied through all of August. We’ll see if I can get there.