Graveyard Quest Devlog #2

So its been a hot minute, almost a year, since I’ve worked on anything game related. Work, life and everything in between has been hijacking my work time. Recently I’ve mostly been on a writing binge with short stories that came about from writing out dnd scenarios for my pals getting back into it, but that’s for another post.

I have worked a bit on graveyard quest as well as another game (I’m a bit hard pressed to call it a game since it was basically an exercise in making a turn-grid based movement system). Here’s what I’ve put into the game ever since my last post.

Basic killable enemy is now implemented.

I’ve upgraded from my previous posts enemy template of a simple red angry face to something that can be hurt, have heath and be killed. They still have no brains and just randomly waltz any direction they can but it’s a start. They also get knocked back when struck into the opposite direction of where they are facing. I get a funny feeling that this logic is going to bite me in the butt later when dealing with more complicated enemies.

I’m thinking that right now, in the pretty early phases of prototyping instead of making more complicated variations of enemies using this same template I should make different kinds of basic enemies first that compliment other enemy types. Not sure yet.

Room, doors, no transitions yet.

I’ve also added basic room transitions with a door object that is named and teleport coordinates are changed in the room editor for easy management. If a door teleports the player at a completely random spot then I can just edit that specific instance in that room instead of having to hard code in x and y coordinates like in the days of yore (I wasn’t and am still not the most clever of coders alright, don’t be too harsh lol).

I’m thinking of adding a simple fade to black transition or something of the like so that it’s not so abrupt a change when moving to another room. And if that’s the case I’m wondering if I’ll need to design rooms in a way that the player won’t get immediately attacked when entering a room before they can asses the situation and deal with threats or create a small timer that disables damage to the player when coming into a new room.

Another thing I’m not sure on how to deal with is that the rooms don’t retain the kind of information on whether the enemy has been killed yet or not. For example in the first Zelda, if the player had killed an enemy, leaves the room and comes back, for the most part that enemy is still gone (I think for like 3 more room transitions). Object permanence I believe is called? I do like the idea that the enemies are still there, it gives it a bit of a retro vibe to it, but I’m probably just being lazy.

Getting Hurt is flashy now

Lastly, I’ve added a lil hurt sprite to help me with debugging hurt stuff on the players side. I probably just need to start adding placeholder sprites for all directions of the player, but unless I make enemies or puzzles that depend on the direction the player is facing I don’t think I really need to until I start making the first draft sprites for the game.

Things to do next;

Although I’m not working feverishly on this, I’ve been putting in about 30 minutes of work here and there when I have the time available usually during work lunches and such. Next things I want to add into the game:

  • Wall traps (the arrow shooting kind)
  • Floor traps (the spike from underneath kind)
  • Health drops
  • Key, locked door mechanics.

Really trying not to add any more mechanics to the game and get stuck in making features, I think what I have now is more than enough to make a short zelda-style game with my own flair, in the beginning this was just supposed to be an exercise in sprite-making but… I got sidetracked. I will do my darndest to finish this.

Leave a Reply

Your email address will not be published. Required fields are marked *