Overview

For this devlog, I will be reviewing my performance in two main sections. One is a review of this specific game, and the other is about my current skillset. If you're here from my Trijam entry, then you may only be interested in reading the first section.

Meteor Shower

Overview

Meteor Shower is my entry for Trijam 121 and the third game jam game I've made overall. In it, you control an astronaut with WASD and avoid meteors which spawn from the left and right walls. You can jump an infinite number of times. Holding S will make the player fall faster by incrementally increasing their gravity.

Fun fact: the "meteors" in this game are probably actually asteroids.

Movement

For this game, I wanted to focus primarily on adjusting the player's movement. When the player jumps, the gravity is much lower than what the player character blueprint is set to by default. I wanted to simulate what being in a low gravity space environment might feel like for the player and I wanted to try different movement in general. A demo of the movement only, with no enemies, can be found here.

Overall I think I'm content with player movement. I had a hard time getting the "fast fall" speed to ramp up accordingly. To achieve fast fall, the game calculates a "falling" variable depending on how long the player has been holding down S. Then, it uses this to lerp from the lowest amount of gravity (player is not pressing S) to the highest amount of gravity (player has been holding S for the maximum amount of time). I initially had the highest gravity set to quite a bit higher so that the player had more control over their downward motion, but the movement wasn't as smooth as I had liked. The gravity didn't change fast enough until right when the player was reaching maximum gravity, and then it suddenly felt like the player was falling too fast. I believe the system I have set up uses a linear method of changing the gravity, but I think this would have worked better with something exponential. 

Admittedly, the space the player is in also restricts player movement more than I would like. I didn't want to make the space too big and have the player unable to navigate clearly (especially since the background is simply a solid color block and I knew I wouldn't spend time adjusting scenery in the foreground), but with it being as small as it is, one or two jumps is more than enough to reach the top of the area.

Gameplay

The player needs to avoid the meteors that come from the sides of the screen at random. Initially, I had these falling from the ceiling, but this combined with a jump heavy playstyle made the game too hard and not very fun to move around. The meteors generate randomly every few milliseconds along the x-axis up and down the side of the wall and then have static y and z values.

If I'm being honest, I don't really like the gameplay in this game. The good thing is that I do understand why I had issues defining a gameplay style. The bad thing is those issues tie into my skillset a bit.

Why is the gameplay style poorly defined? Well, I decided on a movement style first and then just tried to create a gameplay style without the two informing each other and being more connected.I was really set on creating a low gravity themed movement system and didn't actually know what I wanted to do with it. This is a planning problem.

Initially, I had thought about having the player travel through a larger world by going through black holes or vortexes. I think this would have been a better fit for the movement, but I couldn't figure out what to do next. Why would the player travel through these holes? Where would they go? I thought about maybe having them solve some sort of puzzle by traveling between various areas, but I've found the "infinite" level style of gameplay to be something I think I can implement better in a shorter form game jam. Runners, randomly spawning enemies, surviving as long as you can, procedurally generated levels... These are the types of gameplay that I feel like work best for a time sensitive game jam because I don't have to spend much (or any) time on level design and I can still potentially create a game someone might play for a least a few minutes. However, there's a clear conflict between trying to achieve a simple game design and designing a game type that works with the movement system.

Of course, I'm making an assumption about my own skills and about the time required to design games when I say I don't think I could have created a solid level design within the desired timeframe. I did spend time on game design when I developed the asteroids and made them. I spent time when I decided to switch the asteroids to coming from the walls instead of the ceiling. Maybe creating a level would have taken me a similar amount of time.

I also think I'm more worried than I should be about making a short level or only making a few levels and having people not play my game for very long. I think this is a product of me being a bit too removed from web games and mobile games. A lot of the games that I play are longer form games because they're console or PC games. I expect to sit down and play anywhere between a few minutes and a few hours when I play a game, but that's not exactly the type of game that would be created in a short game jam nor created for browser gaming. I'm a solo dev making a free game in a game jam that's supposed to take around three hours of work, so of course it would make sense to only have an experience that lasts for a few minutes. I think maybe I need to sit down and play more mobile and web based games to get an idea of what's possible and what I might want to make in this category.

What should I do next time? Well, I think there's a point where this is an unfortunate casualty of doing a game jam. If you have a limited amount of time, it can be difficult to determine exactly how long something might take. If this wasn't a game jam game, I would have likely tried to go with my puzzle idea, no matter how long that might have taken to implement. If I run into this problem in another game jam game... I think I have to start at the beginning and not make a movement system that required a game concept I didn't have time to create. Barring that, maybe it would have been better for me to go ahead and try designing a level, even if I feel like it might take too much time. Again, for a Trijam entry, only one category is related to time. Wouldn't it be better to make a good game, even if it takes 8 hours instead of closer to 3? Plus I still don't know if designing a level or a few levels would have taken longer than creating and implementing the meteors.

I will admit that this time, part of the reason that I chose not to go ahead and create something that might take me too long was because I couldn't really spend that much time on it for reasons outside of the jam and game development. I can't always avoid other factors getting in the way, but I think in optimal conditions I should maybe strive to create something more in line with what I want even if I end up doing a lot of overtime.

Audio

My game audio always sits at a weird spot for me. I'll explain why in the second part of the report. Regardless, I'm fairly pleased with the audio. The music is a short loop, but I feel like that's fairly appropriate for this type of project. It was nice working with the synth VST (I use Dexed) and creating my own synth voice this time for the melodic line. The sound of the thrusters that play when jumping came from a phone recording of my AC unit. I figured I could use a bad quality recording for a sound that's supposed to have some crunch and some white noise anyway, and I think I was right.

What is a bit frustrating is that I ended up downsampling all the audio a bit heavily to try and solve a size related issue that I had and I'm not even sure if that helped. By the time I finally got the issue resolved I just needed to upload the game, so I didn't really get the chance to try using the 22.5KHz or 44kHz versions instead.

Visuals

My thoughts on the visuals are somewhat scattered. I like the sprite I created for the character and I feel like I created it in good time. The asteroid sprite is slightly lazy, but I'm okay with that because I just needed a general enemy/projectile for the player to avoid. The background and walls are boring. I think it would have been cool to make a background that had more of a "space" theme than just being a dark purple-ish blue color. I liked the fact that I could make flames disappear and reappear as the player jumped, but with more time I would have liked to animate the flames.

The sprites I'm making for these sorts of shorter projects aren't as high quality as sprite art I might create otherwise. I usually draw with a small brush (1-3 pixels) with a hard edge to make these sprites. If I was working outside of game jam timelines, I would probably go back over and check individual pixel placements a bit more, especially when it comes to borderless components and shading. I don't think this is a problem, but it looks a bit simpler and less like the complex sprite art styles I think look best in games.

There's still a descrepancy between how I would like things to be scaled and how they're scaled in game, but I think this may also be something that's a casualty of short form projects. If I make sprites and decide at the last minute I need to resize them, I'm not going to go back and recreate the sprite if I'm already an hour overtime on the project and it's not going to make the game considerably better. I suppose this is something I'll have to take into consideration for longer form projects: I may need to create new sprites unexpectedly later into my game development if I choose to do things in this order.

Where I still am having a bit of issues is with getting a sprite into Unreal Engine. When using Paper2D assets, there's a slight "border" around the sprite and the sprite no longer looks pixellated due to being resized. I think I would benefit from watching some tutorials and revisiting these assets outside of a game jam.

My Skills

Organization and Focus

Sigh. This is where I think I'm having the biggest issue and I think it's something where I'm going to have to try to work with myself instead of being able to make myself do exactly what I want.

I'm not an organized person and I never have been. Even in places where I've been successful, I'm not really that organized.

Where this becomes a problem is when it comes time to create a project in a concise way. I may not be able to see all parts of the project evenly and plan very well. For example, in this game, I got really caught up in creating a good movement system and couldn't move past doing that. I tried to come up with a gameplay design, but was so excited about trying different movement styles that I couldn't do anything else on the game until I worked on the movement specifically. This, of course, led to problems.

I'm not really sure how I would negate that in the future. I told myself that I needed to focus on gameplay, but I couldn't make myself do that. What I think I need to do is plan in phases, but I tried to do that and it didn't really work. Since I was so caught up in movement, I went ahead and fleshed out the movement system and then sat down for another planning phase to think about gameplay. But that planning phase simply wasn't very productive.

I also have a hard time disuading myself from an idea that might not actually be all that helpful. I feel like knowing that the gameplay was pretty nebulous still should have been a red flag to not just create the movement system I wanted to do anyway, but that didn't really stop me.

It might have helped if I had been able to do things in the right order. What I probably should have done is develop a game style/gameplay, then develop movement mechanics, then do any necessary level design, then do art and audio assets. Instead, I developed the movement, then did art and audio, then tried to put together gameplay/level design, then went back and did more art and audio, then had to fix the level design.

I think I unfortunately have to chase "interesting" ideas even if they don't lead me anywhere good, and I think I need to learn how to work with that. If I DID need to create this movement style, then how can I facilitate productivity in a second planning phase that discusses gameplay? OR, how can I convince myself to stay in the planning stage when I'm not actually ready to move on yet? I feel like I need to make the planning stage fun or exciting in some way so that I can stay in this stage without feeling the need to push forward... I'm just not sure how I'd do that yet. 

Development/Coding

Not EXCLUSIVELY due to Trijam, but I'm definitely getting faster at purely game development. Some of this has been because I've done more of it. This is my third game jam release, my fourth release of SOME sort of title, and I'm spending a lot of time with Unreal Engine. I feel like I can pretty quickly get collision settings to work even if I have to adjust physics. Making a simple widget is also something I can do quickly, although I'm still having some issues understanding how and why the widget resizes when the game screen is resized.

I purposely did a few new things this time. I appended a string so that I could use a variable in the middle of a sentence. When the player dies, a message pops up on screen that says "You lasted for x seconds.," where x is filled in by a "seconds" variable that counted how long the player lasted. It's simple, but it's something I had avoided doing before simply because I didn't know how.

I created individual values for each coordinate (x, y, and z) to make a vector, then I put that vector as the location part of a transform so that I could spawn an actor with an custom location variable and an adjusted transform variable. Before, I had only made multiple values into a vector and hadn't put a vector into a transform. It's nice to learn how different variable types interact.

Some of this progress is thanks to starting to learn a language. I haven't been keeping up with it lately, but I started to learn C# a few weeks back. Starting to work with a language has given me a bit more understanding of variable types and terms in general, like the idea of "public" and "private" variables.

I picked C# specifically because everyone seems to say it's easier than C++ but that it's relatively easy to learn C++ from C#. Also, I know Unity is C# and I know Unity has some interesting features. Last time I tried to use Unity, it was for a project that I had a really hard time with, but I'm not sure if that was just because of the project or if I really just don't prefer Unity. I may try it out again.

I did specifically have issues packaging and not making the file too big to go online... But I'm not really too upset by this because I was able to figure it out (eventually...) and it looks like maybe this is just something UE4 is finicky about.

One other thing I specifically think I should try to fix in the future is variable names. I had two variables both named "seconds," one in the widget blueprint and one in the level blueprint. While this doesn't cause too much of an issue because it's usually easy enough to distinguish, it sometimes causes wasted time if I accidentally use nodes for the wrong variable. It can also cause some confusion and I could especially see issues if I choose to work with another developer. Going forward, I should maybe see about committing myself to distinguishing variables.

Audio

I've studied audio. The problem now with working on it is that it sets some weird expectations. When I actually make any effort on audio, it's the thing that mostly ends up being the easiest, the thing that I know how to troubleshoot the best, the thing I usually know the correct terms to use for, and the thing that is the most "effortless" in these ways because I've actually studied it and am not self taught in many aspects of audio. However, this means that any mistakes I make are harder to deal with because I feel like I "should know better". Additionally, sometimes I'll misjudge how fast I can do something in audio just because I know I'm better at it and will end up spending extra time on audio that wasn't anticipated.

I'm also a bit apprehensive that I'll get stuck at my current skill level when doing quick audio projects. I feel like I'm pretty good at making a short (1-4 measure) audio loop like I did in this game, but I'm not that great at making longer loops or generative music. I need more practice making other types of music, but I keep choosing projects that don't demand that I work on more complex music.

Jam Goals

Right now, I think in each short game jam, I'm going to be able to create a project that excels or explores concepts in ONE specific category, while everything else needs to be at a similar level to what I've already done before. For example, in this game, I explored movement and character physics. That doesn't mean I won't develop skills in other categories, as it's still good practice otherwise. However, I think I will likely have one category that stands out above the rest and should try to acknowledge this and plan accordingly before I go into developing my game.

Review

Overall, there's a lot of personal successes that I had in this project, but I'm not all too impressed with the project as a whole. I'm satisfied with the fact that I made a whole game in only a few hours. I think I should make sure I don't lose sight of that specifically. It's impressive to make a game in a short time, even if it's not an impressive game in a lot of ways. But I don't really see people playing this for more than a couple minutes and it's something I won't necessarily want to revisit in the future. I don't have interest in expanding this idea into a bigger project like I might consider with my previous Trijam entries. Overall, I think this game lacked a clear vision of what it was supposed to be.