Pleck's Mart

Category: coding jabber

  • story and art and code, oh my

    This game has become something of an obsession. Or, as the folks over in the meme-posting land of LinkedIn would tell you, a follow-your-passion moment worthy of some stock photography of me running through a field with my arms flung into the air.

    Seriously, in this few weeks of downtime between leaving my part time job and starting back up some professional upgrading and curricular activities—and still, given that the weather is in deep-winter mode—I have little else to occupy my time besides consuming books and Netflix or making something cool.  So the video game design project has won.

    All that is to say that I’m made some serious progress.

    I am nearing the home stretch of Space Carrot, which was my design phase set on building out the equivalent of a game board.  Yeah, there is still more to do as the game design progresses, but this phase was all about building the world in which the game takes place, and in addition to previous updates I’ve made on this phase in the last few days I have added a lot more stuff.

    I think the biggest of these is the furthering of my story system. Tweaks, again, will continue, but the core of it is in place.  The story-proper is a collection of ordered text events that appear on the screen moving the “plot” of the game along. When a room is first entered, when an area is first accessed, when anything of interest happens that could benefit from explanation, this all triggers a bit of the story to be loaded into the game and displayed on the screen. The game, as I have alluded to in other bits of writing, started as a story that I decided would make a good game, so there is a bunch of lore and narrative and characters that are all part of playing it.

    Another big behind the scenes piece is the database system that is coming closer to a solid initial implementation. Behind every good game is a good database, after all. Databases in games store more than just player information and scores, but are sort of the malleable memory of the game itself. I can set all the pieces up as a starting point in the code and have it all initialize when a player first starts the game, but from there the whole point is the player moving, changing, unlocking, and advancing the game itself. Every time something happens the game can try to keep track of this and save it at some point, or—as I am doing—it can basically save as it goes. The advantage of the first method is that someone can reload and go back. That is by design not an option in a rogue-like because the point isn’t to save and progress, but to play over and over again trying different approaches, so a point-in-time save file makes no sense for that. Instead, the state of the single play-through is pushed to the database frequently unlocking and changing the state of the game so that when the player “loses” the game goes back to an almost fresh state—but certain aspects stick and are unlocked ever after and for the next play. A tool. A room. Et cetera.  The foundations of that are now in place as I creep closer to the end of Space Carrot phase.

    And along with these two big bits of work I have not only done some bug clean up but also some key refactoring of the code as I (a) learn better approaches to things because I’m learning the language better and (b) encounter decisions that impede progress because of how I tackled it the first time. Not only does this mean simpler algorithms and code-reusability, but also building little functions that are like little single purpose tools to transform some data or extract a bit of something and give it to something else. 

    Oh, and I’ve leaned into public constants. As I build it’s often easier to hard code numbers into things for the sake of speed and debugging, but as things grow and complexify, one realizes that changing over, say, a number used eleven times to define a spawn point to a constant makes it easier to update when the map shifts ten pixels to the right because of a design change. I spent an afternoon just replacing hard-coded numbers.

    In the end, what this all means is that I am probably one more subversion away from declaring the end of Space Carrot phase and moving into the next one.  More on that later. So stay tuned.

    The obsession is palpable.  Maybe, those LinkedIn people are right and when you lay awake at night puzzling over a code problem and are not laying there dreading the morning, but rather considering creeping downstairs at 3am to try it out—maybe that is a passion project. Grab onto that, huh?

  • after more seriously cold coding, progress abounds

    I hunkered. It helped that it’s been twenty-five degrees below zero outside and I can’t do much besides sit in the warm house and look out through the frosty windows. No dog walks. No running adventures. No casual outdoor excursions. Instead, I’ve spent two full days coding.

    I wrote just a couple days ago about my intention to work on this current phase of development (Space Carrot) and barely forty-eight hours later I’m posting again to say that I’m moving my efforts to a new sub-sub-version. I updated the milestone log with the results of 0.2.1 and I’m moving on to 0.2.2 as of my next coding session.

    What goes into writing a game like this?

    I’m not an expert, I’ll remind you. I’m winging this and hoping something comes out of it.   I’ve been working on some game story lore, fleshing out the mapping system on (digital) paper (ie sketching out things on my tablet) and sitting down to think about the mechanics of creating a game space. 

    Sketching out version one of the storeroom.
    Sketching out version one of the store.

    After all, the whole point of Space Carrot (I realize that some people might read that as the name of the game and not just a development phase) is to create a navigable world for the game-proper to exist in.

    First, I worked through the nuances of creating a collision detection system that doesn’t weigh down the processor checking everything constantly. Now you can’t walk through walls. And since I have now forced every movement to happen inside the boundary of virtual walls, my player sprite can navigate around without falling out into the void. Testing will continue on this, but so far it works.

    Second, I had to figure out the strangenes of door-to-door inter-room navigation. This, also a foundational aspect of the game, seems simple at first but in reality it’s a kind of interplay of a player “colliding” with door, waiting for an action to be triggered, and then figuring out what door she collided with is (specifically) and where it leads. Since this whole thing will exist as a series of  virtual rooms, any given door maps to a corresponding door on a different room map, all of it encoded into a few lines of data and “match” statements in the little door collision detection function. In other words, a door collision is detected and if that happens a trigger action can be accepted and validated, and if that happens the player’s location can be updated, and if that happens the code goes uh-oh, I’m displaying the wrong room because the player isn’t here anymore and then the code despawns wrong room and then spawns the new room where the player is now located and also standing at the cooresponding door she just walked through.  And all that happens in a fraction of a second so it seems to the player (maybe you) that your little dude just walked through a door into a new room. Sketch that out in a math equation, huh?

    Finally, I wanted to add a bit of explanatory text to the scene. Specifically,  this comes in the form of a little corner notice room label, when a new room was entered (it’s going to get confusing otherwise, believe me) and any other little notices that might help the player poke around the game.  This was relatively the most simple part, but I did need to figure out Bevy’s new (0.15) Text system, which has not been updated in almost every 3rd party tutorial and code sample. Every explanation of how to use this leaned into the TextBundle constructor which has been deprecated in the latest version. Good thing this whole langauge is starting to make more sense to me with each new function I create.

    So. That’s that. Two solid days in front of Visual Studio and a compiler—and countless times typing the run command and debugging my buggy code until I incrementally added all this stuff and it seems to work.

    But then, this is just a few more basic building blocks of a much bigger plan.

  • the obligatory “Hello world!”

    As of late 2024 I’ve been incrementally teaching myself how to do this Rust Language coding thing and it has somehow started to emerge as a game. My first love is and will always be words, tho, so here begins many, many words on the topic of building a game from scratch.

    So.

    Thing is, as of this week my efforts have come full circle.

    Kinda.

    An early attempt to build a game tick time loop was a factor of trying to create a series of nested loops that managed random things in a database. It would count off the seconds and if sufficient time had passed it would tell the database to +1 to the age of a game object —the game is about running a little [redacted] and [redacted] exists [redacted] but age consistently across all [redacted] blah blah—I’ll explain it more as we go, later. Needless to say I was leaning pretty heavily into the database design as an active tool to manage all my game variables all the time, including during the current screen gameplay.

    That was silly.

    So I started learning about this game engine called Bevy.

    Bevy handles all sorts of things. Or, essentially, it wraps all the regular pieces you would use—should use—for a game into objects that are then managed by the game engine. This means it can spawn a player and a board and objects and they can exist as virtual game pieces, but also as things that can display on the screen or whatever. It’s all neat and tidy.

    I wrote a bunch of code to use a bunch of array data, essentially an x and y grid of tiles that maps out a player area in the game. I call these simply, obviously rooms. A room can be something like the back store room where you keep and get new products. Or there are storefront rooms which are basically all the same across dimensions but may look slightly different or have different texture files, that type of thing. But the core here is that as much as a player can move around inside each room, there will be doors that take them to other rooms.

    Hense, the full circle.

    Aaaaand—now I am back to the database.

    I started encoding a bunch of database functions just this morning that are updated at various times during play. When a room is exited, I am thinking, the database will slurp up all the room data, store the state of all the objects in that room and essentially create a kind of mapped overlay of the base map for each room, but at coordinates there may be products or tools or other things that despawn out of the active play but can be respawned when the player re-enters that particular play area.

    I lean heavily into database driven design online and I am very comfortable thinking about things that way, but in many ways it this is because databases are virtually a necessity for web based stuff if only because you need preserve a lot of data between pages and across sessions. Each page is essentially a little app that builds itself dynamically from the data in the database and doesn’t rely on a system loading the entirety of the site into memory and keeping track of everything across every session then passing all of it from page to page. Now that would be silly,

    I figure, too, that this approach may really work to my advantage in the roguelite game plan that I am contemplating. Certain data can always be persisistent across runs of the game and just doesn’t get purged from the databse on initiation.

    I sat down here to write something about the abstractions of learning this language but now that my ideas are actually starting to take shape and form I’m noticing that I can write in more than abstractions. And that’s a good thing, right? Maybe silly. Maybe more.