Show older

I've added projectiles that the player can shoot. I was originally just going to make a simple maze game but I got carried away after getting a hand with SFML.

I've added exit tiles. It just ends the game because I don't have it programmed to have multiple levels yet.

So it turns out that I can't have multiple levels without major reconstruction of the code. C# spoiled me with it's lack of import/include statements and Python was dynamically typed which meant I didn't have to declare the object type right away, so now I have to deal with avoiding recursive includes.

Ugh!

Got a second level. I learned that if you just include a blank class definition of a dependency in the header file and then include the actual header of the dependency in the source file, then you can avoid recursive includes.

gamedev 

Now there are three levels, all of which are derivatives of each other.

gamedev 

Got a camera to work. It's manual but if I plan to actually finish this game, I would probably have it scroll based on the player's position and movement. You can also see that there are tiles outside of the camera bounds. Those were left in by mistake.

SFML has a built in camera called sf::View. It's pretty weird. I'm used to having a 2D camera origin being at the top-left corner just like sprites, but the origin is actually in the center which is something I need to get used to.

I mean, it's kind of justified because it also has support for rotation and zooming (things I have never used). I'm just used to implementing my own camera system and just drawing sprites based off of their positions and the camera offsets, but that not an option here because sprites are automatically drawn based on their position (no manually drawing here).

gamedev 

Now the camera vertically scrolls with the player's movement. Horizontal camera movement hasn't been implemented yet.

gamedev 

Horizontal scrolling with player movement has now been implemented.

gamedev 

Created my first enemy. All it does is move down. It's hard-coded into the level (it's not in the level file). The octorok sprite is just a placeholder (if I even plan on releasing this).

gamedev 

The enemy now has random movement, but no collision detection.

gamedev 

You can now kill the enemy. Deleting the object is so much different than what I'm used to. In C#, I could remove the object from its respective list within one of its method because it would be garbage collected. In C++ I have to delete the object outside of the object itself.

gamedev 

The player now knocks back when colliding with the enemy. And I've encountered a bug during this recording.

gamedev 

Player can now take damage. Game Over screen is just a white screen right now.

Oh yeah, I've also fixed the bug, but I didn't feature that in this recording.

gamedev 

Enemy now has a death "animation" (single frame).

gamedev 

I tried to test out increasing the health of the enemy, but I'm stuck with this annoying bug where the enemy dies in one hit no matter how much health I give him. I even tried giving him 1000000 hp and the result is still the same.

gamedev 

I've fixed the bug, but now the enemy is left on the death animation if it dies. As you can see, the enemy is knocked back based on the direction it is facing, when it should be based on the velocity of the projectile (result of copying and pasting code from player's knockback).

There is also a new problem in that I keep on getting segmentation faults. I don't know where they are coming from.

gamedev 

Fixed the segmentation fault and the death bug. Segmentation fault happened because there was an index that I forgot to set to 0. I'm used to C# where integers had the default value of 0 when declared as opposed to random values as it is in C++.

gamedev 

I've added keys, which can be used to open lockdowns that haven't been implemented yet.

gamedev 

I've added locked doors. Probably should create a better tile for them, but all tiles are placeholders (assuming I publish this game; this is merely me just getting used to object management in C++) as most sprites are from Zelda I and BS Zelda.

gamedev 

I've added a heart that increments HP by one.

gamedev 

Enemies are no longer hard coded into the map. They are now loaded from the map file. Ignore the enemy placement. It moved before I could take the screenshot. (My screenshot utility is probably delayed)

The first two numbers defined the level width and height.

The block of numbers are the tiles.

Everything after that are objects. They are listed by object type and then the x and y coordinates.

gamedev 

Player position is now defined in the map file. The second line of numbers determines the player's x and y position (in tiles).

gamedev 

Door now has a sound effect.

I've also realized that the way I'm storing assets in RAM is inefficient (I've actually knew that since the beginning but I haven't bothered to fixed it). I need to implement an asset manager class and have each object store pointers to said assets. Right now, each object stores entire textures/sounds when they should be storing pointers instead.

gamedev 

Added a second enemy class. This one takes two hits to kill, while the first one now only takes one hit to kill.

gamedev 

Added an actual health bar. I probably should move it before the key counter because it looks weird the way it is right now.

gamedev 

Rearranged the UI. The health bar is now on the left. Looks much more natural.

gamedev 

Create a life capsule, which increases your max hp and a new enemy that takes 3 hits to kill.

gamedev 

Replaced the Zelda tileset with my own. I even added an extra wall tile for forward-facing walls.

gamedev 

Replaced the wood tiles with charcoal colored ones. Wood didn't look good mixed with the metal-like walls.

I've also changed the tile format for the levels. 1st digit is the tile type, while the 2nd digit is the tile that appears on screen. It broke compatibility with my level files, obviously, but it's worth it because now the tile maps are readable.

Also, the first level you see in this video was just some sample output generated from a procedural generated cave algorithm on the roguebasin wiki. I just converted it to my level format. It kind of looks without a cave tileset though.

roguebasin.com/index.php/Rando

gamedev 

*It kind of looks weird without a cave tileset though.

gamedev 

Here is the tilemap for the cave-like level.

Follow

gamedev 

I've changed the way how doors and keys work. Now you have colored locks and you need that colored key in order to unlock it (much like in Doom).

· · Web · 3 · 0 · 1

gamedev 

Enemies can now drop keys if set to do so.

I was also experimenting with tile colors. I thought a light blue/cyan would be an interesting color for the tiles. I was expecting a bathroom-like aesthetic but it ended up looking like an ice cave instead.

gamedev 

Fixed the camera to make it center more on the player. It's not perfect, but it is a vast improvement.

gamedev 

Added chests where you can open to get keys. I need to add a sound and a "get item" animation for it though.

gamedev 

Created a small "animation" for when you open up the chest.

gamedev 

Enemy randomly drops hearts (25% chance) if there is no drop item set to it.

Getting footage of an enemy dropping took forever due to the low percentage.

gamedev 

Fuck it. I'm shelving the dungeon crawler project, for now. I've underestimated the switch from C# to C++. The code is already a mess and I wasn't really planning on anything. This was always merely a practice game that I didn't intend to release but I got carried away.

I'm going to work on another shmup but this time it will be a horizontal one.

re: gamedev 

@xianc78 that's a very chip's challenge look

re: gamedev 

@coolboymew It was supposed to be just a simple maze game. I recently switched to C++ and SFML so I'm trying to get used to how they handle objects and everything, but I ended up getting carried away after getting used to the quirks, and now it's some dungeon crawling, top-down shooter.

I've never played Chip's Challenge. That game was before my time. I've seen footage of it. Looks like some sort of roguelike.

re: gamedev 

@xianc78 it's actually a puzzle game. The first one is free on Steam last I've seen. I wonder what a chip challenge like with action elements could be like

re: gamedev 

@coolboymew After seeing this video, I think I played a clone of this game. I had the PC version of Spongebob: Battle For The Bikini Bottom as a kid. It was nothing like the console versions and instead just a collection of minigames. One of the minigames involved navigating through the Chum Bucket in levels like this. It wasn't tile based though.

invidious.poast.org/watch?v=mB

re: gamedev 

@xianc78 you should try it out, it's a pretty decent puzzler that somehow managed to maintain a community for decades
@xianc78 @coolboymew
>maze game
>in fact any game
>not using Jonathan Blow 'Jai Programming Language'
smh
@xianc78 Of course, the ableist gamedev chooses to color-code everything and make it inaccessible to colorblind people.

-Cove
@xianc78 You are proving our point. You just defended your ableism by using an ableist slur.

-Cove
Sign in to participate in the conversation
Game Liberty Mastodon

Mainly gaming/nerd instance for people who value free speech. Everyone is welcome.