The ahoge does seem to “balance out” the head shape a bit. Makes it look a bit less orb-like.
I did a few modifications to the eyes for your character. I liked the orbinesss.
i see what you’re getting at (with the scrunched up eye)
i should note that i lowered the entire face segment down a pixel after that to give more room for the hair and i think it works
i am happy enough with this. i’ll make some generic enemy and put it in and hope for the best
i have been procrastinating on all my projects so i revisited this for something simple to code
some work to be done but the new tile renderer is integrated. really need to replace the old enemy sprite. I cleaned up the rules a little bit to make it easier to specify. There’s some oddness around the edges of the map that I will clear up.
explanation of how I’m doing this!
first, the blob tilesets
i had to add a ‘surrounded on all sides’ tile to the corner because whoops.
this gets fed into my asset preprocessor like so
<sheet output="../Assets/sheets/tiles" premultiply="true" scaleby="2"> <file file="Tileset-Wang-Dirt-Pit.png" w="24" h="24" border="copystar1"> <tile name="floor" x="144" y="0" /> <tile name="pit" x="96" y="96" /> <blobmap prefix="blob_floorpit_" x="0" y="0" /> </file> <file file="Tileset-Wang-Walls-Dirt.png" w="24" h="24" border="copystar1"> <tile name="wall" x="96" y="96" /> <blobmap prefix="blob_wallfloor_" x="0" y="0" /> </file> </sheet>
which generates a reference file and the following texture:
tiles are scaled to double-size and have a one pixel border added to the edges by extending the edge tile one pixel in each direction. this prevents obnoxious texture seams from rounding errors at higher resolutions
then we have a rules definition that indicates how we’re to draw the scene. it looks like this:
<tileAlias name="floor" tile="FLOOR1,FLOOR2" /> <tileAlias name="pit" tile="PIT,WATER" /> <rule tile="floor"> <draw layer="bg" name="floor" /> </rule> <one tile="pit"> <!-- use wang blob tiles for transition to non-pit tiles --> <blob layer="bg" prefix="blob_floorpit_" out="!pit" /> <!-- otherwise fall through. <one> rule means only the first rule is chosen! --> <draw layer="bg" name="pit" /> </one> <one tile="WALL"> <blob layer="bg" prefix="blob_wallfloor_" out="!WALL" /> <draw layer="bg" name="wall" /> </one>
there are also rules for checkerboard patterns, random pickers, etc. will consider adding more in the future as it’s easy to do.
all code pertaining to rules-based rendering comes out to about 520 lines. pretty small!
- fix sprite shadows
- probably better walls? taller?
- replace that enemy sprite dang
- sprite shadows are fixed, they stay at ground level instead of moving with the character, possibly need to be recentered though
- enemy sprite is replaced, not sure how i feel about it yet, the green glow is supposed to indicate how you can attack it, but maybe i should make it more subtle. also i kind of don’t like how it looks.
- those walls gotta go.
- definitely redesigning protagonist
ain’t it adorable
starting to rip apart the map editor code but have been derailed by literally everything
edit: they just wanna give a hug
writing down notes on possible enemy/object types to draw or at least prototype
too much! but going to prototype a bunch of these and start actually piecing game bits together.
I know I haven’t had much ocncrete to post in like a year but I appreciate y’all for continuing to follow
Is… is that a tar analogue on the right?
I’m sorry, I don’t mean to nitpick, I just didn’t know that you were also history’s greatest monster >_>
(I do like the skele-snake)
i haven’t decided if I’ll actually go with it or not but yeah tar-like substance. i was rolling with either slime blobs or ectoplasm blob + ghostlings to pop out of it.
I never really found the growth mechanic in drod all that interesting aside from being used for timers or whatnot, which can be done in other ways.
snake-likes won’t be like drod’s at all. if anything they’ll be like escape goat 2’s, which:
- move in a straight line until blocked
- when blocked, pick the direction that brings them towards the player
- when there’s nowhere for the head to go, just die out.
still mocking up ideas/concepts though, just give me time to get through them
hello! i have been tinkering with design stuff and I thought I’d dump an update on y’all here. It’s slow but I think it’s starting to come together.
#1: protagonist design
previous versions were more washed out in color, and I found that this didn’t stand out against the background as much as I had hoped it would, so she’s a much more saturated blonde now.
Also kind of fixed the arm so it’s a little more aligned with the sword. Which is not really a pose that makes sense but it’s more aesthetically pleasing.
also experimenting with faceless versions. kind of don’t like them as much. Not really touched up much.
That will be all the game will need. I’m going to put up a shitty version of all of this. Comes out to:
I should probably just do json instead of xml, but I don’t feel like rewriting stuff.
(yes I wanted to support jp text)
#3: user puzzles
So when I put this up properly, I’m going to let people share puzzles via URL. You can make a puzzle in one of the editor slots, and then click an export feature to get a URL with all the map’s data.
I have had to make some concessions for this, since I don’t want the URL to exceed 1000 characters, and that puts a pretty strict limit on what I can do, since I’ll need at least two bytes per tile and that adds up.
This may mean slightly smaller puzzles.
Still kind of waffling on diagonal movement. Need to make a whole lot of puzzles before I feel comfortable making a decision here I think, which means I need to get the editor back up and running properly. Soon.
Happy with prototypes of the other new objects, though. Think that it’ll be a nice unique take on DROD-style mechanics.
Main issue I have is that enemy movement is completely uninteresting without it.
Joke answer: Just switch to hexagons.
Wondering if instead of a stage select I should just do it Stephen’s Sausage Roll style where everything is sort of integrated into one giant map and you ‘activate’ puzzles at set locations. Maybe long term, not for the first of the new version.
I know I’ve been slow but juggling way too many things lately and it’s been stressing me out too much to want to stress myself out more with dev on this. Other things have been higher priority.
But I’m happy with how it’s coming along, so maybe next year will be when it’s all there.
jail time for naughty dungeoneers
nobody’s gonna tell me blob tiles aren’t cool as heck
edit: so, editor should be done this weekend. and by done i mean ‘usable by humans, slightly rough, can save/load’
that means it’s time to start asset production in earnest, because the only programming bits left are more entities (easy to add!) and UI stuff. (stage select, dialogue, main menu, etc)
editor is basically done. persistent load/save works, can make stages. the UI is extremely barebones and I would like it to be a bit more better than it is, but maybe later down the road.
so here’s what i’m gonna do.
with code basically done aside from menus and stuff, i’m going to focus on asset production here and go back to coding the wizardry game. you remember that, right? i sort of do.
and that means i’ll be drawing stuff.
i am highly considering streaming this on a regular timeframe, possibly weekly so that stuff Gets Done on this. what you guys say?
I usually shy away from non-pixelart dev streams, but I’m guessing with where you’re at you won’t be too code heavy, so I’d pop in for a stream or two.
Bug of the Day:
I had an issue where, when attempting to perform an action and failing, for example when trying to move into a wall where you can’t move into, a phantom garbage sword object would be left behind and would remain until an actual Undo was performed.
So let’s talk about how the update cycle works!
I use a Statically Allocated Linked List for my game object data. That is, there’s a pool of list nodes, one for each object in the scene, and this data is shared among several different lists.
There are three lists: Object, Redo, and New. The latter two are only used within the update loop.
For each phase of the update process (eg Player Phase, Enemy Phase, etc), it passes through all objects in the scene. If the action successfully resolves, for example an enemy moving towards the player, it is moved to the New list. Any newly created objects are put into the New list. If it fails to resolve, it puts this into the Redo list.
At the end of each pass, it adds the Redo list to the Object list. This is separate so as to prevent infinite loops. If the Redo list is 0 or does not shrink in size, the phase ends and the new list is appended to the object list.
Okay, so, the bug.
When a player action fails to resolve, it aborts the update process and runs a silent Undo(), then tells the UI that the action failed. It had failed to append the New list correctly, so any objects that were in there just stayed there until the next Object phase. This is a different bug, which I fixed, but didn’t cause the loss of information.
So it tried to undo the deletion of the previous frame’s sword.
Which was still currently sitting in the New list.
And it tried to append it to the end of the New list.
Creating an object that was linked to itself, in an island, in an infinite loop.
Basics II is kicking my ass