Production Log

Admittedly, I am very, very late to production. I wanted to avoid this, but one bad week lead to another and I found myself struggling. Particularly, I found myself in a pretty bad rut mentally during Week 10, even though I intended to use that week to start on production. At this point, I'll attempt to readjust things heavily in order to make this project manageable within this time, but I'll go over that in more detail in the weekly review.

TARGETS FOR THIS WEEK (DIFFERENT FROM PLANNER): Basic Character Spritesheet, Soundtrack

To start off production, I'll be working on the main character's spritesheet, using the redesign concept art and the animation concept sheet that I drew up not long ago. I've found through research that the Kirby series is a good place to look for inspiration, and so I'll be somewhat taking some influence from the artstyles of certain Kirby games.

I was initially planning to take some influence from the Yoshi's Island series, but I found the art style doesn't quite 100% match what I want, at least in the case of the main character.

I started off by building the palette, as I do whenever starting a sprite. I've found that having an idea on what your sprite's colour palette will be can somewhat affect the way you sprite, so I always make sure to set one up first thing. I went for something not too big yet not too small. A little larger than what I aim for when it comes to personal sprite work, but it works out in the artstyle and it doesn't exceed that mark very far. I went with soft, pastel colours as opposed to the 2022 sprite which had much brighter, vibrant colours.

The decision to switch to more pastel colours overall is both due to personal preference and because I feel it better fits with the tone of the game. While vibrant colours in games can definitely create a fun, colourful, and childlike feel, pastel colours do it in a much softer, dreamier way that is much more fitting for a game like this, and I feel they do more to sell the game's artistic themes. They are calm, easy on the eyes, yet still evoke a sense of fun and childlike joy, while stronger colours are more punchy and distracting and in your face. In a way, I also believe pastel colours fit the main character's design and personality too.

As spoken about in pre-production, I already had a colour scheme for this character which I felt didn't need changing. It was simple and effective. Very light, creamy off white, pink, and an almost mint green, which along with similar blue colours often compliment these kinds of shades of pink. For the sprite's palette, however, I decided to specifically base it off of schemes like this, which I had found while debating on the character's colour scheme.

Moving on, I made a quick sketch for the sprite. It really doesn't matter to me whether my sketches come out rough or not, but this one in particular was pretty clean and fleshed out, so it ended up being quite reflective of the final product.

There wasn't much to talk about here. The process was very straight forward with little iteration. I did a couple silhouette tests, and they seemed satisfactory. I'm pretty happy with how this turned out. It's simple, fairly animation friendly, not too cluttered, so it's a good translation from concept art to spritework and it proves the small redesign done in pre-production was effective.

Next was to move onto animation. In pre-production, I went over a little animation concept sheet I made to guide me through the animation process. As I said there, one of my primary aims with her new animations is to prioritize proper characterization. One of my issues with her original, 2022 design is that it didn't portray the dominant parts of her personality well enough, sort of emphasizing the more negative or comical traits more and almost making her look like a "scraggly, skittish, hyper-alert animal", and her in-game animations were often quite generic and didn't do much to balance out the aforementioned design issue.

I started off with the walking animation. Weirdly, I didn't take a progress screenshot for the first frame. Regardless, I regularly exported my progress as gifs to share with friends and receive feedback, which works out as an effective measure of progress.

Using the animation concept sheet as a guide, I blocked out the keyframes, or major poses, first, a common practice in animation. 4 frames consisting of the contact pose, the pass pose, another contact pose, and another pass pose.

This was sketched out with the final animation in mind. Even in this simple 4 frame loop, you can see I set up a subtle sway in her arms. Thankfully, to the people I sent this to, this detail didn't go unnoticed and it got the reception I was hoping for. I took some screenshots of this feedback and labelled myself.

Next, I made the in-between frames.

Going into this part, I was very cautious not to ruin that subtle bit of characterization. The process was obviously very simple, so I didn't really get much progress screenshots.

So far, I think this is flowing really well. It's fluid, it makes sense, and I managed to somewhat keep that subtle sway. The rest of this was just colouring it, some details, animating the scarf, and a little bit of polish.

There wasn't much trouble through this, but I did come into an issue when animating the hair. I had gone into it with something too complex and found it didn't flow well or really make that much sense, so I decided to settle for something simpler with more subtle hair movements.

Simply, rather than going through continuous, unique movements, the hair bounces slightly in the first 3 frames and that movement is copied to the last 3 frames. This worked a lot better, as something more visually complex would go unnoticed and it just wouldn't be efficient or worth it going through all the extra effort for something so miniscule. It achieves fluidity without overdoing anything. Also, it just makes more sense. Her hair shouldn't be going through ridiculous amounts of movement from a simple act like walking.

Since this was a more minor part of the process, I didn't really get that many progress screenshots. These gifs somewhat make up for that, though.

With the walking animation finished, next, I'd move on to the running animation. Between that, however, I asked my close friend, Iyani, which had previously composed for some of my previous projects, if she was able to get started on some tracks for this game. Of course I won't be marked for this in specific, but it's worth putting here just to track progress.

I reassured her that she wasn't in any particular rush to make these tracks since they wouldn't be graded and they're purely optional. If anything, I'd just reuse the tracks she made in 2022. Regardless, she delivered, and very quickly.

I wanted to put the focus on two tracks specifically, the Title Screen track and the Level track. I had two references/inspirations in mind for these tracks.

For the Title Screen track, I wanted something like "秘密のレシピ/Secret Recipes" from the game "Hatsune Miku: Colorful Stage!", and for the Level track, I wanted something like "Daffodil Petals" composed by Toby Fox. I've linked these songs below.

First, she composed the Title Screen track. Funnily enough, when this was sent, I almost thought it was supposed to be the Level track since she had put so much into it and it seemed like a sort of mix between the two reference songs. She pretty much nailed the feeling I had in mind, and I've found myself listening to the track a lot whilst working.

When it came to the Level track, however, she seemed to really stray from the reference song I had given her. She had told me she wanted to try out a Japanese "City Pop" kind of thing. This time, she was streaming her work to me through Discord, so I was able to lead her and give feedback in real time.

When she was starting off, I got a little worried that it was gonna derail too much and end up not fitting. That it'd end up straying too far from the tone I want to achieve or maybe turn out too complex. She's had the tendency to do that in the past. But in the end, it turned out really good. She had managed to make a song that fits within the level in its own, distinct way, and in ways I didn't account for. I particularly liked the sort of sparkly feel the new direction brought.

Here are the tracks.

With that out of the way, I'll be going over the running animation.

I was looking forward to get started on this. The 2022 equivalent for this animation was not only really generic, but it was generally just weirdly animated and weirdly sprited, as a whole but also in proportions. It also just didn't really flow well at all. It looked jarring with the other animations.

Unlike the walking animation, the pose is quite a bit different, so I made sure to sketch the body as I would a new sprite. This time, I got quite a few progress screenshots, but I didn't export as many gifs.

Like the walking animation, the process was quite straight forward. and pretty much the same. I blocked out the main frames, set up the arms swaying in a slack, clumsy kind of way, and then did in-betweens. On that, actually, I recall saying on the animation concept sheet that I estimate the running animation to be less frames than the walking animation, probably around 4 frames as it would be a faster action. This didn't last very long. 4 frames alone wouldn't look very good, and so I settled on the same frame count as the walking animation, 6 frames.

On a side note, I did somewhat struggle with getting the expression right, and I remember switching between two variants a few times before settling on this. I thought it looked cute and funny.

Having learned from the walking animation when it came to animating smaller details during polish like the hair, I had a much easier time and was able to get something good first try. Not too complex, but definitely more than the walking animation's hair. It is more similar in complexity to the initial draft I had for the walking animation's hair movement, but it makes more sense in the context of the character running and it was made in a similar way to the final walking animation's hair, in that the hair movement occurs in the first 3 frames and then is repeated exactly in the last 3 frames, which helps it flow a lot better.

The flowing scarf was easy. I have nothing to say there. Animating flowing fabric like this often comes easy to me. It looks pretty satisfying, I think.

From there, all I had to do was to shade and detail.

During this process, I wanted to utilize anti-aliasing effectively in the arms to convey subtle movements and make it look fluid. That alone isn't notable enough to mention, as I do that anyway, but during this, I had actually changed the shape of the arm in one of the frames as I felt it'd work better. I also just generally used this process to smooth out and tweak the arms in each frame, albeit in more subtle ways than the instance I just mentioned.

The final animation turned out really good. I'm really proud of how it came out. Compared to the 2022 animation, it's worlds better in spriting and animation. It flows better overall and feels like a better, smoother evolution to the walking animation.

WEEKLY REVIEW 1

TARGETS FOR THIS WEEK: 

Basic Character Spritesheet, Soundtrack

WERE THESE TARGETS MET?: 

Basic Character Spritesheet - Not yet. 3/5 animations complete.

Soundtrack - Pretty much. Other tracks planned, but they're optional.

MY THOUGHTS, WHAT WENT RIGHT, WHAT DIDN'T: 

Start of production. Very late, way too late, and of course, the pressure is weighing on me. It's nothing I haven't felt before, but it's not something I'll get complacent about and take less seriously because of that. The quality of the work produced this week is satisfactory, I believe. I'm confident with it. I received plenty of positive feedback from people who I shared with, receiving mostly confirmation that my aims were met and that the artwork was received positively, and no particular criticism or feedback on what I should change. Pre-production/planning work proved useful and found appropriate application, same with research. As mentioned, only 3 animations out of 5 in the basic sheet were completed. I'll be talking about what I class as the basic sheet later. As for what didn't go so well, quality wise, I don't have much to say. Quantity wise, though, if I had started work earlier and been more consistent, I would have gotten a lot more animations done I feel. That's something I wish I had done. I'll be taking that into account going forward.

GOING FORWARD, MY PRIORITIES:

To address what I class as a basic sheet at this point, pretty much everything absolutely necessary to movement. Nothing cosmetic. I can do without a hurt animation or a double jump animation, and the paint mode animations would have been something else entirely. I want to be very careful with what I take on, so I'm keeping a mental record of my priorities, shifting in real time based on what I've got done. Right now, I'm placing full priority on the basic spritesheet, the tilesets, and the GUI. Those feel like the most important elements to start with. Then I'm shifting all focus onto programming a complete framework of the game, implementing the player, components such as collision, the level design, and then I'll consider everything after. Right now, I'm not so confident, but I have a few weeks and I intend to make the most of them.

Next week, I intend to finish the player spritesheet and start on the tileset and GUI. If luck has it, I may also finish the background and get started on programming then.

With the start of this week, I quickly continued with the basic character spritesheet. Next up are the Jump/Fall animations, and that should be no sweat at all. Here are my targets for this week, as I spoke about in last week's review.

TARGETS FOR THIS WEEK (DIFFERENT FROM PLANNER): Basic Character Spritesheet, Level Tileset, UI Sprites, Hopefully Programming Start

Since the jump and fall animations are gonna be easy, I have confidence that I'll be able to start on the level's tileset, maybe even the background and UI. As for programming, I'm not sure...

Regardless, I'll be noting my progress now.

I started off by sketching out the jumping pose. One thing I should note that I'm trying to be conscious of as I sprite, I don't want to make the sprite canvas size too big. This is something I struggled with in 2022. There were a few sprites that way exceeded the bounds of the idle sprite's canvas size, and since I'll be switching between these animations in game, I have to make sure they're all exported from the same canvas and under one consistent, universal canvas size. I've done a pretty good job at managing this so far, and I haven't gone over too much.

I sort of struggled with getting the proportions right in this sketch, but I managed.

So far, I've had a feeling I'll have to change this one a bit before I'm fully satisfied. Nothing too much, though, but something about her looks a little off.

And there it is. That's what was bothering me. Primarily, the face. I had tried to do some kind of perspective thing or something with the glasses, making one of the lenses smaller, but it just didn't look very good. The hair looks a little strange, too. I cleaned both of those up and it was looking great already.

There's not much to say about this one. It's a one frame animation, like the idle, and I didn't go much into that either. I'm pretty happy with it. I ended up changing the mouth a little from the original concept sketch, as I couldn't really make it look good in sprite form. It's a really small change, just going from an "ah" to an "oo" shape.

Now it's the falling animation's turn. Final one. I plan for this one to be a 2 frame loop at most. I went into it a little worried, but I managed to execute it well. Unfortunately, I didn't get very many progress screenshots... I could have sworn I did, but it seems I went full steam ahead. I only have these and some recountings of my process.

I struggled a little with the shading on the hair. That I remember. It was a weird approach I wanted to take and so it took a bit of effort to make look good. But it ended up working out in the end. The second frame wasn't much trouble, and I'm happy with how it ended up looking altogether.

Anyway, with that out of the way, I can get into the not so brief part. The tiles.

For the making itself, again, it was mostly full steam ahead. I didn't get many progress screenshots, but at the same time, I didn't want to be excessive. There's probably a balance I should meet.

Going into it, I had a rough idea for how I wanted the tiles to look. In the pre-production reference image board I made for the level's design, I had included a screenshot of Sonic CD's Palmtree Panic level. Since that was the base inspiration for the level's design, of course I'll keep it in mind when taking on the spritework. However, I didn't want to just stick to that. Two other reference points came to mind, Stargrove Scramble and Kirby Mass Attack. Here's another little moodboard I put together.

I initially imagined something bold and vibrant like Sonic CD, but I might have to tone that down. Maybe find a sort of mix between bright and soft. I imagine the tiles to look big and bold and a little chunky. Very defined with a natural shape. A little bit like the tiles in the Stargrove Scramble and Kirby Mass Attack images. The tiles I made in 2022 were very flat, sort of confined, flawless in shape, 

ended up making the environment look a tad boring and safe.

I first built a palette, as I usually do. I'd later expand on it.

And then, I got to work. I'm working with 20x20 tiles.

With tiles, I don't usually sketch like I do regular sprites. It's not as necessary in a lot of cases, unless it's a defined object or structure. I quickly got a good shape going, much better already than the tiles from 2022. 

I debated on how to make the shadow from the grass look for a bit, and ended up settling on just a simple one colour wave for the sake of simplicity and keeping things neat. It didn't take me very long to finish the base ground tiles. I'm very happy with how they turned out. Things are promising.

I moved on to slope tiles. It's at this point I'm glad I know my limits sometimes, because I did struggle with this and I think I would have struggled a lot more had I decided to have different levels of steepness like Stargrove Scramble and Sonic CD for example. I didn't take many screenshots here because I was focused on just making it look good.

There's quite a bit of Kirby Mass Attack influence in the way I did the slope tiles, but I feel it'd look like that regardless. It took a while to get something I felt looked natural, and I ended up chipping away at it for a bit.

With the slope tiles finished, that was pretty much the base, necessary ground tiles. From then, I wanted to make some slope tiles for the dirt without any of the grass, as well as a single tile variant of the ground tiles for use in Paint Mode. That was the more major of the regular tiles I had planned, the rest were simply just a single colour tile and a darker dirt tile for use in walls. This didn't take much at all. It was all very simple edits and I got it out of the way quick. Not much to say.

Now it was time for the more decorative tiles. This is where the Sonic CD style influence is at its highest. I wanted to start with these two elements, as I feel like they're the most visually complex and distinct. Regular decorative plant life can wait until later since it won't take as much time and it wouldn't take too much from the level overall.

For the light pole, it was a simpler process, but I'd end up making quite a few tweaks as I went on, even as I started on other stuff. I got a few progress shots, so I'll just throw them down here in order.

One thing I struggled with a little was the shape. The 2022 equivalent was very basic, so I wanted to do a weirder shape like the sketch on the right. But that was a bit of a hassle. Regardless, it didn't slow me down much, and I can't complain about what I ended up with.

I did some tweaks later on, as I said, so I'll put the current final iteration as well as an alternate version here.

As for the tree, that one was a little bit of a more complex process, and it took more effort, but once it was done, it was done. I didn't take very many progress screenshots since I was very focused on getting it done and making it look good. In fact, the only progress screenshot I could find, I had already started on the leaves...

There was a bit of struggle with the lower half of the tree. Especially the segment that bulges at the bottom. The "pot" or base changed styles at some point. It was initially a simple, solid colour much like the one on the light pole, but I had changed it to resemble similar objects in the Sonic CD style. I believe it added a little bit of visual interest.

Additionally, I changed the base from a purple to a gold as I felt it would look better overall, but I'm still not 100% on it.

Here's the first progress screenshot I got. Just me sketching the leaves. As I said in pre-production, the leaves are supposed to resemble the tail of a shooting star symbol, leading to the star fruit in the middle. I didn't have a very concrete, symmetrical order for these leaves, so I had to quickly improvise one, also resulting in a slight design change from concept art to sprite which I think works very well.

The leaves were kind of a pain to do. The shading and lighting in particular. I had a very specific way that I did it in 2022 which, if the leaf shape were the same, I could improve on tenfold, but because of the more abstract shape, I had to think of something different. To compliment the shooting star shape, I did something kind of streaky, especially for the shading, and then added to it with the lighting. It took a while to make look good, though, but when it was finally done, I was really proud of it.

The star in the middle was no problem at all. I wanted to make it gem-like, sharp and angled. Another small design change I made was the addition of two smaller stars below the large one, different growths or fruits of some kind.

And that was pretty much the tiles out of the way. On to the background.

I initially imagined myself going into the background with new colours, different from the ones in the final concept in pre-production. However, I've found they work well enough on their own. I started off by simply testing how the tiles would look laid out in the game's resolution.

From here, I'd begin translating the concept art to final art.

Again, like with the colours, I imagined there being a significantly cleaner, more detailed look to the final art than in the concept art. However, looking at the concept art, I found that the slightly messier, simpler look had a certain handmade appeal which would add a lot to the area's design. This wasn't intentional, but it sort of links back to the Kirby and Yoshi's Island influence that I've spoken about in the past, as they both tend to have very handmade or hand-drawn art directions.

Of course, I won't be able to achieve the exact feel that the above images have. I feel like I'm not quite yet at that level and it might hinder my progress and wear down on my time if I worry too much about making it LOOK like an acrylic painting. I feel like it'll do the job either way, and it'll be something to work on after this project is said and done.

I started sketching, using the concept art as reference. I tried to replicate the blotchy look for the sky that I had in the concept art. It was very directly influenced from the look of acrylic paintings, how certain things are painted in the ones I picked out and outside of those, so I felt like, if anything, I'd have to get that right to properly get across what I want to get across for this level.

I didn't quite get it exact. I'm chalking it up to the fact that I was trying too hard. I feel like it's a little overdone as opposed to the slightly more natural look in the concept art. Of course, I'd end up tweaking it plenty of times, so this current look isn't final. It's definitely worth mentioning that I think a lot of aspects of the background design, things like the shapes especially, end up feeling more natural in the concept art. I feel like that's a by-product of the fact that it's all sketched with less care and direction, and that it's harder to replicate natural looking shapes, the asymmetry and randomness of nature, when you're following a very strict and set base like what I'm doing. That's one complaint I have, writing this with hindsight.

After getting a rough base for the sky, I blocked out the mountains. Again, trying to match them to the concept art. Same worries with it looking more unnatural in comparison to the concept art. I had to tweak the overall shape a lot too, which definitely added on to the issue.

In-game, the sky will stay still but the mountains and the forest will move in their own layers with parallax scrolling. Because of this, I don't have to worry about drawing anything over the game's resolution for the sky, but I'll have to exceed the canvas width of 320 to add more to the mountains.

The sketch was coming along well. I cleaned it up a little bit and added some lighting. I struggled a little with this part. The lighting on the mountains is one of the things that I felt would benefit from being drawn with care and intent. While it looked cool in the concept art, it wouldn't really make much sense in final art, so the complaints I talked about earlier weren't really the issue here. Honestly, I mostly just struggled with making it make sense. In the end, though, it turned out alright, so I can't complain much.

I quickly added on some structures in the background, and then exported it in the game's resolution just to see how it'd look.

I do have one complaint here. I really don't like the look of the structures very much. Especially and particularly the bridge. I don't like how it turned it. It's weirdly sprited, way oversized, and it looks out of place. I feel like there are ways I could make it better, but I really don't want to spend a lot of time as there's not a lot of that which I have at the moment. I settled for simply tweaking it later on. I've learned over time that often, when working on projects, I need to set aside my perfectionism and prioritize simply making a presentable final product, especially when working under time restraints like this. Perfectionism would have me putting too much time on aspects that are overall not very important, which then leads to other, more important aspects coming out barebones and looking worse than that smaller issue would have made it.

From here, I didn't get many progress screenshots as I was full steam ahead. I added shadows to the mountain and then got to work on the forest. That latter part took up all of my attention, as I had to be very meticulous with it. However, since the forest layer was made of smaller details rather than large shapes like the mountains, I was able to get away with just keeping it at the same resolution as the sky layer.

Some extra polishing. Nothing much to say now as my work on the background was coming to a close. I initially detailed the forest layer by hand, but then found that copying and pasting different segments from the top, changing their colour, and placing them around the lower half provided a better looking result at a fraction of the time. I did still keep some unique, hand-drawn details to make it look more natural.

Finally, the background was finished. I exported it in the game's resolution after fixing up the sky layer a little.

Honestly, despite some of my issues with the individual parts, I think all together it came out really good. Visually, the game is coming together great, a lot better than it did in 2022. To quickly address it, I decided not to add a sun as I felt like I couldn't execute it well enough, but also to make sure the screen stays uncluttered. There's somethings I wish I could do, but again, I have to make sure to keep my perfectionism in check.

Finally, it was time to move on to the UI elements. In pre-production, I only sketched out a concept for the HP display and Big Coin display as I felt like the rest of the UI would be pretty straightforward. I had a rough idea in mind for what everything else was gonna look like, anyway.

To compliment the game's themes, the HP display is supposed to resemble splodges of paint on a palette, and everything else is gonna have a sticker or cut-out appearance. Simplistic graphics with sharp and bold outer lines that makes them look cut out and pasted on to the screen.

I started off with just the text. Nothing much to talk about here. I wanted the text to look bubbly and fun. In the 2022 version, it was weirdly sharp and angular looking, aside from just being weirdly sprited, so I wanted to move away from that as it obviously doesn't really fit with the game's tone.

Then, onto the HP display. This is probably the most visually complex UI element on screen. I'm honestly not entirely sure if it'll stay that way by the end of the project since I don't want too much contrast, but at the same time, I want to be able to communicate that it's paint.

I made them look irregular and wonky, made sure to draw unique hearts every time rather than reusing any. I wanted to have a smaller palette, but I had to add a white to properly convey the glossiness of paint.

I don't have much to say about the smudged icons for when the player takes damage. I had a very particular look I was trying to go for. Splodgy, rough, sort of angular a little bit, with these overlapping colours, and with each smudge continuing seamlessly onto the next. It looks the best in the first smudge, but the others don't look bad either.

From this point, everything was pretty straight forward. Nothing too notable to say about the Coins and Time UI, and for the Big Coin display, I simply had to draw a dotted circle. I did like how the Coins and Time display turned out, though. I feel the cut-out look has a nice appeal.

I placed these UI elements over the mockup I had earlier to tie it all together, with the same placements as the 2022 version and the concept art.

Things were looking good. The game was coming together visually very well. However, I couldn't shake the feeling that this UI placement felt a little off somehow.

So, I made a variant. A very simple change, simply moving the Big Coin display to the bottom left of the screen. I sent it to some friends for feedback, asking which one felt better.

As I expected, people seemed to react well to the variant. Consensus was that placing the Big Coin display in the bottom left was a better use of the screen space, and that it looked odd and cluttered in the top right, and those were my thoughts exactly. So, the variant was final.

To spice things up a bit, though, I decided to look into ways on how I could make the Big Coin display feel even more natural. This one didn't take long. My first thought was opacity, and while that definitely does help, I wanted something else. So I looked into blend modes.

I was aware that GameMaker Studio allowed the use of blend modes. But I also know that Aseprite and other common art programs have a lot more options than GameMaker. I believe there are more advanced blending options that GameMaker allows you to use, but that's above my scope and not something I want to spend too much time on. So I quickly looked into what basic blend modes the engine offered.

I decided to try the Additive blend mode and I thought it looked the best.

With that, the UI was complete. Here's the final mockup.

WEEKLY REVIEW 2

TARGETS FOR THIS WEEK: 

Basic Character Spritesheet, Level Tileset, UI Sprites, Hopefully Programming Start

WERE THESE TARGETS MET?: 

Basic Character Spritesheet - Complete. 5/5 animations.

Level Tileset - Necessary Tileset complete.

UI Sprites - Complete.

Programming Start - No. I was unable to start.

MY THOUGHTS, WHAT WENT RIGHT, WHAT DIDN'T: 

Good week, I think. There was a lot of stuff done. I've pretty much cleared the most important and necessary visual elements, which is a significant milestone. A lot more was done this week than last week, but of course, there is still work to be done, and I could have done a little bit more to push myself. Regardless, I did manage to get a good balance with quality and quantity. Work was positively received by peers. I received both positive comments and criticism, and I acted on the latter quickly. Though the quality of certain aspects bothers me, I've learned to set aside my perfectionism in order to better ensure that I'm able to deliver an overall good quality final product on time. Setting this aside proved to be the right thing to do, as despite my smaller nit-picks, when everything was put together, it came together well. Like last time, pre-production and research was very useful. I ended up adapting and changing certain things I had planned to better work as final assets. Already, this is showing how far I've come with my creative process in just a few years. Compared to the game in 2022, this looks miles better. It has more intent, direction, it feels more developed. That final mock-up feels like a screenshot to a real game that can be played, while I can't exactly say the same for the 2022 version. I have hope it'll get even better from here. I just have to keep this up.

GOING FORWARD, MY PRIORITIES:

My priorities have stayed absolute. Going forward, I'm side-lining artwork and prioritizing programming. That feels like the best way to go about this at this point and with this little time left. Even if I'm unable to finish the game, getting even something playable LOOKING will allow me to quickly shift my priorities last minute and settle for an asset showcase and a few short clips or a trailer, dressed up in a pretty way. Since I wasn't able to get started on programming this week, obviously, next week I will. I'll be focusing on establishing a solid framework for the game, and then the specifics come after. I doubt I'll be able to get things such as playtesting done at this time, so that currently is not in my priorities, but we'll see what happens. I do have faith that I'll be able to get something good, but I'll need to keep an eye on time.

It should go without saying. This week, I plan to get started on programming. I can be pretty quick when it comes to programming, all things considered. I've done this several times before so I've got a good mental reference for decent player code, and with the most important visual aspects out of the way, I'll have no problem.

TARGETS FOR THIS WEEK (DIFFERENT FROM PLANNER): Programming Start, Basic Player Framework

After exporting each player animation, I started a new project file and dragged them in.

As I usually do, I exported every left facing and right facing variants for every animation. I've found that having separate sprites for each direction and then switching between them alongside animation is a little bit easier to deal with than flipping the player sprite through code, and I've had less issues doing so.

Additionally, I created a simple 20x20 graphic for use in solid collision objects.

I got to work on the player object. This contains the code for the player's movements, the inputs behind them, the player's animation, how the player collides with different objects like collision objects, etc. I'm taking a bit of reference from some previous code I had written since I find it pretty decent and it works well enough, but I don't intend to copy it one to one and even then I'd still have to make plenty of changes.

This is the Create event. In GameMaker Studio, every object is made up of different events. The Create event is usually there to set up variables, and it runs once when the object is created. I set up the same usual variables that I do in platformer projects. The inputs variable, obviously, dictates whether or not the player is able to use the inputs that would be set up in the object's Step event, which is an event that is checked every frame or "step". If the inputs variable is set to false, then the input code in the step event wouldn't be able to run, and the player would lose the ability to control the character. It'll be set to true pretty much the whole time, but it could come in handy if I decide to include some kind of automated scene or something.

The other variables are simple movement variables. hsp and vsp refer to Horizontal Speed and Vertical Speed respectively. When the player moves, the hsp or vsp variables will increase and update the object's x or y values. maxSpd refers to the player's maximum horizontal speed. The hsp cannot exceed this value. the acc variable is the player's acceleration, and baseAcc is a fallback which does not change and the acc variable can call back to. jumpSpd obviously refers to the jump speed or height, and the grav variable goes without saying.

I'll probably learn to speak less later on. 

Oh, I also set up some state variables which I didn't include in the above screenshot. Essentially, curState will refer to states such as idle, horizontal movement, and jumping, while curSubstate refers to whether or not the player is grounded or in the air. There's probably a better way to handle this.

Anyway, this is the Step event. Every frame, constantly, this event is checked and code is ran if necessary for as long as the game runs. I opened it up with some more input variables that are defined by keyboard check functions. The game will know that, when these variables are in action, a certain key is being pressed, and if they are, the curState variable will be changed.

I wrote down some more code, primarily defining what happens with each state. Allowing the player to move, changing the hsp variable and acc variable, some collision code, etc. Very simple, but besides collision code, which is mostly old code, I forgot to take any screenshots...

For a quick explanation, using the horizontal collision code as an example, it checks if the player object is colliding with an instance of the object obj_solid, also checking the x position added to the current hsp. If it detects collision, and for as long as the player object is moving against this instance, it'll stop the player's movement and make sure that it doesn't go inside. "x += hsp" and "y += vsp" don't relate to the collision code, they're there to add the hsp and vsp, which increase according to the curState, values to the x and y position, making sure that the player object actually moves.

Oh, another thing I didn't take any screenshots of, I did write down some animation variables and code. In the Create event, there are 3 variables: baseName, curAnim, and dir. They correspond to the sprite name itself/a sort of prefix, the animation name, and the direction respectively. By default, these are set to "spr_artist_", "idle", and "_r". In the Step event, the sprite index is set to these three variables added together in order. What this does is, without using the actual sprite name, set the sprite to spr_artist_idle_r, which as I showed earlier, is the name of the idle sprite. By changing the curAnim to a different value, like "run" for example, the sprite index will automatically be changed to spr_artist_run_r, and by changing the dir variable to "_l", the sprite index will automatically be changed to spr_artist_run_l, all without manually changing the player's exact sprite to a different one. If I wanted to change between different character sprites entirely mid game with their own animation sets, I'd be able to change baseName to, say, "spr_hero_" rather than "spr_artist_", and it'd adapt. It's convenient, allows for quickly and easily interchanging different aspects of the player's sprite completely separately.

After adding a camera object that I keep around for convenience sake since it's simple and effective, I threw everything together into a room to test it all out.

Here's a gif I recorded of it. Looking decent so far, but I think there's still some work to be done.

After sharing this around to some friends, I got a bit of feedback from someone.

I did think the player movement was a little bit off, but this gives me a good idea on where to look. I'll keep this in mind.

WEEKLY REVIEW 3

TARGETS FOR THIS WEEK: 

Programming Start, Basic Player Framework

WERE THESE TARGETS MET?: 

Programming Start - Complete.

Basic Player Framework - Not yet. A few things left to do.

MY THOUGHTS, WHAT WENT RIGHT, WHAT DIDN'T: 

Compared to last week, not good. Not good at all. I'd say really bad but I don't want to be too overly critical and let my worries affect this reflection too much. I got a bit of work done, but not nearly enough, not even close. I wasted a lot of the week away, and It will affect my final product. If I had worked consistently and throughout the whole week, I estimate I'd have finished more than just the basic player framework. To end the whole week on something this simple not finished and in this state, doesn't look very good on me. I suppose the quality isn't too bad, but I feel like it doesn't make up entirely for the lack of quantity. I'm pretty notorious for being able to get a lot of work done under time crunch, but I don't want to let myself do absolutely everything last minute on the last week, and I cannot rely on a reputation and get complacent just because "It worked out in the past".

GOING FORWARD, MY PRIORITIES:

At this rate, the chances of me getting many of the more complex aspects of the game done in time are very low. I'm even less sure I'll have time for playtesting. My priorities are mostly the same. Totally side-lining art, and I'm focusing entirely on programming. Next week, I NEED to get the basic framework done and I need to have started on the level design at least. When the level design is complete, I need to get the paint mode implemented at LEAST. If the level design and the paint mode aren't finished, then those are the most major parts of the project down the drain. Right now, granted, my computer is struggling to perform very well, which does take time away from my programming. But I NEED to overcome that.

After the rough week last week, I'm hoping that I'll do a better job. I won't waste any time. First task will be to quickly address the feedback I received. I have doubts there'll be many screenshots as I'm very much in a rush right now.

TARGETS FOR THIS WEEK (DIFFERENT FROM PLANNER): Basic Player Framework, Basic Engine, Blocking Out Level Design

Again, without wasting any time, I got back into the project file and made some tweaks to the player object's speed. I also set up some variables for double jumping. Right now, double jumping, running, and slope collision are up there on my list of priorities.

The canDJump variable is there to set up a sort of time window for when the player is able to double jump. There's definitely probably a better way to handle this, but right now, I feel like it's unwise to spend too much time worrying about something that, while potentially imperfect, gets the job done just fine. If the player is grounded, the double jump window automatically closed. It only opens after the player jumps and is still in mid air, and then closes back up once that double jump is triggered. As an aside, I initially forgot to account for this, so for a moment, the player was allowed to infinitely jump and propel themselves upwards like Flappy Bird. The state code for double jumping is pretty much an exact copy of the jump code.

Additionally, I also wanted to look into jumping as a whole. I felt like maybe the player was a little too floaty, so I went and adjusted the jumpSpd and grav variables a little bit. Since I'd be tinkering with them over and over, I decided to just append an operator to the base values so I can change it without worrying about not being able to go back to a better spot.

Running was very simple. I needed to set up an input for shift, add another variable or two, and then have the maxSpd increase once shift is pressed and decrease when it isn't. I did run into some small issues that came with messing with the character's walking speed and implementing a run function, so I had to mess around with how acceleration works a bunch before the player object stopped jetting off in different directions with no apparent cause.

Once these were properly implemented, I expanded the test room to give me some running room and some platforms to bounce between, and tested. It's looking much better already. Here's the gif I recorded.

I shared it with some friends, and got positive feedback. It was definitely looking a lot better, and it plays a lot better too. Things are coming around a little bit. I still thought that maybe there was a bit of work I could do with the movement variables, but at this point, with a good base like this, it feels unnecessary.

Next was to add slope collision. I'd have to mess with the player object for this too. I've always struggled with slope collision, so I'll have to look at past code for reference.

First, I modified the grounded state code just a little bit to account for the changes I'm gonna make to the collision code itself, adding a little buffer variable. This will guarantee smoother slope movement.

The code below, a modified version of the pre-existing collision code, was, again, especially heavily referenced from some old code I had, which was aided by a tutorial I had followed. Without going into too much detail, that new yplus variable, as the name suggests. is called on to add extra value to the player object's y position when needed, such as when coming into contact with a sloped collision object. This works with collision objects that are manually rotated and angled in the room editor, as well as collision objects that have unique slope shaped sprites. All in all, working with the previously established buffer variable, this code helps make collision more precise and flexible.

Putting it all together into the test room, however, I immediately ran into an issue.

The code technically does work, but something else is interfering. Horizontally, the slope object is treated as a solid wall, and if the player is to try and fall down to it from above, they're locked in the falling state in mid air, never coming down.

After seeing this, I didn't manage to document my process much as I was focused solely on fixing this issue right away and as quick as possible. It took a bit of trial and effort, seeing if I had forgotten to change something important, looking around. One of the first things I looked at was collision maps. I had ran into minor hiccups earlier relating to collision maps when programming the base player object. Mostly issues relating to each animation still having different collision maps and that causing very unnotable oddities with collision. Unsurprisingly, the slope object's sprite's collision type was set to "Rectangle". That was my issue. It made sense why the game treated the angled object as a large solid block. Setting the type to Precise (Slow), which means that the collision map is automatically and precisely calculated in real time rather than being a one and done, universal thing, was most of my issues out of the way.

The player was properly colliding with the slope object now. Mostly. There was still some small issues, such as the player object not properly recognizing that it's supposed to be grounded. With some additional minor code tweaks here and there, mostly tinkering with the buffer and a little bit on the states and ironing some stuff out, It was working just fine.

Here's a gif I took. With slope collision, the player object framework is pretty much complete, and when I add semisolid/jump-through collision, the game's overall framework, or "engine", will be complete as well.

Now, it was on to blocking out the level design. On an unrelated note, I threw together some placeholder decorative tiles when exporting the tileset. Just to have those there and ready to be properly implemented.

Though I definitely should be focusing on the level design, I did take a second to quickly implement a parallax scrolling background. It was pretty simple, but it was still sort of a distraction at a time where distractions should be minimized, especially considering that this "simple" evolved into a larger thing as I ended up getting carried away trying and failing to add vertical parallaxing as well. I'll make sure to minimize issues like this going forward. Regardless, it was looking pretty good.

Additionally, calling back to what I said earlier about the modified collision code being a more precise and flexible version overall and allowing for not only collision with angled objects, but also precise collision with more complex collision maps, I trimmed the slope object's sprite to an actual slope shape so I wouldn't have to waste time angling every slope object manually. Works out a lot better overall. Achieves the same effect but it's better integrated into the flow of designing this level.

I did forget to screenshot, but I also quickly programmed semisolid/jump-through collision blocks. For this, I had to create a semisolid object and a semisolid-barrier object. The semisolid-barrier object was the thing the player is actually meant to collide with, so it was parented under the solid parent object and I didn't have to do anything extra for the player object to recognize it. The semisolid object, however, was a little bit more work. It involved detecting the player's position. If the player was detected above the semisolid object, then it would create a new instance on top of the semisolid object, that being the semisolid-barrier object. This means that the player will be able to pass through from the bottom, and in mid air, the semisolid object would create an actual solid object for the player object to collide with when it lands. If the player is below the semisolid object's y position and the semisolid-barrier instance exists, it's destroyed, allowing once again for the player to pass through from the bottom. This was without issue, but I ended up having to change the player's animation sprites' origin to "bottom center" so that the semisolid-barrier stopped appearing while the player was still inside the semisolid object.

I got to work. My aim was to create a longer, fuller, overall better version of the 2022 version of the level, as well as to create an effective tutorial level. The very basic idea for the level was there, but I needed to improvise on it a lot, so I didn't copy anything 1:1 or even get close. This screenshot already is only similar to the 2022 version in progression, but in layout, it's quite different already.

To explain the process here, I first wanted to have some mostly flat terrain, interrupted by small hills in the terrain. This gives the player some space to move around, get used to that a little bit without having to perform anything challenging. And then I introduce semi-solids (marked in red). Again, it's only simple, but it introduces the player to layered platforming. The 2 floating platforms positioned above the first 2 semisolids are gonna be falling platforms that, if the player detects and chooses to follow, will lead them to a high-up sort of rock formation containing a big coin. The first and easiest big coin. This sets the groundwork for branching paths, which would later be expanded on and properly introduced in the second big coin spot. Immediately after the first 2 semisolids is an abrupt stop. This is to get players more used to larger jumps, as you can't cross this part without a higher jump, and then, immediately after, I introduce a small bottomless pit. This should be easy to avoid falling into, but if you're distracted, it could be dangerous. It also feels like a natural, immediate evolution after having just gotten the player a little more used to performing larger jumps. I did end up modifying this gap a little bit to place the other side lower. It a little more natural to me.

Finally, I quickly filled this in with some basic tiles. This should give a clearer view of the intended design here, since it's a little hard to follow at the semi-solid section with just the collision blocks visible.

I did small bits of extra work here and there, but unfortunately, I didn't capture those by screenshot, and by the time I'm writing this, it's already the end of the week, so it's better to get that recorded next time.

WEEKLY REVIEW 4

TARGETS FOR THIS WEEK: 

Basic Player Framework, Basic Engine, Blocking Out Level Design

WERE THESE TARGETS MET?: 

Basic Player Framework - Complete.

Basic Engine/Basic Game Framework - Complete.

Blocking Out Level Design - Not yet.

MY THOUGHTS, WHAT WENT RIGHT, WHAT DIDN'T: 

Compared to last week, a little bit more was done. However, things are looking really worrying. I did all I could for this week, but I didn't work as often as I should have done. I am now going into my last week, and it's looking like I'll have to rush everything out last minute. This is really bad on me, but I'm not gonna sulk and slow myself down about it. I'll work tirelessly as I always have in these situations. Quality wise, I'd say this week was pretty good. I can't say I've had to sacrifice a lot of quality and things went pretty smoothly all things considered. I acted on feedback that was given last week, and the reception was overall positive. As for quantity, again, there's quite done in comparison to last week, even if the section is pretty short next to the art-focused weeks. I think I can chalk that up to being less used to going more in depth into my programming process, though. It's something to work on. Quantity could have been a lot better had I worked more consistently and had I better used my time. I'd say I have to work on this, but I don't have much of a choice. If I don't work tirelessly next week, then I won't be able to finish on time.

GOING FORWARD, MY PRIORITIES:

As usual, my priorities lay on the absolute necessities of this project. The full level, at least a title screen, Paint Mode, basic level mechanics such as falling platforms and elements such as collectables, just generally trying to get the game to a place where it's playable from start to finish. It's looking less and less likely that I'll be able to implement things such as enemies, or even send out playtesting builds. I'm keeping my expectations low for next week, but I won't pass up a reasonable opportunity if it presents itself. But of course, I'm not gonna waste any time searching for those opportunities either, and I definitely won't be wasting any time bashing myself for what could have been. Next week, I'm obviously, first and foremost, prioritising finishing this level design above all else, and hopefully that won't take too much time. The level design is pretty much the biggest thing I have to do now, and everything past that is in smaller chunks and should be manageable.

Final week. It's looking a little bleak, but again, I won't linger on that. The outcome of this week will rely on how good my decision making is at this point. I'll likely have to sacrifice certain targets, and I'm working with very little plan. Because this is all so much to do in only a week, there may be a lower amount of screenshots, but I'll try to make up for that.

TARGETS FOR THIS WEEK (DIFFERENT FROM PLANNER): Blocking Out Level Design, Finishing Level, Implement Paint Mode, Basic Level Mechanics, Basic Level Elements, Working Statistics/Hud, Paint Mode UI Art, Paint Mode Player Sheet, Title Screen + Pause Menu, Game Playable From Start To Finish

Without wasting much time, I continued blocking out the level design. This screenshot is set pretty much right after the bottomless pit that I documented at the end of last week. Like last time, I'll go over my thought process with the level design, why I made the decisions I did.

That first semi-solid layer is mostly decorative. I didn't think much when putting it there other than interrupting flat terrain, it doesn't lead to anything, but it's there. However, in a way, it does feel right to remind the player of different layers, as following this semi-solid is a hidden branching path. Discrete, but marked by suspicious overlapping terrain. There's not much to this path. There's a bottomless pit that the player must be careful to avoid, It's bigger than the last, and it leads to the second big coin. There's an added complexity to this, as it requires the player once again getting used to using the layered terrain around them to their advantage rather than simple platforming. I am a little afraid that the player will get confused on where to go after they collect the big coin at the end of the lower path.

Following the main path, you eventually run into a large bottomless pit. That's the pit covered only by a single stretched out solid, which I added there for my own playtesting as the pit is too large to be jumped over. This is gonna be the Paint Mode segment. After introducing and walking the player through the basic components of the level design, it's time to introduce them to the game's central mechanic. Once Paint Mode is implemented, the player will be required to fill out that long stretch using the base ground material. Of course, they can also fill out only enough to allow them to cross the pit. And in a hypothetical proper demo version of the game not held back by time restraints, they might also choose to use floating platforms.

Anyway, past this gap, and it's back to simple terrain.

After blocking this part out, I kept going. I had a rough, yet solid idea of where the level would head past this point. I wanted the latter half of this level to take place in a sort of cave-like area, and encourage more exploration, setting up that aspect of the game. It was also at this point that I had to significantly increase the height of the room, which meant wasting a bit of time lowering everything to the bottom since the room is centered at the top left. Putting down more downwards slopes, I set up the semi-solid which would branch off into the biggest alternate path yet.

At this point, admittedly, I got pretty excited about how the level was coming together, so I didn't get any inbetween screenshots. However, I feel a fuller screenshot with more progress will help me to better explain my thought process with this segment than filler screenshots.

The main path, or the lowest path, is pretty ordinary. There's some hilly terrain that leads to yet another, simple bottomless pit, and then there's another large bottomless pit where the player must jump across two platforms to get to the other side. I intend for these to be platforms that move up and down. However, if you take that semi-solid where the paths fork and then navigate through the two regular platforms, you'll end up on the middle path. This path mostly parallels the lower path, albeit with less immediate danger. There'll similarly be a gap in the terrain, however, it'll be bridged together by large blocks which crumble when stepped on. If you don't move fast, best case scenario is you land right on one of the lower platforms, but if you aren't careful, you'll plummet straight to your death inbetween those platforms.

If you do cross that bridge alive, you'll be met with seemingly innocuous terrain, which will merge the middle and main path together. Admittedly, I wanted to have an extra path where these two paths merge, but I cut it out in order to save time. But, just outside of the average player's view is a lone platform in the corner of the screen, floating high above the downwards incline which would lead you to the main path. This is where I set up the highest path. If you're curious and attentive and you take that jump, ascending the three platforms, you'll reach the high path and find the third and final big coin.

Besides just being a hidden big coin location, this also serves as a way to skip through the remaining portion of the cave segment, and straight to the end of the level. This rewards exploration, sets up that aspect of the game well, and also, in a way, appeals to players like speedrunners who wish to speed through the level as fast as possible.

As a side note, when taking on this whole cave-segment with the branching paths, I took a lot of heavy inspiration from Sonic CD's level design. Of course, that's unsurprising. Sonic CD is already the level's inspiration in terms of visual design, and so it's only natural that I end up using the game's level design itself as an influence. Sonic CD is a very multi-layered game that focuses very heavily on exploration and rewards that. The levels are typically, again, very multi-layered and wide, with many branching paths and routes. Once you get used to this exploration, you're rewarded with the ability to breeze past these levels with ease, tapping in to the Sonic series' focus on speed. I wanted to capture the game's focus on exploration with this level, working with what I had, so I pulled up two level layouts, as seen below, from the game's "Palmtree Panic" zone. This zone was also the one which inspired the visual design for my level, so it all comes back around.

This second one was the one I took the most influence from, I think.

It was quite a fun and interesting experience trying to tap in to this multi-layered exploration-heavy design. Though I don't think I was able to 100% match it, I think it definitely flesh out the level and make it a more interesting experience.

Back to my level design. With the high and middle paths out of the way, I decided to tighten things up a little bit with a more narrow platforming segment, also inspired by certain parts of the Sonic CD level design pictured above. I took influence from that at most points going forward, to be honest.

It's not much at all. It's very simple, but it gets the player used to tighter, more methodical platforming which the level had previously not gone over, and which I imagine a hypothetical second level would explore in full as an integral part of its design.

You can see at the end I placed some semi-solid layers leading up to three platforms that connect to the high path. That won't be much at all, but it provides a smoother landing for the player rather than just throwing them onto the lowest path when they're not sure about what hazards might await them, and I imagine it'd provide a few extra coins to top off that exploration reward. Past that, it's all flat terrain until you reach the finish line.

And with that, the level was complete. Suffice to say I'm pretty excited with how well this is coming along. That's the biggest part out of the way.

To go over my aims for this level again, I wanted to create a short, simple, effective tutorial level. Throughout my time in this course, I've found that that effective tutorial level design should seamlessly and gradually introduce the player to different concepts and facets of the game. That's obvious enough. As the first level, I wanted it to be welcoming for anyone, even a first-time player, so I tried to keep a balance of not too easy but not too difficult. Throughout the level, I slowly introduced and expanded on things such as multi-layered level design, branching paths, exploration, etc. I also wanted to subtly appeal to the different player types I spoke about during my research through these gradual introductions as well. Providing plenty of reward for exploration, providing rewards for going above and beyond, allowing the player to take alternate routes which will get them to the finish line faster. When it came to different facets that I didn't explore as much, such as tighter platforming, I included it in a way that would set up for a hypothetical full game, which helps it to feel a little more natural rather than the one time thing it actually is.

Did I do a good job? I think so. I'm very proud of how I executed this level. I met my aims pretty well, and it's a massive improvement from its 2022 equivalent. If there's one thing I wish I could have done better, if I had more time, it's make a longer design and further hammer in alternate branching paths and exploration. I did well with what I had, but I wish I could have done more in that regard.

Now, I did something I didn't think I was gonna be able to do. With the level completed, I quickly put together some objects that restart the game when collided with, lined the bottom of the level with them as well as a makeshift finish, mark the positions of the big coins with a placeholder yellow block, and then sent out a build to some of my friends for playtesting. I'm pretty consistent with updating my friends with what I'm doing and working on, but I've been silent on level design because of the possibility that I might be able to squeeze in playtesting. My aims were to mostly observe how the average person plays through the level, and pick up on any feedback. It's pretty difficult to gauge just how a level is actually played when you're the one developing it.

I was unfortunately not able to see them play it live, but some posted their reactions in real time and noted down their gameplay. I got a pretty lengthy voice message from one going over their thoughts.

I'll start off by putting down some of the live documentation.

It was overall a very interesting experience. Beyond even what I've shown.

Like I mentioned, beyond live reactions, I got a pretty lengthy 4 minute long voice message going over some criticisms. This friend has previously given me pretty good feedback on this project, and I've noted some of it in previous weeks, so she's pretty reliable.

Obviously, I can't put the voice message itself here, but I'll just quickly summarize some of the stuff that was said.

1. "I can't really tell what's going on ahead of or under me because the camera is centered. Could be more dynamic, dependent on the player's actions."

2. "I can't tell which pits are bottomless. Possibly comes down to a level design thing because I shouldn't be taking leaps of faith to begin with. Could normalize having less areas where you need to jump down without knowing where the platform is, or indicating if a pit is bottomless."

3. "Small nitpick on the movement. I still feel like getting from no speed to walking speed is not gradual enough."

4. "Maybe zoom the camera out a little bit? Like, I don't really know if you can do that because of the way pixel art is? But if you can, maybe invest in that. Cause that goes back to the camera and the bottomless pit thing. I don't really know what's going on ahead of me."

There seems to be a common issue where the playtesters struggle to figure out where to go to proceed or with what's ahead of them. One got stuck at the second big coin location because there wasn't a good enough indicator on where to go, there was a few comments on the resolution of the game being too small and limited, and a lot of feedback said that they struggled on certain platforming sections because it's hard to tell where they're able to jump.

While changing the resolution at this point would only cause me inconvenience and waste my time, I can think of a few ways to address these issues. A primary solution right now would be to implement a looking down state, where upon holding the down arrow key, the camera will pan downwards, as well as just generally implementing certain indicators. However, a secondary, bandaid solution if it comes down to it and if I struggle with the camera, would be to simply guide the player with the use of coins. I recall, during our level design classes, a good way to guide the player in level design is, obviously, through subtle yet noticeable visual indicators. Like a light illuminating a door. In this case, I could use coins as a way to show a player where they should or can head. This should kill two birds with one stone, as well.

A small issue that some players had was that they didn't know about the double jump. I did try to make this clear in the original message when I sent out the build, but it seems some people didn't quite read it. If I don't manage to get a "controls" display at the start of the game, then this will be covered in the itch.io page. There's not much I can do about people not reading, unfortunately.

Overall, reception on the level is mostly positive. A few deaths were noted which does tell me the level isn't too easy, but it isn't too hard either. Discovering the big coins isn't too easy or too hard either, as it turns out, and I was told they were well hidden.

Now, with the level design and playtesting out of the way, it was time to move on to implementing Paint Mode.

Even besides Paint Mode, there were a handful of things that I decided to take on. I'm writing this after the fact, as I sort of went full steam ahead because I wanted this done and out of the way as soon as possible. I didn't take many progress screenshots along the way at all, so a lot of this is after it was all said and done.

Starting on Paint Mode and exporting some less important graphics from 2022 that work as placeholders but are unimportant enough to where I wouldn't lose any sleep if I can't remake them, I decided to follow a similar object structure to the 2022 version of the game. The brush cursor object, the Paint Mode object itself, a Paint Mode marker, and a decoy actor for the protagonist which is switched out from the regular player object. Because of the similar structure, this was mostly recoding things from memory of programming it originally, doing it better and avoiding pitfalls I originally ran into. Though I did realize I'd probably have to do a lot of weird, hacky bandaid code to avoid working on this too long.

To get things started, I also made a global "game" object which would keep track of some of the more important things. It'll track certain stats such as time, it'll contain pause menu code, and most importantly and relevantly, it'll contain a global Paint Mode variable.

Here's a screenshot I took of the Create event after it was all said and done and I had things like the pause menu coded in. You can sort of tell I was in a rush since I stopped caring about variable names.

And, while I'm at it, the Step event.

I also went and made a "music" object while I was at it. It's only simple, having only a Create event, so I figured I'd get that out of the way now. Simply detects if Paint Mode is on and which room it's in.

This is getting a little messy, but back to Paint Mode.

The Create event mostly sets up visual stuff. To be honest, it IS mostly made out of just visual stuff. A lot of the variables note down initial positions and end positions for different onscreen graphics that would get moved around and moved into place by lerp functions. It switches the camera focus to the brush cursor object, which is given a starter x and y position, centered to one of the grid squares, and then it sets up the tilemap. The tilemap would get used in the Step event, where the specific tile ID for the grass tiles would be picked out and assigned, and upon pressing Z, that specific tile ID's tile would be placed down on the closest position to the brush cursor. Which is rounded up and aligned to the room's "PMTILES" layer's 20x20 grid size. I didn't take a screenshot, but the code for that is insanely hacky. I could do a lot better, but I feel as if I'll waste too much time by doing so, when visually and functionally, it gets the job done.

A screenshot I took of some of the Step event code. Everything at the start is set up for the Draw GUI event where all the graphics are drawn on screen and their positions set to the lerp functions so that they settle on screen smoothly. It then creates the brush cursor, and makes sure it moves based on what's pressed, but never off the grid.

Finally, for the Draw event, since the brush cursor object is set to be non visible, it simply draws a sprite for the brush cursor, and then sets the positions to brushx and brushy. Very simple. Nothing much to say on this.

I started coding the Paint Mode marker object when I was just a little bit less in a rush, so the variable names are a little better. Here's the Create event for that.

The pester variables are a sort of trigger. When pester is set to true, that's a call for the marker to prompt the player that they can enable Paint Mode. It'll set the cooldownTimer variable and then count it down until it reaches zero. In the background of that countdown, in the Draw Gui event, a prompt graphic, which I'm using a placeholder for, will be created, and it'll smoothly slide up onto the screen using the lerp function and the promptStart, promptFinish variables, the promptBack variable specifically meant to send it back once the prompt is no longer needed. Once the cooldownTimer is zero, zAllow will be set to true, allowing the player to enable Paint Mode by pressing Z, which will set the global pm variable to true and create the Paint Mode handler object.

Additionally, I had to go back and add a little something to the start of the player object's Step event to ensure that the player object is properly replaced by the decoy Paint Mode protagonist actor object.

With that, Paint Mode is pretty much implemented, and I couldn't be happier with how it turned out. To be honest, it's mostly just sprites being moved around and extrapolated, along with some hacky code here and there, but it gets the job done and I shouldn't complain too much. I said a couple weeks back that I need to learn to put away my perfectionism sometimes if I want to ensure that I can deliver an overall good quality product on time.

There's still some stuff to be done with Paint Mode, though, like replacing the placeholder toolbar graphic with a new one based on the concept art in pre-production, and there's no guarantee I won't be doing some polishing. I'll be saving that for later. Here's what all these walls of text look like in game so far.

With Paint Mode out of the way, that was pretty much over 90% of the game done. Before moving on to talking about my next tasks, I'll just quickly go back and talk about the pause menu, since I did that sort of alongside Paint Mode. Wasn't wise, but what's done is done.

I already included the Create and Step events for the global game object containing some of the pause menu code, but since it's all just sprites and graphics moving around, talking about the Draw Gui event is probably the thing to do.

Here is that. Simply, if the paused variable is true, all of these things will happen. The first half which talks about surfaces and what not is what handles the game screen actually freezing. Admittedly, I took that code from a tutorial, as something like that is way above my expertise. It does seem pretty simple, though. From my newfound, yet limited knowledge of surfaces, I believe it redirects the current screen display from the screen itself to the gamescreen variable after setting the gamescreen variable to a new surface the size of the room's width and height, drawing the application surface preserves what's being shown on screen, and then it draws the paused surface. I believe instance_deactivate_all will stop anything else except for the game controller from working until the game is unpaused. I mostly understood it, but some things go over my head, which is something to work on.

Anything below draw_surface(gamescreen, 0, 0); draws the visual aspects of the pause screen. It covers the screen in a low opacity black rectangle that makes it look faded, draws the letterbox-style bars that close in on the screen and sets their y positions to the respective variables so that they settle on the screen smoothly, sets the font and draw colour, and then writes down text which also settles on the screen smoothly, and the process is repeated for the 3 buttons and the text on them. It's cropped out, but the cursor for these buttons is drawn with its x position set to a fancy custom sine wave function I got from somewhere, which, admittedly, I don't understand yet.

The movement of this cursor and the ability to press the buttons is all handled pretty easily in the Step event. It's somewhat similar to the Paint Mode grid movement code where it uses a variable to track which button the cursor is at, that variable changes depending on player inputs, and that variable dictates visual changes such as the cursor's y position, which graphic is changed to a highlighted state, and what happens if each button is pressed. So on and so forth.

Here's what it all looks like.

Alright, back on track. My priorities now are to get the HUD working and take on level elements such as coins.

I didn't take many screenshots at all this time. Time was running out, so I was really really rushing, working completely full steam ahead.

After exporting the HUD elements I had sprited a couple weeks and getting them into GameMaker Studio, along with quickly throwing together some stages for the big coin display, as is shown below...

It was time to take art out of the sidelines. I started off with making a simple little coin graphic. I didn't get many progress screenshots. It's a really small graphic and I didn't need to sketch or anything like that.

Just a simple 4 frame animation. If it isn't clear, I'm really going hard on setting up a very frequent visual motif with this face, based on the sun lion boss design I sketched out mostly for fun alongside the level's visual design in pre-production. There was a similar visual motif in the 2022 version, but it was vague and sort of aimless, totally detached from anything else. 

After this little animation was finished, I moved on to the big coin sprite. I'm kind of sad I didn't get any progress screenshots for this, as it was a very interesting process. I decided to take on the same process as I did for this graphic in 2022, being to upscale the regular coin sprite by 2x. Of course, it wasn't just going to be that. That would go against common pixel artist ettiquette. As is said in Michael Azzi's "Pixel Logic - A Guide to Pixel Art", which I've been occasionally taking mental notes on every now and then through this project, "Even more importantly, NEVER EVER mix different pixel ratios."

After resizing, I'd sort of touch up the shape to smooth it out and make the resized sprite more fitting to the game's normal pixel ratio. Sort of sculpting and chiseling it a little bit. The process took some trial and error, but it was overall really fun, which is why it's a shame I can't get any progress screenshots to document that.

Afterwards, I threw together some sparkle effect animations for them which didn't take too long and then threw it all in to the game. There's not much to note about these and even less progress screenshots. I suppose the big coin sparkle took a little bit more trial and effort though.

Once those were in, I made some objects for them, replaced the placeholder yellow squares with actual big coins, and then blocked out the coin placements throughout the level.

Here, I acted on some of the feedback I got earlier. I figured by now that it was too late to try and mess with the camera. I explained my approach to some friends, specifically talking to the one which had sent the voice message, and the coin indicator idea seemed to be a pretty good solution to the leap of faith problem.

Now, to program the HUD, it should be simple enough. I've shown many times throughout the project that I'm more than capable of putting a bunch of flashy graphics on screen and having them change a bunch along with variables. Strangely, I remember taking a picture of some updates I made to the player's Create event, but I can't seem to find that anywhere. Regardless, the updates were simple, so it's not like I can't summarize them through text. I just set up a few new variables for the stats. coins, bCoins, points, hp, and animHP. The variables for the time display were handled seperately by the game controller object. Using the mockup to guide the positions, I threw some draw sprite functions into the player object's Draw GUI event, and then topped it off with some draw text functions with their values set to different variables, the time one specifically calling a combination of obj.game variables. As a side note, actually, I have my own custom made script function which is just a regular draw_text except it's layered in front of a whole bunch of other draw_text functions printing the same argument but set to a different color depending on another argument and all moved around a bunch to create the illusion of an outline around the text. There isn't a built-in text outline function in GameMaker Studio, unfortunately. I used this for the coin, points, and time displays' corresponding text, but I noticed the outline wasn't really thick enough and it didn't match the thickness of the outline on the HUD sprites, so I had to make a thicker variant to this script and just duplicate a bunch of code and change some of the values.

 Anyway, was a pretty simple process. Not much to say. 

Quick callback to a few weeks ago when I made the HUD sprites. I had gone over looking into blend modes to see if I can make the big coin display more visually interesting, and I found that GameMaker Studio supports the additive blend mode as one of the basics. Now, while actually implementing the HUD, of course, I tested out the additive blend mode on the big coin display. While it initially looked good in the mockup, I forgot to take into account that there'd be more to this display visually which may not look good with additive blending, and I realized that, well, it REALLY doesn't work out.

So I just settled for low opacity.

Here's a screenshot of this all together. Things are coming along really well.

Now I just had to properly program the coins so that 3/5 of these displays have something to do.

The coin objects were already created, so immediately, I went onto the sparkle animations and added a message broadcast after the last frame. These messages will be received once the sparkle effect is created.

Then, I created a dedicated object for the sparkle effect. There's definitely a different way to do this, but this comes naturally to me and visually gets the job done. I don't wanna spend too much time on this, so it's better to settle for what comes naturally first and works. Moving back to the player object, I added a new collision event with the coin object. Once this event is triggered, it adds one to the coins variable, plays a sound, and creates a new instance of the sparkle effect object in the same layer and with the same x and y positions as the coin object. Easy stuff.

The coin object similarly has its own collision event with the player, except it simply destroys itself.

For the sparkle object, it has one simple event, that being the Broadcast Message event. Once the animEnd message from the last frame of the sprite animation is broadcasted, the sparkle object destroys itself.

Here's how that all looks.

For the big coins, it was all just the same process, except instead of adding one to the coins variable, it was one to the bCoins variable and 100 to the points variable. And changing around the sound effect and sparkle object, of course.

Now, to make sure that it displayed properly on the big coin display, I needed to quickly go back and set the subimg value on the draw sprite function for the display to the bCoins variable. Subimg is just a weird way to say the sprite's current frame, and so when the bCoins variable is added to, the big coin display's sprite's frame will go up as well, showing the amount of big coins the player has.

Finally, here's how that looks.

With collectables and the HUD out of the way, there was only two main things to do now programming wise. Implement some basic level mechanics, that being falling platforms, moving platforms, and falling blocks, and then the title screen. Of course, I'm starting with the former.

Heading straight into it, the falling platform was fairly simple. I made a new object with a placeholder graphic, and then copied the semi-solid code. From there, I set up a few new variables. triggered, fallTimer, and grav.

Pretty self explanatory names. With these new variables set up, I made some additions to the code in the Step event. The triggered variable, automatically set to false, is set to true once the falling platform object detects that the player is stood on it. Along with triggered being set to true, it also bumps the fallTimer variable to 30. The object only checks for this collision if triggered is false, so the second it happens, that piece of code at the end stops running and allows for the rest to do their thing. Past this point, as long as fallTimer's value is above 0, it'll keep counting down until it reaches zero, where the grav variable does its job and both the falling platform object and the barrier it created fall down.

It was pretty simple all things considered, but I did struggle quite a bit initially, which I didn't capture because I'm, again, rushing and working full speed ahead. Here's what the falling platforms look like in action.

Now, so far during this week, I've been pretty consistently meeting my aims. However, it was only a matter of time before I had to make some decisions. I moved on to the moving platform. The plan was very solid for it, and it seemed like it was gonna work out in the end, but the collision refused to work properly as the platform went up. So I decided to scrap it. It's not exactly necessary, and keeping at it will only slow me down. I also decided to scrap falling blocks as well. Though I had the framework, trying to tinker with moving platforms for as long as I did slowed me down a lot, and I did not want to risk the potential of running into another issue and losing even more time.

Before heading onto the title screen, I decided take a moment and work on some art assets. I started by finalizing the tileset, most importantly the placeholder graphics from last week.

For this one, I worked off the sketch I had last time. I also heavily referenced Sonic CD's Collision Chaos Good Future design. I wanted to go for a screen mixed with solar panel kind of deal, which goes along with the level's almost weird occasional pseudo-futuristic yet overall nature heavy elements.

The reference is a little more apparent when it has the text.

I also went back and did the plants. I didn't get any inbetween screenshots on this, and there's nothing to talk about, so I'll just put these here.

Besides finalizing some placeholders, I also went back and touched up on previous, finished tiles as well. For the light post, I covered up a small error in the darker variant, added some lighting to the grass, and made the stand holding up the sphere a little bit more layered, complex, and symmetrical. There's something about the Sonic CD art style that I want to try and tap in to with this level's design, and I've found that the style isn't really just "thing that looks weird for the sake of looking weird". There's a lot of complex, symmetrical, elaborate architectural features in the Sonic CD style which I feel this update gets a little closer to matching, rather than just looking weird and wonky.

Something a little more minor, I also went back and changed the tree decoration's base's color back to purple, like I was considering doing a few weeks back. It looks more concise this way. Most other bases shown in the level will be purple, so it's more consistent overall, too. The pink and yellow looked a little jarring and amateur, anyway.

Finally, I went and finished the pillar tiles for the cave entrance. I don't have much to say about this one. Sort of a callback to the inclusion of ancient sort of roman architecture in the area design's moodboard and the background. There's a weird sort of mix, a juxtaposition between futuristic and ancient design elements, and I think that alone adds to the intentional weirdness of the design.

With that, the tileset is basically totally complete. All together, I'm really happy with how, well, complete it looks. It looks very final, like something that would actually show up in a game.

That doesn't mean the level is visually complete, though. I still need to make graphics for the platform, the would-be-falling blocks, and the victory object.

For the would-be-falling blocks, I used the same process as I did on the big coins, but this time on that regular lion head block tile. Same process, but significantly less fun this time. It took a bit more trial and effort, and it was pretty hard trying to get right. But I got it in the end.

For the platform, I remember imagining it to be more complex, but at this point, I can't be bothered having to deal with potential complications of exceeding the size of the placeholder platform graphics. Even then, I think the simpler design turned out even better. I made sure to keep it visually consistent with the monitor decoration, to make the it all concise. This one was also just kind of improvised. 

Finally, for the victory object. This time, I calmed down and got some inbetween screenshots. This one was kinda improvised, but for a while, I imagined that at the end of the level, there would be this magical, glowing, floating painting that resembles the one the world is based on. A simple graphic, but I also imagined there being some visual quirk with it once the player crosses the finish line. Of course, since I don't have time for a victory screen, I won't be able to execute that. But I think it'll be fine on its own.

Sketching it out, I decided to go for a weirder shape. Exaggerated, cartoony, but it also adds to the otherworldly nature of the game's setting. When I first considered a painting-like victory object, I imagined it to be more of a framed photo. But I think this works out better.

I can have fun with this one. I don't have to put too much thought into it. The painting itself is supposed to look sort of faded, splodgy, as both an artistic decision and for simplicity sake but it also gets across the idea that the protagonist is having to go back and finish her old, unfinished paintings, in a way.

All there is to it. Very simple, cute little sprite. I do wish I had the time to execute that little visual quirk I spoke about, but I'll take what I can get at this point.

I finished the title screen pretty quickly, but I only got this little piece of footage after it was finished before immediately moving on to last minute stuff. The rush is really starting to get to me now.

Footage is a little slow since I converted it from a video to a gif.

With that out of the way, I got back into Aseprite to get the Paint Mode UI finished.

I decided to get a little more free form with it. It's a larger graphic, so drawing it individually, pixel by pixel, would be a pain and might lose some of the effect. It'd take me way longer than it needs to as well.

I settled for also manually touching up on the shape as I go along. Free form doesn't mean it has to get too messy. Some messiness would help sell the whole handmade aspect, though.

I decided to put the eraser and material options behind little padlocks. I didn't have time to program those features, so it's better to communicate that. 

I'm happy with how this came out, though. Because I decided to go free form, I managed to achieve a kinda vibe which really works out for this kind of game.

Implementing this UI was no struggle at all. Just simply replacing a sprite with another, and it worked perfectly.

And now, as one last bit of polish before I call this game done...

While playing through the level, I realized that the Paint Mode prompt overlaps really awkwardly with the big coin display. Some simple code changes worked that out really easily. I switched the Paint Mode prompt to the other side of the screen, which doesn't overlap with anything and looks really nice. It uses the screen space well this way, I think.

While looking at Paint Mode, I also went and fixed a bug I notice, where the brush is allowed to go one square too far to the left and upwards.

And finally, the game is finished.

All that's left to do now is export the build, record a quick video, take some screenshots, and get it all on an Itch.io page.

On that, actually. I mentioned on the proposal that my aim was to showcase the final product through an itch.io release and either a trailer or a video. Since this is sort of a multimedium thing mostly comprising of art, I feel like it'll be balanced to throw in a simple art book in there too. The itch.io release will show off the playable game, the art book will show off all the assets, and the video, along with the screenshots that come with the itch.io page, will show those assets in action. It feels only natural. Good ways to convey the nature of the project.

Putting together the itch.io page will be no sweat, and recording a video and getting some quick screenshots will be even less work. So I'll mainly be going over the art book.

I put together a cute little looping background to make the art book a little more visually interesting itself. If I'm able, I'll also be using this for the itch.io page.

Then, with it, I threw together a quick, cute, good looking first page. The rest should all be pretty much the same process, so I'll only go through the next page and the page after that.

This is how I'll be fitting things together page by page. I won't go into lengthy explanations, or any explanation at all for these. If there is any explanation at all, like in the second image, it's simply there for clarification purposes. Simply just displaying the work as concisely as possible.

Now, I'm setting up the itch.io page. Initially, setting up looked a little more plain than I expected. That is until I saved the draft and it sent me to a whole other page which allowed me to view it as well as edit the theme.

After tinkering around for a bit, I got something pretty cute looking, so I left it at that and went back to edit the description. I opened it up with a quick summary of the game's story, acting like it's a proper, fully developed thing.

I also went and set up some tags.

After a bit of writing, it was good to go.

FINAL WEEKLY REVIEW

TARGETS FOR THIS WEEK: 

Blocking Out Level Design, Finishing Level, Implement Paint Mode, Basic Level Mechanics, Basic Level Elements, Working Statistics/Hud, Paint Mode UI Art, Paint Mode Player Sheet, Title Screen + Pause Menu, Game Playable From Start To Finish

WERE THESE TARGETS MET?: 

Blocking Out Level Design - Complete.

Finishing Level - Complete.

Implementing Paint Mode - Complete.

Basic Level Mechanics - 1/3. Two were scrapped.

Basic Level Elements - Complete.

Working Statistics/HUD - Complete.

Paint Mode UI Art - Complete.

Paint Mode Player Sheet - No.

Title Screen + Pause Menu  - Complete.

Game Playable From Start To Finish? - Yes.

BEYOND THE TARGETS: 

Playtesting Build - Complete.

Fully Finalised Tileset - Complete.

MY THOUGHTS, WHAT WENT RIGHT, WHAT DIDN'T: 

That's it. That's the end of the project. Like I expected, it was all pretty much finished last minute, but I won't complain much about that right now since it was at least finished. I met pretty much most of my targets here, and made up for the ones I didn't by achieving certain targets I had completely sidelined since I thought they'd be either impossible or not really worth my time. This was a very good week, and honestly should be the standard for my average work week. I spent a good majority working full steam ahead, completing the level within the first couple days and being able to send out a playtesting build. I acted on feedback, weighed the pros and cons on different solutions before landing on one which would be effective and could be implemented at a fraction of the time, and then implemented everything as swiftly as possible. I could have worked a little bit more, and there were times where I definitely lagged behind a little bit because of distractions, but I tried to keep it all to a minimum this week, and it paid off. Quality wise, I think it's great. I couldn't be prouder of how this all turned out. It really shows how far I've come since 2022. I don't think I have to speak much on quantity. I pretty much developed the better half of the game in this one week. There are many things I wish I could have done, and a few I wish I could have done better. I wish I could have at least implemented enemies and a better win screen, and I especially wish I could have had more time on polish. I definitely shouldn't have been doing all of this on the last week, but what's done is done and I managed to deal with it pretty well.