Progress Update #7
Jade Jam Postmortem
The past 2 weeks I have been working on a jam project with some former classmates. The theme was "Jade" and we gave ourselves the month of January to complete it individually. The month long deadline didn't really concern me at first, then I realized the month was half gone and I hadn't created a project file yet. With the space game I haven't really had many hard deadlines, but now I had a deadline that I felt ready to meet head-on.
Initial Planning
As a solo act on this project, it meant that I would have to do everything by myself. Programming, no problem; but design is something that I haven't really done for a full game before. I started looking for inspiration in the theme "Jade". I thought Jade could be a name, but I didn't think I had the experience to make a game with a strong narrative. I then thought of the mineral Jade which then led me to the Wikipedia page.
Reading through the article it is apparent that the gem has cultural significance around the world. Again though, I didn't feel confident in telling a strong story. That's when the identification info box caught my eye. It said that jade had a "splintery" fracture tendency. Fracture... fracture... the chaos physics system in Unreal! I've wanted to try chaos destruction since it was announced for 4.23 but never had an excuse to really get into it. This was going to be that excuse.
My first idea for a game involving breaking jade was to be a sculpting sim where you could chisel away at a block of jade to make some of the popular figures made with jade. Looking further into the chaos system though, it seemed like this wouldn't work because the destruction is based on precomputed break locations.
The next idea was to be mining a block of stone for all kinds of valuable gems and minerals with jade being the most valuable as it is the theme of the jam. I decided to physically write down all of the things I wanted to be in the game and here's what came out of that:
Chaotic Chaos
The next step was to get chaos working in the Unreal editor. I went in with the mentality that "chaos has been out for 3 major revisions of the engine, it must be pretty stable now". How wrong I was. No matter how long it had been out, 'released in beta' still means beta.
Anyway, to get it working I just followed Epic's official guide, installed the destruction demo and went to work struggling. See, like many things in Unreal the documentation is... inconstant. So when I'm following along with the previously mentioned guide and it goes into talking about fields and how they can be "created inside the Content Browser" under the physics section, but when I try fields are nowhere to be seen, I'm a bit confused. It cost me about a day rebuilding the engine and trying little things trying to get it working.
I eventually figured out that chaos fields is part of a separate plugin. This plugin is not enabled by default and doesn't show up with the rest of the chaos plugins, despite fields being a critical part of real-time destruction. This discovery was thanks to a series of videos by Dev Enabled which also helped me better understand the chaos system.
Also, beta software being beta, I got my fair share of unexplained crashes. These could usually be resolved by pulling the latest commit of the 4.26-chaos branch of the unreal source and rebuilding it. Anyway, enough of my woes with engine problems, let's get into the making of the actual game.
Programming
After working the past almost year exclusively in C++, I forgot just how fast you can make stuff with blueprint. Seriously, it compiles almost instantly and any errors are printed clearly so you can find the root of the problem; it's perfect for jams.
Once I got chaos enabled the first thing I did was to make the centerpiece of the game; the destructible stone. This came in the form of a geometry collection of a cube that sat on top of an anchor field. (side-note: the anchor field is really buggy and each time you load the level you have to move it around a little to call 'reconstruct' otherwise the geometry collection will completely ignore it) Now that the cube wasn't exploding immediately upon spawn I started trying to get the cube to break when the user clicked on it. This is where I ran into the funkiness of collision with chaos.
So each geometry collection has a setting where you can select the collision type. Box is the default but it looks weird when it breaks as the piece suddenly has collision bigger than itself and violently pops away from the rest of the geometry. Then there's sphere and capsule which don't have that problem but will roll around on the floor forever if you don't have a sleep or kill volume to timeout the collision. Then there's 'level-set' which procedurally generates collision for each fracture piece every time the level loads (it seems to bake this collision for builds though). Level-set is the best looking at the cost of performance, as many things in game development are.
I used level-set with toned down parameters to be a little more performance friendly. I also found that having collision with the floor meant that pieces would pile up, get unwieldy, and ultimately tank performance. To fix this I just had them fall through the floor. So yes, if you played the game and were wondering, that is intentional.
Basically the only thing left to do was to get the valuables to spawn randomly inside the block and get collected when they were mined from the stone. Getting them to spawn in random positions was pretty easy because I found a built in blueprint function called random point in bounding box. Then I randomized the rotation as well and that was that.
The final big feature (and main gameplay mechanic) was collecting the valuables from the stone. In my original design doc I wanted them to be collected once they became detached from the stone without taking too much damage. While looking more into chaos collision, more specifically overlaps, I found that they were quite inconsistent and buggy, so trying to tell when a valuable became separate from the rock was a challenge. This is when I changed the method of collecting items to being a damage based system.
Essentially what I wanted was for tools to do a different amount of damage so you would have to balance the damage required to break up the stone with the damage required to collect the valuables. Once I implemented that I realized that uncollected valuables would float in midair. This brought me full circle back to the collision problem because the way I wanted to fix the floating items was to destroy them if they came detached from the stone. But if you remember in the last paragraph I couldn't figure out how to do that.
My 'workaround' was to do manual collisions for the items. Basically I would do 6 hit-scans for each item, 1 in each direction. If none of the traces hit then the item was no longer in contact with the stone and was destroyed.
UI
This was one of my favorite parts of this jam strangely enough. My only real idea for a UI in the design doc was to have a pop-up that would appear then disappear when a valuable was collected (this can be seen in number 3 at the bottom right of the page). Once I did this I became obsessed with animated UI, mostly because of the ease of use of Unreal's tools to make and play the animations. I animated almost every transition between widgets and spent significant time on the 'results' screen to make it look all pretty.
I also became kind of obsessed with the background blur widget component and transparent/fading widget elements. This mini obsession lead me to making my own 2D art for the game for the first time I think ever. All I did was make the black to transparent gradient in Gimp, but now I feel more comfortable making my own unique assets for UI. Overall I am quite proud of the UI in this project especially considering it was all done in a matter of hours for a jam.
Level Design & Art
So all of the UI was made by me, but the rest of the art was part of various free marketplace packs. Namely "Soul: Cave" by Epic Games for the environment and "Ancient Treasures" by Dekogon Studios for the valuables.
I saved level design for the end of both this blog and the development of the game for one main reason. In my eyes, a game can be fun to play no matter what it looks like so I usually save decorating for when everything is functional enough to play. I was really looking forward to using all of these assets and having a relaxing time at the end of the project knowing that the rest of the game is functional. And just like the UI, I'm quite happy with the end result. I got exactly the look I was going for and it didn't inexplicably break some seemingly unrelated part of the project like has happened to me in the past.
Comments
Post a Comment