denizk0461/pages
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

changed routes of devlog entries to new year-group system and adjusted resource paths accordingly

Browse Source
This commit is contained in:
denizk0461
2025-07-13 17:47:33 +02:00
parent fbc32be54f
commit 168e526fd8
224 changed files with 227 additions and 231 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
src/routes/projects/projectn5/devlog/2025/0203/+page.svelte Normal file
View File

@@ -0,0 +1,104 @@
<script>
import BannerTitle from "$lib/banner-title.svelte";
import Content from "$lib/content.svelte";
import TableOfContents from "$lib/table-of-contents.svelte";
</script>
<svelte:head>
<title>The Making of a Protagonist, Part III | denizk0461</title>
</svelte:head>
<Content>
<BannerTitle title="Project N5 Progress Update: 2025-02-03" subtitle="The Making of a Protagonist, Part III" banner="../../previews/2025/0203.webp" />
<TableOfContents />
<p>While I've been busy working on another game with friends lately, I've managed to almost completely finish Laura. Here's what I've achieved!</p>
<h2 id="eyes-hair">Visual Personality Adjustment</h2>
<p>As promised before, I've worked on Laura's head a bit more. Her full face shield has been replaced with a face mask / respirator covering only the bottom half of her face. Also, I finally got the hair into a state I'm actually happy with. Here's a comparison:</p>
<div class="horizontally-centre-aligned">
<img src="../../2024/1222/laura-hair-flat-new-3.webp">
<img src="laura-head-new.webp">
</div>
<p>The eyes took some work to get right, but I'm pretty happy with the current result. They're not proper eyeballs, but instead they're embedded into the head, which visually isn't significant because the flat shading would hide these details anyway. She has a brown left eye with a small sparkle, as well as a right eye replacement. This implies that Laura sustained further damage to the right side of her body, which necessitated replacement of her eye in addition to her right arm.</p>
<p>It's actually the result of UV unwrapping her model. Previously, every colour was its own material, which I wanted to change by switching to a texture atlas. Initially, of course, the UVs were a bit messed up, which resulted in this look:</p>
<img src="laura-uv.webp">
<p>I still think this looks kind of cool.</p>
<h3 id="hair">New Hair 💇‍♀️</h3>
<p>Her hair is now not a cohesive mesh anymore, but rather made up of something between 15 and 20 individual strands using custom normals to get a flat look. It also has a faint gradient, changing from a brighter colour at the top to a darker shade at the bottom.</p>
<p>I added earrings too:</p>
<img src="earrings.webp">
<p>Just some small metallic rings that I thought looked cool. For positioning these correctly, I hid Laura's back hair at one point, which gave me the idea to model a ponytail / tied-up alternative hair look for Laura. I think it'd look really cool. I haven't created this yet, but I've laid some groundwork to make it work:</p>
<p>Laura's hair is now separate from her main mesh. The main mesh is rigged using a metarig generated through Rigify, whereas the hair has a manually-created armature. Also, the hair is split into the front part and the back part, separated by the hair band (which is part of the main mesh). This allows me to replace the flowing back hair with a ponytail easily in-engine without swapping out the entire character.</p>
<p>This is pretty cool, because I can now create scenes for each hairstyle, set them up with <a href="/projects/projectn5/devlog/2024/1222/#hair-animation">jiggle bones</a> to create flowing hair, and essentially add a toggle to switch between them in-game!</p>
<h2 id="rigify">Rigging and Using Blender's Rigify</h2>
<p>Rigify is really cool for rigging characters easily. However, you need to know some things that I didn't before you start using it:</p>
<ul>
<li>When adding a Rigify armature to the scene, <i>do not parent the rig to the model</i>. You need to place the rig as intended, then click on "Generate rig", and then parent the <i>new</i> armature with the mesh and weight paint that way. I made the mistake of weight painting before generating the rig, which isn't transferrable because the metarig adds extra bones which require individual weight painting (e.g. the thighs being made up of two bones instead of just one).</li>
<li>Know how to switch between forward kinematics (FK) and inverse kinematics (IK). At the top right of the editor, there'll be a window with a slider to switch between FK and IK, as well as buttons to transfer an FK pose to IK and vice-versa. Don't be confused if posing a specific control doesn't work – you might need to switch to FK or IK, respectively.</li>
</ul>
<h2 id="face">Facial Animations and Shape Keys</h2>
<h2 id="animation">Animation and Framerate</h2>
<p>I've been playing around with the idea of using a lower framerate for the animations. I got the idea from <a href="https://www.youtube.com/watch?v=_KRb_qV9P4g">Noodle's video on animation</a>. Not sure whether I'll go through with this, but if I do, I think I'll go with 15fps or 20fps animation, since that's easily implementable a 60fps environment.</p>
<p>I already adjusted the jiggle bone script, which was easy to do since it runs in Godot's <code>_physics_process(delta)</code> function. This runs 60 times per second, so having code run only 15 times per second, for example, is as easy as wrapping the code in question in <code>if Engine.get_physics_frames() % 4 == 0:</code>, which makes a code block run only once every 4 frames – 60fps/4 == 15fps.</p>
<h2 id="in-engine">Laura In-Engine</h2>
<p>Since the shader I'm using in Blender is quite different from the one I am planning to use in Godot, here's a shot of Laura with the Godot shader:</p>
<img src="laura-shader-inengine.webp">
<p>I've been thinking of adding an option (perhaps as a cheat code) to change her outfit's colour – hair band, sweatshirt, and the rings on her right prosthetic fingers. I first didn't know how to implement this, but now that I've learnt a bit on how to use shaders, I think this could be achieved with a custom UV mask and a parameter that determines at which position the UV is sampled from – the UV would then contain several colour options.</p>
<h2 id="pics">Some Funny Pictures</h2>
<div class="horizontally-centre-aligned">
<img src="ok.webp">
<img src="dance.webp">
<img src="naruto.webp">
</div>
<div class="horizontally-centre-aligned">
<img src="shock.webp">
<img src="reprehension.webp">
<img src="disgust.webp">
</div>
<h2 id="future">The Future of this Devlog</h2>
<p>I feel that this blog-like format makes me think that the content here should be educational; that someone may read this and learn from it. It's likely not the case, but either way, perhaps it would make sense to limit the progress updates to a mere "here's what I made!" and only a little bit of background, if it's interesting.</p>
<p>Most times, I find myself struggling to explain my progress anyway, mostly since I'm learning as I go and because I publish progress updates pretty rarely. For example, I added eyes to Laura's model on 2025-01-01, there's no way I'll remember everything I did and thought of over a month ago.</p>
<p>Switching to a more short-form content format might help in publishing updates more regularly, and being more in the style of: "hey look at this cool thing I made!" It would also focus on visual changes, possibly helping me to keep a better schedule, merely because I can see my progress more steadily and be motivated more frequently.</p>
<p>I've been thinking of creating an Instagram account for that – though I despise Meta (and Instagram by extension). It feels like a decent platform for my idea, though: presenting progress mostly through visuals. I also know more people who are on Instagram who may follow my progress... maybe. Bluesky <i>may</i> be an option, though it's more text-focussed and more short-form than Instagram.</p>
<p>Either way, I'd lose out on the progress I've already shared here.</p>
<p>Or maybe I just don't share my stuff at all and don't stress out about it lol, no one's seeing this anyway and I'm not a social media person anyway.</p>
<p>idk</p>
<p>Maybe it's time to change the format of the devlog on this website?</p>
</Content>

178
src/routes/projects/projectn5/devlog/2025/0316/+page.svelte Normal file
View File

@@ -0,0 +1,178 @@
<script>
import BannerTitle from "$lib/banner-title.svelte";
import Content from "$lib/content.svelte";
import TableOfContents from "$lib/table-of-contents.svelte";
import Video from "$lib/video.svelte";
</script>
<svelte:head>
<title>Refactoring | denizk0461</title>
</svelte:head>
<Content>
<BannerTitle title="Project N5 Progress Update: 2025-03-16" subtitle="Refactoring" banner="../../previews/2025/0316.webp" />
<TableOfContents />
<p>I've been making a lot of progress in a lot of different areas, so I won't be able to elaborate on every little detail, but I'll focus on more major things. Excited to share what I've been working on!</p>
<h2 id="laura">Introducing: Laura</h2>
<img src="laura.webp">
<p>Laura is finally, <i>FINALLY</i> a playable character in the game!! I cannot overstate how cool this is. To finally see the character I've been creating for actual MONTHS in my game is HUGE.</p>
<p>As you can see in the screenshot above, Laura has a toon shader applied – it's <a href="https://godotengine.org/asset-library/asset/1900">this one again</a>.</p>
<p>With the implementation of Laura came some other changes as well. The over-the-shoulder camera had already been adjusted to fly over the character's left shoulder, but now Laura also holds the weapon in her left hand. Plus, the camera was changed, because Laura is smaller than the chunky robot I had in her place before.</p>
<img src="laura-spinning.gif" style="max-width: 400px; object-fit: cover;">
<p>I even added swooshy hair using the JiggleBones plugin, though I've already removed that plugin from the project, which I'll elaborate on later.</p>
<Video src="hair-swoosh.mp4" />
<p>I was also able to implement <code>LookAtModifier3D</code> to make Laura look at any enemy she's targetting. In the video, however, you can also notice that Laura's irises don't follow her head. That's a bug and it'll be fixed soon-ish.</p>
<Video src="look-at.mp4" />
<h3 id="not-happy">...and I'm not happy about it?</h3>
<p>I want to change Laura.</p>
<p>While I'm super happy that I was able to create a relatively decent mesh (topology-wise) that even animates fairly alright, I think Laura in her current form is boring. She <i>is</i> meant to be a 'regular girl' just being thrown into this dystopian world and unfamiliar (combat) situations, but... it doesn't have to mean that she has to look boring. Consider her clothes in particular; right now, her clothes are straight, clean, uneventful, and it's even worse on the back (where you, as the player, will consistently see her), since I've primarily focussed on modelling her from the front. There's <i>nothing</i> interesting in the back, by which I mean something akin to Ratchet carrying Clank on his back, Banjo carrying Kazooie, or even just a neat backpack or belt.</p>
<p>I think Laura (being born in the 28th century) should look more futuristic, more interesting, and just overall more unique! I also want to make changes to aspects such as her hair, because while I have found out how to animate it in-game, it looks pretty unappealing. Plus, laying the back hair was kind of difficult; making it follow the flow of her shoulders meant that it would not deform properly when running. Making it straight would mean it clips through her torso when standing still. I <i>do</i> have an idea for how to fix that – by modelling it straight and then placing a capsule as collision shape for the <code>SpringBoneSimulator3D</code> – but this didn't even exist when I modelled Laura.</p>
<p>Also, I think I want to go with <a href="/projects/projectn5/devlog/20250203/#hair">tied-up hair</a> instead. Not only does it animate much easier without clipping, but it'll give Laura a more unique silhouette, I believe!</p>
<p>I've been doing some sketching in a new B5-sized (much better size than A5 for sketches, I reckon) notebook, and I'm quite excited for this.</p>
<p>While I do wonder whether I'll be able to successfully execute upon my ideas, I believe that I'll be able to create something quite cool. Not only do I now have plenty of experience creating a character, but I'm also not creating one from literally nothing anymore. I have the current Laura model as a base to work off of – though I likely will not recycle many parts, since I want to make improvements to the mesh and loop cuts for better bends. I also have <b><i>ideas!</i></b> I was struggling <i>so hard</i> to come up with ideas for Laura before, <i>especially</i> concerning her clothes!</p>
<p>I am confident that Laura 2.0 will be awesome.</p>
<h2 id="weapons">New Firepower</h2>
<p>I added two new weapons to the game! Neither one currently has a proper model, being relegated to primitive shapes, so they're not worth showing, BUT I'm quite happy about the fact I've been able to implement their basic functionality already.</p>
<h3 id="igniter">Igniter / Flamethrower</h3>
<p>The Igniter is a flamethrower with a rapid firing rate. Here is it in action:</p>
<Video src="106.mp4" />
<p>The particle effect is a single .webp that was originally meant to have a blur effect, but I used Alpha Scissoring as the transparency mode in the <code>StandardMaterial3D</code> and kind of liked the effect, so I kept it. The fire effect is BY NO MEANS finished though.</p>
<p>I was initially writing custom logic for the Igniter, which, <a href="#weapon-code">as you will see</a>, I wasn't super fond of, though I later was able to reel back the project and integrate it into automatic3.gd quite nicely. There's still a remainder of custom logic for the sfx, since the audio for the Igniter loops instead of one-off firing, but I think that can be integrated into the regular sfx script as well.</p>
<p>I've been meaning to implement the Igniter for a while, because I thought a flamethrower could be a neat addition to the roster, but given the direction I've been meaning to take <a href="#story">the game's story</a>, I think a flamethrower is unsuitable and overly brutal, especially considering that Laura's is supposed to be a 'regular girl' thrown into this ruined world. Expecting her to use a flamethrower doesn't match her character, I find.</p>
<p>Then again, you could say the same thing about the other weapons, but I think they can work better as strategic items rather than merciless killing devices.</p>
<p>This, by the way, also means that the arena will likely not make it into the final game, unless I integrate it on the premise of, for example, it serving as a colosseum of sorts where Laura can become a gladiator and risk her life for a reward.</p>
<h3 id="rifle">Unnamed Rifle</h3>
<p>The second weapon I've added is a rifle-type weapon! Whether it'll just be a rifle or a <i>sniper</i> rifle, I haven't decided yet.</p>
<Video src="107.mp4" />
<p>This rifle, unlike the Igniter, fits the ideas I've had for the story much better. I can imagine Laura using this as a long-range weapon from behind covers, possibly paired with a sliding mechanic that allows her to quickly and stealthily move between hiding spots, leaning over them to take shots... could be cool.</p>
<p>The projectile ray takes a while to spawn after pressing the fire button. This happens because the projectile uses a <code>RayCast3D</code> to register a collision with a prop or an enemy so that the projectile stops exactly where the hit occurred instead of extending further. The <code>RayCast3D</code>, however, takes a while to process collisions after being moved, so the projectile overall has 3 frames of buffer time between being created and visibly appearing to calculate its end position. This creates a short delay. Not sure 1. whether I'll fix it, and 2. how I'd fix it, though I assume it would require some reworking and potentially scrapping the <code>RayCast3D</code> idea.</p>
<p>The projectile also... doesn't exactly hit where the crosshair is pointing. I'm pretty sure this has to do with the <code>RayCast3D</code> responsible for finding the collision point being attached to the player instead of the camera (which I've intentionally changed very recently – it used to be attached to the camera!), so it doesn't actually point where the crosshair is pointing. I'll get around to it eventually.</p>
<p>The good news: it has nothing to do with the rifle, so the rifle isn't broken. The bad news: it affects every weapon, so technically, all weapons are broken.</p>
<h3 id="preview">Item Preview Window</h3>
<p>I upgraded the item preview window slightly. Previously, the weapons just spun aimlessly, but now they can be tilted using the right analogue stick or the mouse to gaze upon them better! It's a small change but I'm proud of it, so here it is:</p>
<Video src="item-preview.mp4" />
<p>I also fixed a long-running bug where the <code>DirectionalLight3D</code> of this preview would cast light on the gameplay world. This was caused by the preview being in the same physical space as the rest of the world (unavoidable) and being on the same visual layer (totally avoidable). I changed the layers, adjusted the light so that it doesn't contribute to the sky (very important with a shader that takes the scene's main light into consideration!), and it relieved a great headache that caused oddities such as two specular highlights on every model that received light.</p>
<h3 id="weapon-icons">Please Appreciate These Wonderful Temporary Weapon Icons</h3>
<div class="horizontally-centre-aligned">
<img src="104-icon.webp">
<img src="106-icon.webp">
<img src="107-icon.webp">
<img src="108-icon.webp">
</div>
<h2 id="code">Grand Code Overhaul</h2>
<p>In (re)starting work on my game, I've been confronted with a lot of... <i>legacy code?</i> Lots of code that I was unhappy with, at the very least.</p>
<p>I've found that a lot of the code I've written – which at this point is up to 1.5 years old – isn't really up to par with what I want to write. It's inflexible, verbose, doesn't always follow standards and best practices, and overall really needed some overhauling. So, I've been doing just that.</p>
<p>I simplified logic, standardised scenes and code for game objects that share logic, implemented both inheritance and component-based designs where appropriate, and just yesterday, I've moved the code for fading in/out a black screen as well as the message handler displaying text such as "Collected 12 N5 Blaster ammo" and "Open vendor" into autoloads – I learned <i>this morning</i> that autoloads can be full scenes (.tscn) instead of just code (.gd). It makes a lot of sense, retrospectively, but now I'm just happy to have simplified some areas where I was unnecessarily passing references. For instance, displaying a text such as "Collected ammo" required the node response for collecting that ammo to have had a reference to the player, who in turn had a reference to the message handler and thus could display messages. This approach was overly convoluted.</p>
<h3 id="godot-4-4">Godot 4.4 Changes</h3>
<p>If you haven't heard, Godot 4.4 is out! And that meant quite a few changes for my game:</p>
<ul>
<li><a href="https://github.com/godotengine/godot/pull/99895">Jolt is now integrated into the engine!</a> Since my use of the physics engine is relatively basic and does not rely on Jolt features that haven't been implemented in the engine yet, I switched immediately and was able to remove a dependency. The work that went into this is insane, I recommend checking out the pull request.</li>
<li>Godot 4.4 added a new node called <a href="https://docs.godotengine.org/en/stable/classes/class_springbonesimulator3d.html"><code>SpringBoneSimulator3D</code></a>, which can be used for jiggle physics in a similar manner to <a href="https://godotengine.org/asset-library/asset/1595">JiggleBones</a>. I replaced my JiggleBones implementation with <code>SpringBoneSimulator3D</code> and was thus able to remove another dependency. I like the <code>SpringBoneSimulator3D</code> setup better, though I'm not as happy with the current result. I'll have to spend more time tweaking it and learning how to use it properly; it involves a bit more setup than JiggleBones, but it's more reliable, especially since it has better support for collision shapes (JiggleBones only supports spheres, but it's very rudimentary support, and they have to be sized way larger than expected to work at all. It's very unreliable. <a href="https://docs.godotengine.org/en/stable/classes/class_springbonecollision3d.html#class-springbonecollision3d"><code>SpringBoneCollision3D</code></a> works <i>so much better</i> and supports capsules and planes as well).</li>
<li>Physics interpolation is now available for 3D, which fixed <a href="https://phantom-camera.dev/support/faq#i-m-seeing-jitter-what-can-i-do">an issue that caused nodes tracked with a Phantom Camera to jitter</a>.</li>
<li>Godot has typed <code>Dictionary</code> support in <code>@export</code> properties now, which in <i>my world</i> is a <b>huge</b> deal. It means you can do <code>@export var dict: Dictionary[int, String]</code> and dynamically add to the Dictionary in the inspector. This, of course, allows for custom <code>Resource</code>s as well. I use this, for example, in the item statistics, where I have a <code>Dictionary</code> holding item statistics as a custom <code>Resource</code> associated with the item's ID. This <code>Resource</code> has nested <code>Resource</code>s for individual weapon levels. It's <i>so</i> cool! I'm disproportionately happy about this change.</li>
</ul>
<h3 id="node-refs">$</h3>
<p>Yesterday, I replaced a lot of $ node references with <code>@export</code> properties for performance reasons. I watched <a href="https://www.youtube.com/watch?v=fb68YXIBinc">this video on node retrieval</a>, where I found out that $ references are inefficient. I then thought about this, and... yeah, that makes sense. $ is just a short-hand for <code>get_node()</code>, which means that, in a <code>_process()</code> context, I'm calling <code>get_node()</code> potentially 60 times a second – every time I use it. Considering this <i>massive</i> performance implication, I refactored a lot of code and created loads more <code>@export</code> references. They're easier to manage in case of moving or renaming nodes, anyway.</p>
<h3 id="weapon-code">Weapon Code</h3>
<p>The weapons received some of the biggest changes. Previously, I had a bunch of different classes for a base weapon, semiauto, automatic, and thrower weapon (the last one being a semiauto weapon that fires in an arc), and they all kind of did similar things. I first used inheritance, then switched to a component-based design, where I still needed more boilerplate than I was comfortable with. The thrower in particular copied all the code from the other weapon types, just with changed logic for the projectile path.</p>
<p>It was a mess. It's all overhauled now.</p>
<p>There's <code>weapon3.gd</code>, which is the base weapon class for all weapons, inheriting from <code>item.gd</code>. Then, there are <code>semiauto3.gd</code> and <code>automatic3.gd</code>, which implement only the functions to determine what happens when the player presses and releases the shoot button – one of them fires once, the other one repeatedly.</p>
<p>Notice there's no <code>thrower3.gd</code>? It's unnecessary. The logic for the arc has moved into the projectile. Why would the weapon be responsible, I asked myself, considering that the throwers otherwise acted identically to the semiauto weapons. I also moved a lot more properties away from the weapons; damage and speed, among other things, have been moved to the projectile. AoE damage and radius, for example, have been moved into the explosion that's spawned by the projectile upon impact. I've generally moved properties to where they're needed instead of bunching them all up at the weapon and then sending them over via long and unnecessary functions. Like, for example, a function that spawned the projectile, which used to look like this: <code>start_moving(direction: Vector3, ramp_up_speed: float, damage: float, explosion_resource: PackedScene) -> void</code></p>
<h2 id="enemies">My Enemies Follow Me Wherever I Go</h2>
<p>The enemies have pathfinding now implemented! I used Godot's <code>NavigationRegion</code> to create a mesh the enemies can traverse. Since they all inherit from <code>StairsCharacter</code> – a class I once downloaded to deal with stair stepping for <code>CharacterController3D</code>s – they can traverse the world about as easily as the player. It works super well! I was able to piece it together quite quickly, after a friend of mine figured out how to implement navigation in another game we're working on together.</p>
<Video src="enemy-stairs.mp4" />
<h2 id="story">Story Changes</h2>
<p>I have some minor ideas for where I want the story to head in.</p>
<h3 id="genre">Where the Game is Headed Gameplay-Wise</h3>
<p>When I showed the Laura model to a friend recently, they noted how she doesn't look like she belongs in a shooter, but more of a puzzle-type game. I think that incorporating some elements of that sort could be quite cool, actually; solving problems to uncover the mystery of what happened to Laura's world.</p>
<p>That's the general idea.</p>
<h3 id="story-weapons">How (Many) Weapons Will Play Into It</h3>
<p>Heading into this direction means that a large arsenal makes less sense. While I do still want to have combat elements, I've considered reducing the amount of weapons from 12 (which was even as high as 16 way earlier) to 8 or even just 4.</p>
<p>The amount of weapons in the game also impacts UI: having 8 weapons total would warrant a quick select, like the one currently implemented – though I'd probably make it look a bit more similar to Ratchet: Gladiator, where it is displayed in the upper left corner of the screen. 4 weapons total might instead be served through selection via the d-pad (or numbers 1-4 on the keyboard), though.</p>
<h2 id="notebook">A Notebook for My Thoughts</h2>
<p>I bought a new notebook recently! While I had a notebook before – a <a href="https://www.thalia.de/shop/home/artikeldetails/A1071363499">green A5 notebook with dotted pages by Share</a> – it was filling up with notes from university, internships, and other miscellaneous things I didn't want to clutter my project notebook with.</p>
<p>I switched to a <a href="https://www.thalia.de/shop/home/artikeldetails/A1071895735">black B5 notebook, also with dotted pages, by Plan A</a>. This cost me a lot less than a Leuchtturm1917 B5 notebook (like 60% cheaper) and still totally serves my needs. I like the B5 format, it's just a fantastic size. It's bigger than A5, which allows for more expression, details, and overall just breathing space on the pages, but it's also not as big as A4, which would be unwieldy. B5 is a superb format for my sketch notebooks; can recommend.</p>
<h2 id="bsky">Bluesky</h2>
<p>I have a <a href="https://bsky.app/profile/denizk0461.bsky.social">Bluesky account</a> now!</p>
<p>I've been eyeing the platform for a while now, but lately I've noticed that quite a few people I enjoy following have Bluesky presences. Plus there are other cool people there, as well as the Feed feature where I can, for example, see all Godot-related content. I've created an account with the idea of potentially posting some of my gamedev progress on there, though I have not yet shared anything. Still figuring out social media; while I grew up during the rise of social media (on mobile phones in particular), I've never really been into them quite as much as others have.</p>
<p>Maybe this'll be different though, seen as I have a relatively specific goal here. We'll see!</p>
<h2 id="addendum">Addendum</h2>
<p>Sorry for the walls of text! I've really just been working more on backend stuff than visually interesting things, mostly to clean up the project, but also because I feel that's my strength. I'm super good at programming expandable, relatively easy to maintain code, at least in comparison to my artistic skills. However, I'm <i>absolutely</i> working on story, visuals, more weapon, and of course Laura 2.0, so hopefully I'll have more to show for in the coming weeks and months!!</p>
</Content>

108
src/routes/projects/projectn5/devlog/2025/0427/+page.svelte Normal file
View File

@@ -0,0 +1,108 @@
<script>
import BannerTitleAlt from "$lib/banner-title-alt.svelte";
import ContentSidebar from "$lib/content-sidebar.svelte";
import TableOfContents from "$lib/table-of-contents.svelte";
import Video from "$lib/video.svelte";
</script>
<svelte:head>
<title>The Making of a Protagonist IV | denizk0461</title>
</svelte:head>
<BannerTitleAlt title="The Making of a Protagonist, Part IV" subtitle="Project N5 Devlog" date="2025-04-27" banner="../../previews/2025/0427.webp" />
<ContentSidebar>
<TableOfContents slot="side-left" />
<div slot="main">
<p></p>
<h2>Current Progress</h2>
<p>As promised, I've been working on Laura v2 – which has now become v4. On the right is the current/soon-to-be previous model of Laura, on the left is my current progress on her new model!</p>
<img src="laura-comparison.webp">
<p>(By the way, the left picture is the most recent version of the model. Other pictures on this page will be older and may have some slightly different details!)</p>
<h3>New and Improved</h3>
<p>Notable differences are:</p>
<ul class="styled-list">
<li>Laura wears a cropped zip-up hoodie with a more saturated colour than before, and a black shirt underneath. Her clothes are generally fairly similar between versions, though her dimensions and especially the topology are quite different and optimised.</li>
<li>Her shoulder area was a previous pain point of mine – notice the completely smooth transition from neck to arms in the right model. In the new version, her shoulders have been given much more shape.</li>
<li>Her hoodie's colour is more saturated than before. The comparison here is not quite fair, since the left is an image from Blender and the second is from Godot, thus impacting how the colours look since there are different shaders used, but the idea still stands.</li>
<li>Her hair is tied-up in a ponytail, which not only looks cooler, but is also way easier to animate, imo.</li>
<li>Her eyes have been refined in shape and her lashes/eyeliner have been extended to wrap around her eyes more, which, in my opinion, looks quite a lot sharper than before.</li>
<li>Her eyes have been socketed in a different way. Previously, they were flat faces directly behind her irises, but now they're much more recessed, which likely/hopefully won't be visible using flat shading. I also edited the normals to look less like the sclera is recessed. I'm hoping this'll make animating easier, since the irises can now move more freely without clipping into the sclera.</li>
</ul>
<img src="laura-comparison-eyes.webp">
<h3>Things to Work On</h3>
<p>Parts that have not yet received much attention are:</p>
<ul class="styled-list">
<li>Her trousers, which have received a general shape, but no details.</li>
<li>Her belt, oxygen mask, and left hand, which are mostly copied over and adjusted to not look completely out of place.</li>
<li>The shoes, which are placeholders.</li>
<li>The right arm, which is notably present in the picture, but nowhere near finalised and to be attached.</li>
<li>Her hair, which is present only in a basic shape to serve as a placeholder for what I have planned.</li>
<li>I might add her hair band back.</li>
</ul>
<h3>Further Thoughts on Modelling</h3>
<p>This model is supposed to look more dynamic and lively than the previous one. I want to more granularly animate the hair by adding more bones to individual strands. I'll also add bones for the hood so that it can bounce up and down when running. I'm also considering adding bones to allow the sleeves and trouser legs to move slightly, though I'm not sure if I'd be able to make that look good, so I'm keeping this idea in the 'optional' pile for now.</p>
<p>I think what helped with modelling this time around was that I let go of the notion that Laura should be a low-poly character. I started out that way when I was modelling v1 but then I changed my mind, which created some problems, I find. This time, I still don't want to go crazy with tris, but it's not as much of an issue to me. At one point I even intended to subdivide her entire model by 1 level to smoothen some rough edges and overall make the model a bit more polished, but I discarded that idea yesterday.</p>
<h3>The Eternal Hair Struggle</h3>
<p>I've <a href="/projects/projectn5/devlog/2024/1222/#hair">struggled with hair before</a>, and it's not gotten <i>much</i> better. Check out Laura's current ponytail:</p>
<img src="ponytail.webp">
<p>Looks like a banana!</p>
<p>I think my next try will be to polymodel strands of hair out of subdivided planes. It'll increase the poly count quite significantly, but it's a trade-off I'm willing to make for hair that'll look better and flow (animate) much more nicely!</p>
<h3>wdym v4?</h3>
<p>The current version of Laura is based on the following sketches:</p>
<img src="body-sketches.webp">
<img class="inline-img-left" src="laura-v2.webp">
<p>I worked with these sketches to create the first remodel of Laura. Originally, I was decently happy with the result, though her sleeves seemed boring – just ballooning and lacking an interesting shape.</p>
<img class="inline-img-right" src="laura-v3.webp">
<p>I had quite a few ideas to improve the current and rather boring Laura model. At the centre of the remodelling was keeping Laura's character but giving it more edge through a more unique silhouette. I wanted to accomplish this by adding textures and detail, layering clothes, and giving more shape to her.</p>
<p>Eventually, I had a different vision for Laura, though. This time, she would wear a dress with a long-sleeve shirt beneath. I liked this idea because it showed off the shape of her legs more, whereas the previous idea would hide them inside of straight-cut trousers. It would just look more interesting, I felt. I was also inspired by some 3D models I saw on Pinterest.</p>
<p>While I generally liked the idea, there were two major problems: firstly, I felt I wasn't really able to execute the idea in a way that I found fitting. Secondly – and this plays into the first aspect – the model didn't look as mature as I liked. Partially in its style, but also in its execution.</p>
<p>This v3 of Laura was then superseded by another Laura, which essentially went back to the previously style, though I used v3 as a base due to some improvements I made on the model. Thus the new version is now called v4.</p>
<p>Notice how specifically her head and the prosthetic aren't present in the v2 screenshot – those were v3 additions.</p>
<h2 id="laura">Prosthetic Implications</h2>
<p>I'm changing Laura's amputation from its previous below-the-elbow cutoff to above-the-elbow. This is mostly a stylistic change, because it means her elbow will be a mechanical replacement as well, and that might look cool, I think.</p>
<p>I've also been thinking about how her prosthetic could play into the story. A while back, I watched <a href="https://www.youtube.com/watch?v=jZfgQTC9CEA">this video by champutee</a> on arm amputee representation in video games. Admittedly, I feel I'll likely fall into quite the same categories in some ways, making Laura's prosthetic so advanced that it'll more or less serve as a perfect replacement for her organic arm. I had a potentially neat idea that would impact gameplay, though.</p>
<h3>Difficulty Scaling</h3>
<p>At one point in the game, Laura could lose function of her prosthetic entirely and be forced to continue without being able to use it. This would reflect in gameplay especially because Laura would then be unable to use any two-handed items, which will include a majority of her weapons as well.</p>
<p>Laura will likely have something between 4 and 8 weapons available to her. I'm thinking that some will be two-handed from the start (including her main rifle), and some will level-up from one-handed to two-handed or dual-handed (for example, a blaster in each hand). This would mean that more advanced players who progress quicker and manage to level up their weapons early (through XP, collectibles, or purchases, I've not decided) will face a greater challenge, since more of their weapons will be levelled up to their two-handed versions, thus making a larger part of their arsenal unavailable for this part of the game.</p>
<p>In my teacher training, we call this type of catering to different skill sets <i>differentiation (Differenzierung)</i>!</p>
</div>
</ContentSidebar>

76
src/routes/projects/projectn5/devlog/2025/0523/+page.svelte Normal file
View File

@@ -0,0 +1,76 @@
<script>
import BannerTitleAlt from "$lib/banner-title-alt.svelte";
import ContentSidebar from "$lib/content-sidebar.svelte";
import TableOfContents from "$lib/table-of-contents.svelte";
import Video from "$lib/video.svelte";
</script>
<svelte:head>
<title>Reboot | denizk0461</title>
</svelte:head>
<BannerTitleAlt title="Rebooting the Project" subtitle="Project N5 Devlog" date="2025-05-23" banner="../../previews/2025/0523.webp" />
<ContentSidebar>
<TableOfContents slot="side-left" />
<div slot="main">
<p>20 months after starting <i>Project N5</i>, I decided to restart the project. In fact, a friend of mine assumed I'd do it all the way back in December 2023! Initially, I resisted, though I toyed with the idea for quite a while, before finally deciding that this is best for the project last Friday (<b>2025-05-16</b>).</p>
<h2 id="why">Why?</h2>
<p>There are two main reasons for starting the project from scratch again.</p>
<h3 id="improvement">I Improved</h3>
<p>The first reason is simple: I improved as a programmer.</p>
<p>Back when I started <i>Project N5</i>, I had never actually used Godot before. This project was my first experience developing in Godot, and to a greater extent, my first attempt at making a full-scale game! I set out a huge goal for myself, though I welcomed the challenge.</p>
<p>With stagnation in my progress especially in the summer of 2024, I felt I outgrew the project's codebase in some way. Also adding to that is the fact that I was working on <a href="/projects/#projektike">another game</a> with two friends, where I had to write clean solutions and well-structured code to keep the project modular (especially during the stage where we hadn't quite figured out where to take the project) and understandable for the others. This resulted in me learning the ropes of Godot and GDScript much more than I had before.</p>
<p>I initially tried to tackle the issue by refactoring the codebase of <i>Project N5</i>. Even though I made significant progress, I later felt that the codebase was flawed from the core. I felt this way especially while I was recently trying to implement a new weapon – what a hassle that was!</p>
<p>Which leads nicely into my second reason...</p>
<h3 id="changes">The Project Changed</h3>
<p>For quite a while after I started <i>Project N5</i>, I didn't know where to take the project. In fact, I was stuck at the idea of a robot protagonist for <i>such a long time!</i> Laura only came to mind <a href="/projects/projectn5/devlog/2024/1127/">much later</a>. With her, however, my ideas for the project started to change slightly.</p>
<p>Don't get me wrong – the essence of the game is probably still pretty much intact. However, I want to make the game a little less combat-focussed, which meant that especially the weapon structure I had built up made no sense anymore. I built the system specifically so I could implement as many different weapons as I liked. Recently, though, I decided that 4 is enough, which made the grand system redundant.</p>
<p>Add to this the fact that, with a lesser focus on combat, an <a href="/projects/projectn5/devlog/2024/0324/">arena</a> made <i>no sense at all!</i></p>
<p>Trying to bodge my old codebase – "Altlasten mit sich tragen", as one would say in German – felt wasteful.</p>
<h2 id="currently">The Current State of the New Project</h2>
<p>Considering I started one week ago, I'm doing decently well:</p>
<img src="over_the_shoulder.webp">
<p>What you can see here is my new Laura model (not yet finished!), with a partially-applied toon shader and an outline shader on top. The UI elements include a health counter (on top), a money counter (bottom right), a placeholder for the popup menu(s), a crosshair in the middle of the screen (the dot), and an aim helper texture also in the middle of the screen (the cross). The two boxes represent enemies, not in function, but in their physics layers and in targetability.</p>
<p>There are a lot of improvements: targets, for example, are now not defined by a special node setup, but rather by a <code>Target</code> prefab, which can easily be positioned anywhere (enemy or environment) and be used to guide player projectiles.</p>
<p>The code is also <i>so much more streamlined...</i> I put many elements into their own components to avoid cluttering the <code>player.gd</code> script with an overwhelming amount of responsibilities. That way, what was previously a 300+ line script handling player movement, aim direction, messages, equipping items, interacting with objects etc. is now a lean 50+ line script (although ofc not everything from the previous project is implemented here yet, such as the vendor interactions). Anything that's not directly related to the player has its own component script to keep things separated as much as possible. Currently, there is also no singleton <code>SignalBus</code> routing wildly between any and all nodes. Instead, signals are just defined in their components and connected directly to only the components needing them. This also means that components only take care of tasks that are explicitly meant for them; the guns, for example, no longer calculate the position which the projectile is flying towards. Instead, they can now simply retrieve an aim direction from the <code>AimManager</code>, requiring much less code in each weapon. Everything's so clean and I love it.</p>
<h3 id="weapons">The New Weapon Arsenal</h3>
<p>Check out the new weapons:</p>
<img src="new_weapons.webp">
<p>With these, and with the UI in the previous screenshot, you may have noticed a theme: I'm putting less time into temporary assets. While nice to play around with, it's unnecessary to spend an hour designing a UI element when I already know I'll 100% replace it down the line. Thus, most elements are either entirely simplistic (text, primitive MeshInstance3D, etc.), or just very simple textures.</p>
<h2 id="continuing">Continuing</h2>
<p>Progress has been quick, which I really liked. It felt as if project development picked up again. Of course, a lot of this has to do with the fact that I'm just programming things I've already once programmed, so I have to put less time into coming up with ideas and can instead solely focus on the implementation. However, I feel that this cleaner codebase will allow me to expand much more easily and develop a less bug-ridden game than if I had simply continued with the old codebase.</p>
<p>I'm happy I took this step!</p>
<img src="taking_aim.webp">
</div>
</ContentSidebar>