#cmdev

[rootvegetableboy]

chorus machine dev log #18 - april 2025

another 1st of the month? no problem, another dev log! in log #18 (can you believe it's been a year and a half of development?) i discuss my long break, new sound effects, and not showing my entire hand. come check it out!

[laravelvuejs]

สอนเขียน VueJS #9 - Vue Router (Page Navigation)

สอนเขียน VueJS #9 – Vue Router (Page Navigation)

หากท่านอยากสนับสนุนเรา CMDev Channel ท่านสามารถช่วยเราได้ เพียงแค่แวะเข้าไปชมหลักสูตรของเราที่ http://www.codemobiles.com ซึ่งหลักส. source

[teknoiot]

Sertifikasi Database Populer Saat Ini

Sertifikasi Database Populer Saat Ini...

Sertifikasi database populer selalu diminati, apakah itu sertifikasi Microsoft MCSA dan MCSE SQL, OCA Oracle, OCP, dan OCM atau CMA, CMDEV, dan CMDBA MySql.

Apakah Anda seorang profesional database yang ingin memoles resume Anda dengan harapan mendapatkan posisi yang lebih baik? Mungkin Anda baru saja memulai dalam administrasi database, dan Anda ingin membangun kredensial Anda di lapangan. 

[rootvegetableboy]

cm dev log #14 - december 2024

here it is, the final log of 2024! in this one i talk about the title reveal, last-minute porting, strangers playing my game, the importance of tiny details, and even... my plans for 2025?!?! come check it out!

[rootvegetableboy]

chorus machine dev log #15 - january 2025

five days late but i DO deliver!! january dev log is here!! talking all about finally putting my save/load system together and how coding souls mechanics gave me a headache. really happy with the work i got done last month!

[rootvegetableboy]

chorus machine dev log #16 - february 2025

happy March! i didn't work on my game in the entirety of february! so… what did i even write my dev log about, you ask? well, why don't you come find out?

[rootvegetableboy]

cm dev log #13 - november 2024

hi everyone! i've copied all previous dev logs to my neocities; existing logs will stay on my tumblr, but this + all entries going forward will only be posted there. i'll still post a link here whenever there's a new entry :) hope everyone had a great month!

[rootvegetableboy]

cm dev log #12 - october 2024

happy november! welcome to dev log #12!!! i can’t believe it’s been an entire year since i started development. happy one year birthday to my little project :’) now cm can reasonably start taking steps… yahoo!

as you all might remember, i got top surgery on september 30th, so october has mostly been a recovery month for me. post-op brain fog is very real and not to be underestimated… so, it’s another shorter log this time. but i’m only feeling better & better every day, so hopefully there will be more to discuss in november 24’s log ^_^ onto the content!

SMALL FIXES:

i don’t think these count as “bug fixes” because there was no error message or anything… it’s not like the game was crashing… they were more like little quality of life adjustments.

whatever current song is playing will now fade out if you die. at some point in the last few months i finally got around to writing music for the first miniboss fight, and during testing a couple weeks back i realized the INTENSE MUSIC continuing after death kind of threw off the vibes. i’ll probably write a tiny little song/soundscape for the deathscreen at some point, but for now you get eerie silence ^_^ yayy

i noticed the weapon reload timer wasn’t properly centered over the player sprite and scooched it over a few pixels.

i changed the first miniboss’s collision mask from an ellipse to a rectangle.

i changed a bunch of the room names. formerly my naming convention for rooms was numbered: rm_floor1_1 followed by rm_floor1_2 followed by rm_floor1_3, etc. it did not take long for me to realize that this could get really confusing really fast, so i changed their names to be more reflective of their contents (rm_floor1_intro, rm_floor1_aeski, rm_floor1_hall, etc) and i now have a separate document to keep track of order & flow. this will make it a lot easier if i decide i want to put a new room in between two existing rooms, or if i want to reorder some of them.

DIALOGUE CHANGES:

i don’t think i’ve actually shown any dialogue in these dev logs? i’m a lot more secretive about my writing than i am about my art or code, but i rewrote several scenes… the previous dialogue was feeling kind of stilted & bogged down. i spent some time really reflecting on my characters’ different personalities and conflicts and rewrote most of their lines to give each character a more distinct voice & communication style. i think those scenes are reading a lot smoother and more naturally now! if you’re curious, my personal note for accomplishing this task just reads “changed [redacted] dialogue to make the girls meaner to each other”

NEW SPRITES:

remember last month’s UI sketches? i’m slowly starting the process of spriting some of the save/load menu!

image ID: pixel art of an open book. the left page has an unfinished decorated border in blue. the right page is empty.

it’s extremely unfinished!! i have a lot a lot more to draw for this system, but i’m really happy with how it’s going so far. and really happy i finally have One Proper Sprite to put in a log even if it’s far from complete…

that’s all i have for this log! if you’ve been sticking around for a whole year: THANK YOU!! i really can’t express how much i appreciate every person who has taken an interest in this project. i’ll see you in december for dev log 13 ^_^

[rootvegetableboy]

cm dev log #11 - september 2024

hi everyone! i hope you all had a fabulous september. i’m posting this two days earlier than normal because i’m getting top surgery tomorrow (yahoo!!!) and i expect to not have much energy on the 1st. i’ve had a pretty busy month with personal life/surgery prep things so this dev log is going to be fairly light on actual game content; instead, i’ve prepared some concept art i thought you all might be interested in!

CHARACTER SKETCHES!

a lot of what i worked on this month was stuff that i can’t show you: namely the script, the story’s outline, this world’s timeline, figuring out emotional beats & thematic through lines, etc. but i also did some character sketches: behold, These Guys!

alda is the player character, which you may have already gleaned if you’re a Project CM Certified Lorehound. also depicted here are thea and lyle; thea is a fat lesbian with a huge sword that can & will kick your ass. lyle is thea’s best friend/resident pretty boy and is the #1 women’s wrongs supporter. he’s extremely emotional, chaotic, and he always wants to see the best in people; thea is a lot more restrained, logical, and direct.

i love them all a lot. i wanted to have digitally drawn portraits of all three of them ready for this dev log, but my arm started cramping up, so i only have thea’s… anyway, i’m really excited for you to meet them :)

ENEMY SKETCHES!

i only have two enemies in the game right now, but i’ve been cooking up a lot of other guys to fight! here are some regular-tier (not mini/bosses) enemy concepts that i’ve been playing around with.

i’ve also been sketching out a particular boss idea… not much to say here lest i say a little too much, or lest i end up deciding to change something down the line. but i am very excited for you all to meet her, as well >:)

UI… SKETCH…ES?

this is probably only exciting to me, because no casual player should be paying much attention to the layout of the user interface. long-time followers of my development logs may recall that i have a pretty unique save/load system in place for this game; i’ve been sketching out different ideas for how i want it to look on paper, because it’s much less time consuming to do a little drawing as opposed to spending two hours coding something only to realize it doesn’t even look that good.

actually, this sketch harkens back to a drawing i did over a year ago, when i was first starting to conceptualize how i wanted the game to look:

things have turned out pretty different from the initial concept i had in mind while drawing this, but it’s still really beautiful, so i’m glad i’ll still be able to use the basic layout in some way!

that’s all i have for this log. i’ll see you all in november for my one year anniversary of development <3 i'm so excited for this little project's birthday!

see you then!

[rootvegetableboy]

cm dev log #10 - august 2024

happy september, everyone! i burned the shit out of my dominant hand this month, so, things weren’t necessarily as productive as i would’ve liked… but progress was still made for sure :)

here are a few things i worked on in august!

player death:

i did this at the very beginning of the month, as it was one of a few things necessary to release my first playtest. (more on that later!) like a lot of things i put off for months because i thought they’d be way difficult, this was a lot simpler than i’d thought it would be.

there are not a lot of moving parts to this! when your hp reaches zero, your player object is destroyed, and the death screen fades in. pressing enter at the death screen will reload your most recent save.

cutscenes and dialogue:

previously, conversations and dialogue in the game were pretty static, so i introduced an object called “obj_camerashift”. when called, this object can move both the camera & which direction the player is facing, giving the effect of the player “looking” at certain things mid-conversation.

i made a few other small changes to some dialogue-handling objects, as well. the aiming/shooting cursor now disappears when a textbox is on screen—i found being able to move the mouse around during conversations a little distracting, and i think it looks a lot more seamless this way. i also implemented an object that keeps track of plot/story related variables! surely i will not use intimate knowledge of the player’s actions against them :)

arson?

you can now set fires

fun for the whole family!

playtest one?!?!

do you guys remember last month when i said “i would love for people to playtest within the next couple months”

well… i actually moved way quicker than i was expecting and released playtest one at the beginning of august! i put out some feelers for who all would be interested back in july and was able to get a bunch of people to participate and share their feedback with me. i’ve been hearing a lot from fellow game devs about how important early and frequent playtesting is, and now i can finally say, with pride:

oh my god i get it. i am WAYYY to close to the trees. and i am so, so unbelievably grateful to everyone who took the time to test, because it really opened my eyes and gave me a much clearer picture of where things are at. let’s take a look at what people thought, and most importantly, what i learned! :)

standard enemies:

i chose to go with a goldilocks-style rating scale for the post-playtest survey. i felt like this would help me focus on the individual player’s perception and experience, because i had a lot of different ranges of skill level in playtesters. (my partner defeated the miniboss on their first try, but to my knowledge almost no other player was able to do this!)

this is a summary of responses about the difficulty of the small-scale enemies. i found it helpful to switch back and forth between the summary of all responses and individual responses when analyzing data, as often people would explain what occurence led to what choice. for example, i had one person rate Bug entirely “just right” for every category, and they explained in their written response that they enjoyed the threat level that the speed of the bug posed. i had another person rate Bug’s overall power & movement speed as “too difficult” for the same reason cited: the enemy’s speed! however, the person who found it too difficult also expressed that they don’t have much practice on keyboard&mouse games. you can start see where dev decisions start to get both more simple and more complex with access to all this info…

the summary of all responses is very helpful for analysis of overall player trends, though. i was pleasantly surprised that people tended towards finding the snake a little too easy overall (i <3 making things more difficult). i wasn’t expecting people to be so divided on the bug’s damage, so that’s one of the categories where teasing out individual responses is a little more helpful.

miniboss:

this is the most beautiful graph in the entire world to me right now.

the clear overall trend towards “just right” is so exciting for a first playtest!! it’s also a huge relief to know that the core gameplay is legitmately enjoyable. i had several people express that the miniboss fight felt rewarding because they were able to watch themselves get better at it. that feeling is exactly what i’m going for in terms of difficulty, because it’s one of my favorite feelings to have: knowing that it’s not any special levelling or number getting me through the fight, it’s just me and my skill.

though it’s really exciting to read about the aspects people enjoyed, i got a lot of insight from those that found this too easy or difficult as well. one person who found the fight too difficult suggested a small wait (”a breath or two”, they said!) between attack patterns, as they were getting very quickly overwhelmed. (i think this is a great idea!) i had another person who found the fight a little too easy in every category, and mentioned that they were able to complete the entire fight without using the player dodge mechanic at all. this is interesting to me because a lot of the people who seemed to struggle with the combat struggled with using the dodge mechanic specifically. actually, this is a pretty good segue…

player:

testers were rating the relative strength/weakness of each category offered here as opposed to “difficulty”. though, it’s sort of the same thing in this case…

anyway, as you can see, the dodge was pretty divisive.

i believe there’s multiple issues here that are compounding each other. the first is the dodge animation: it was very quickly drawn and i don’t think it gives anything in the way of juice or satisfaction to use. it’s also not even really an animation, i just change the player sprite to a static image depending on what direction they’re facing. because of this, there isn’t a clear “beginning of dodge → end of dodge” visual progression, so i think players get confused on when they’re actually invulnerable.

the second issue is the timed length of the dodge itself. playtesters only got 15 frames (or a quarter of a second) of invulnerability, which is just really difficult to consistently execute. this is especially affected by another issue about the player i had several people point out: the player hitbox was much taller than it was wide, so dodging attacks that were coming at you vertically became especially hard to pull off.

rest assured, playtesters, i have heard your cries! i have already changed the length of the dodge to 22 frames (a little more than a third of a second) and squashed the player hitbox significantly shorter. a full dodge animation is on the list of things to draw as well—hopefully these changes will help.

so it was less of a “work on actual game content” month and more of a “pace back and forth across my apartment thinking very hard about survey results” month. i’m glad it went this way though! it gave my hand some time to heal and gave me a lot to think about. i’m excited to tackle september. i don’t think i’ll do another playtest for at least a few more months, though… it was a lot of work to set up…

as a final note, in two months project cm will be one year in development… i’m thinking i will reveal the name of the game at that point. it could be nice to know what “cm” stands for…

that’s all for the august log. see you in a month!

[rootvegetableboy]

cm dev log #9 - july 2024

i think july might’ve been my most productive month yet! i really surprised myself with how much i achieved. it’s really satisfying proof that development is only getting faster & smoother the longer i go on :]

some really really exciting stuff implemented, including but not limited to…

new mechanics!

a surge/dodge mechanic has been added! press the spacebar to avoid incoming attacks! you can use this both directionally for a boost of speed, or while standing still to become invulnerable to damage for 15 whole frames. woah!!!

healing flask!! fuck everything else i’ve said in every log, good game design is all about beautiful potions. like all good potion ui, you get a little visual of your flask emptying:

reworking older systems!

i’m currently in the midst of reworking my save/load system! i’m not going to say too much, because… it’s one of the main hooks of my game… but it’s going real swell. i only have to do one more thing before this is in a workable state, which is:

i need to create a new in-game menu system from scratch =_=

this is something i’ve known was coming for a while, but i find coding UI pretty annoying sometimes, so i’ve been putting it off. the current in-game menu isn’t up to par with the artistic style of everything else, so i want to re-do it. i also plan on separating out the save/load menu from the in-game menu.

HOWEVER! i was able to do a successful collisions/hitbox rework this month in its entirety! this is huge, it’s an issue i noticed in january and has been bothering me all year!! it’s kind of hard to explain this one, so let me whip out some visual aids:

the dark rectangle around her feet is her collision box; when i write code that references a collision with the player, it’s checking for a collision with that box. such as… collisions with walls! or furniture! having it just around her feet is what allows me to fake a 3D look with only 2D art, so she can stand/walk in front of walls and objects and it doesn’t look horribly strange.

if her collision box included her head, she would stop moving as soon as the top of her sprite touched the bottom of the wall.. it would look and feel very odd!

but, you can immediately see where this becomes a problem when enemy bullets are checking for a collision with the player. she would get shot in the head and just like, be fine, it would go right through her…

i had the same problem with one of the enemies i’ve implemented, where i wanted to figure out a way to have both the collision box that comes with the sprite and a differently shaped hitbox. i hunted through a lot of forum posts for the best way to do it, but ultimately decided on what i personally thought to be the most “elegant” solution:

an entirely separate invisble object that follows all of the player’s exact movements and handles all of the player’s health and taken damage. (that’s all it does: the player object got to keep all its other code.)

i actually have no idea if this is optimal! but it works, and i got it working with minimal effort. it was a little trickier figuring out how to apply this concept to enemies, but i was able to write a little script so that every enemy i place in a room will spawn its own hitbox object. task complete!! the 3D illusion is secure and i can still maintain expected combat logic.

actual game content!

ah, finally…! after 9 months of development, the first miniboss is here…!!!

like a lot of things in game dev, you never really think about how much goes into a boss fight until you make one… but i had So Much Fun crafting this. im absolutely buzzing with ideas for future fights!

so, this all included: a small arena, pre-fight dialogue that automatically triggers when walking into said arena, barrier objects that appear during the fight so you can’t escape, and associated save/load scripts so that the boss doesn’t respawn if you leave the room and go back in. as for the miniboss herself, she gets her own special health bar with her name attached, and a state machine that cycles through three different attacks until she dies. (i haven’t coded player death yet lol)

some miscellanious stuff!

you may have noticed if you watched the video above, but i’ve changed the aspect ratio from 4:3 to 16:9. i like the nostalgia of a 4:3 but… i think with the way combat is emerging, the experience only benefits from the added screen space. you get a lot more room to see, and thus more time to react.

i’m finally starting on implementing music!! it’s getting atmospheric, babey!!! i’ve also got a little list of sfx that needs doing and i’m stoked to get started on it. video above doesn’t contain any sound because, i have not written a boss theme for her yet, and i didn’t want it to just be the shooting/damage sounds… i promise i am thinking a lot about sounds. and i can’t wait to dive into vcv rack to whip some up!!

i finally set up a github source control. files are secured. every other hobbyist dev should do this way earlier than i did

i’m proud, i did a lot! ^_^ i really want people to be able to playtest the miniboss fight soon—currently i plan on having one available to those interested in a couple of months! i have no idea how hard it actually is and i need some different eyes on it asap, so please let me know if that’s something you would be interested in :]

signing off for now… have a good august, everyone!

[rootvegetableboy]

cm dev log #8 - june 2024

june’s been pretty busy for me, but i've still gotten some very cool things figured out this month :) here’s dev log number 8, hot off the press for y’all! (gosh, it’s already been 2/3rds of a year…)

game control changes:

press f4 for fullscreen!!!! i repeat, we have fullscreen mode!!!! i was really worried that implementing this would be difficult but it was actually super easy.

some camera coding nonsense; basically, setting the groundwork for screenshake & other such effects to be implemented later.

combat changes:

implemented a visual representation of the player’s weapon reload timer! the timer itself existed last month, but i hadn’t put in any real indicator of how long you had left as of the last dev log. now there’s a little bar that appears & fills up to let you know :)

this next one is huge!! enemies now drop items!! AND they have their own unique drop tables!!!! :) really excited about this, it wasn’t too difficult to implement and it makes fighting the little mobs a lot more engaging when there are occasional drops.

speaking of enemy changes, another death animation has now been implemented. this one was pretty fun to animate:

visual changes:

the player character is now visibly disgruntled!!! aka i altered her sprite a bit :) her old sprite was the first thing i drew in the entire game, but now that i’m a bit more comfortabe with pixel art i was able to give her an upgrade.

i know i separated all of these out by different sections, but most of these things are technically visual changes: small beautifying details & such. the biggest Coding Thing was enemy drops, and that didn’t give me too much grief either :) i’ve also finally started on a proper first draft script now that i have a full story outline, but i’m not showing it to you yet!! hands off!!!

that's all for now. i hope you have an excellent july, everyone! see you later <3

[rootvegetableboy]

cm dev log #7 - may 2024

happy pride month! i got a lot done in may, so i’m really excited to show off all the progress i’ve made. let’s take a look!

for logs in the past, i’ve written fairly in-depth paragraphs detailing major changes or new systems, but i’ve actually gotten so much done this month that the idea of writing this log that way is pretty overwhelming. because of that, i’m going to lay it out more bullet point style this time—this looks a little more like the notes i take for myself throughout the month, but greatly consolidated.

combat changes:

lots of combat UI!

enemy HP bars added

player HP bar added to the top left corner of the screen

UI for player’s current weapon/capacity/shots left added underneath player HP bar

red vignette will now flicker on screen when player takes damage for greater visibility

implemented unique enemy attacks, both melee & at-range variations

visual changes:

all bullets now have their own destroy animations

added to level furnishing with additional objects/sprites

animated lamps

added rugs, alternate desk with papers, +5 bookshelf variations

stone floor & stone wall textures added

death animations for enemies implemented

other changes:

select enemies can now bypass certain walls

fixed depth issues with enemies & furnishings

fixed issue where dead enemies could still cause damage to the player

fixed issue where player hp could go above its maximum

more flavor text added

aside from work on the game itself, i’ve also been fleshing out my design document as thoroughly as possible. as of this week i finally have a complete drafted outline of the story, so more and more things are continuing to fall into place!

i want to say i plan on having something playable available this year, but it’s hard to be certain. there’s still quite a lot i need to do to make that happen: a complete in-game menu rework, the other 99% of the audio, a whole lot of enemy creation, finally learning sequences, player death, and lots more… so, i will tell you that i am hoping to release a free playable demo this year, and i will do my very best to try and make that happen! but!! it might not!!!!

also, i’m going to be a little busy with life-things in june, but hopefully i still have some cool things to show you next month :]

that’s it for now—see you in july!

[rootvegetableboy]

cm dev log #6 - april 2024

happy international workers’ day! in april, i did even less than i did in march… so, it's another short log this time.

i’ve been feeling a little burnt out on this project, so i’ve been trying not to needlessly force myself to work on it. i did a couple small character sketches earlier this month:

[photo ID: two sketches. on the left is a humanoid robot drawn in red lineart. on the right is a human woman drawn in blue lineart; she has her hair up, and is wearing shoulder pauldrons and large earrings.]

i also showed a little bit of what i have so far to a friend who visited me a couple weeks ago. actually, i was trying to show them how i haven’t set a maximum to the player’s hp yet by consuming a bunch of beef jerky, but the game crashed on the first jerky consumed. turns out when i added the damage system a few months ago i changed how i was handling hp variables but never changed the respective jerky code… so, the jerky was trying to increase a number that didn’t exist anymore. how embarrassing…

truth be told, i’ve been struggling a lot with the sheer scope of what i want to do. for a little while i was getting good at keeping my head down and only focusing on the task directly in front of me, but now that i have so many systems built up i feel like i’m floundering on what to do next, and overwhelmed at how much i’ve worked on versus how little i feel is actually complete. but i’ve been looking through previous dev logs in preparation for writing this one (i always reference them, even if just for consistent formatting) and i’m starting to feel a little better about this… even if this game is just for me and 2 other people, i think it looks pretty cool. i still want to see it through.

i don’t have that many concrete goals for may. i’d like to start getting some kind of boss fight demo together for further combat refinement, but beyond that i’ll be happy as long as i have multiple things to talk about next month.

can you believe it’s almost summer? see you in june!

[rootvegetableboy]

cm dev log #5 - march 2024

march was mostly a resting month for me, so this dev log is a bit sparser than you may have come to expect. i’ve still got a few things to show off though, simple as they are ^_^

[photo ID: a gif of the player character shooting small orange bullets around a room. the bullets have a short sparking-out animation upon impact. end photo ID.]

to start, i figured out destroy animations. this is a great step forward because now my bullets actually make a little sparky explode upon impact instead of just disappearing… and since i figured out the code for this already, it won’t be too difficult to expand & apply elsewhere, like death animations for enemies. that’s the nice thing about coding: once the code works, i scarcely have to touch it again, and it’s easy to replicate.

actually, it’s kind of funny that i’m saying that, because the next thing i did was rework some amount of previous code for my save/load system.

[photo ID: the in-game menu’s save/load section. it has three available file slots, two of which are in use. end photo ID.]

way back in january i talked a little about building this system; i kind of glossed over the specifics but mentioned i had some issues with integration into the larger in-game menu. this wasn’t intentionally misleading, but i realized recently i’d left a lot unfinished in this regard… i hadn’t actually coded a way for the save file to be labelled by the room the file was created in, (the “Wicker - Neighborhood” in the respective january screenshot was just a placeholder) and i ran into a bunch of unexpected issues when i tried to create multiple save files. one of the funnier ones was that every file’s name would change to reflect the most recent one created, even though the files themselves were still distinct in every other way. it was a fun example of how sometimes what the problem looks like is very different from what the problem actually is: it looked like every save file was getting overwritten by the most recent save, but the only thing that was actually being overwritten was the displayed text.

after i fixed all the issues i could find and the save/load menu was working exactly as intended, i turned to my partner to express great relief at being finished with this particular system! and then halfway through my next sentence i realized that there is currently no way to access save files from the start menu, and you can only access them when you’re already in-game… so, still more work to do actually…

[photo ID: the first screenshot shows the inventory holding only the item “Parchment” with the options “BACK”, “USE”, “LOOK”, and “DISCARD”. “LOOK” is highlighted. the second screenshot shows the same inventory, no options visible after “LOOK” was selected, and there is now a textbox that displays “> It’s a little drawing of a ladybug playing the flute.” end photo ID.]

another change i made to the in-game menu was to the inventory. previously, item descriptions were displayed in small text above the inventory window and were not optional to view. the description was always there (provided you had at least one item) and would change respective to the item currently selected. i realized pretty quickly that this would get hard to read if the menu was opened against a light background… so now, the “LOOK” item option will provide extra info via regular textbox for those who desire it. (i’m planning on displaying the player’s HP in a different way for the same reason). i also think something as small as item descriptions are only really sought out by players who enjoy reading in games, so it’s not something i need displayed at all times. this way of handling the text also lets me write longer, multiple-page descriptions if i so desire :-)

aside from this, i made a few small adjustments to combat. the gameplay is still pretty easy at the moment, but the few adjustments i made will let things ramp up in difficulty nicely once i let the enemies also have bullets.

well, looks like that’s it for march. i hope you have a good april! i’ll see you all on may day ^_^

[rootvegetableboy]

cm dev log #4 - february 2024

happy march! i can’t believe this is already my 4th dev log… that means i’ve been working on this game for one third of a year…

i know in the january log i said i wanted to tackle gameplay, and i guess i did a little of that, but it ended up being mostly an art/asset creation month. towards the 3rd week of february my wrist started to hurt, so i’ve slowed down a little bit since then. thankfully, i still have some cool art to show off!

[start image description: 3 variations on the same bookshelf sprite: one with all empty shelves, one neatly packed with different encyclopedia-like sets, and one with mostly unrelated books tending more towards leaning against one another or being stacked horizontally. end image description.]

[start image description: a very zoomed-out view of a basic environment, cliffs overlooking water. the player character is extremely small in comparison. end image description.]

[start image description: a view of an indoor environment with brick walls, four tables, and several of the previously-described bookshelf assets. end image description.]

the thing about art/asset creation, i’ve noticed, is that it’s generally a bit more of a convoluted process than coding… when i want to code something into the game, it’s more a matter of figuring out how to code it → and then coding it. (and then fixing it if i need…) art is different, though, because a lot of the things i draw end up going through several different iterations before i settle on what i want them to look like. i’m still not entirely sold on some of the basic structures i have in place for myself, but it’s still been really satisfying to slowly start to build up these areas. even just the bookshelves and tables have added a lot of depth & feeling i think ^_^

aside from art, i also made a few minor coding tweaks. i added a little bit to the enemy AI: now enemies will only chase you if you come within a set distance, and if you leave this distance, they will walk slowly back to their spawn point. (basically “running away from and/or avoiding everything you encounter” is now a viable strategy.) the sounds that accompany a character speaking are now a little more fluid re: keeping pace with the text, and i adjusted the depth & drawing code for the player character so her weapons are drawn over other objects (such as tables and bookshelves) as opposed to underneath.

i’ve been having a bit of trouble classifying february as a ”productive month” in my mind, but i know how important it is to keep slowly chipping away at long-term projects like this, so i’m happy at least i have stuff to share with you all! in march i want to really hone in on building some more tools for myself: my close friend stevie suggested whipping up something with Twine when i expressed having difficulty keeping track of characters/plot threads, which is such a genius idea. it’s not something that is easily “shown off” but is definitely sorely needed for me at this point in development, if for no other reason than just keeping me sane...

as always, i really appreciate everyone who has been keeping up with the process! it's always super encouraging to receive feedback and hear people ask about how it's all going. i will see you all in april... springtime approaches :)