The last element of the 7DRL engine’s “must haves” – a win condition for the player. With that out of the way, let’s talk about localization, combat, and making the game look a little less like crap. Win Condition Determining win conditions without using code is a challenge, and it’s a challenge I don’t yet know how to solve. It’s similar to the behaviors attached to weapons – I can define behaviors in the Python code and then select them in the YAML, but I can’t define them entirely in the YAML without writing some code in the YAML that knows about the game state somehow. ...

Working through my checklist of “must have” features for the game. I have a checklist of the bare minimum features I need to implement in the game engine before I can even think of implementing a real combat system. They are: The game must begin- The game must have a win condition- The game must let you lose- The game must let you defeat enemies- The game must let you be defeated by enemies Yesterday’s update covered the introduction to the game, and how I wrote a dispatcher to bring the player from the introduction and into the main game. At that time, the introduction was written entirely in code, but that was a problem. ...

Yesterday I mentioned a few things that were required to be part of any roguelike game engine. Today, I add two of them – an introduction, and a way for the player to be defeated. To recap: Here are the things that I felt needed to be addressed in order to even begin thinking about the actual game I’ll be building in a week and a half: The game must begin- The game must have a win condition- The game must let you lose- The game must let you defeat enemies- The game must let you be defeated by enemies When I start programming the game, I am going to start with these five things. The player will probably be able to win in just a minute or two, or perhaps be defeated. Once I have these five things done – which really should happen in the first day or two – then I can start adding content between the beginning of the game and the end of the game, while always being able to draw a line from start to end, such that, at any point in time, I could say the game was fully playable. ...

This weekend, I added weapons, monsters only move when you move, and I added flags to tell if items were identified, cursed, wielded or worn. Each flag multiplies the complexity of the code by at least three times, but it is flags like these that are central to the Roguelike experience. How many flags I choose to implement has a direct correlation to how the game plays… and whether I can finish it at all. ...

If someone were to quiz me on how a game engine is different from a game, I’d think about it a bit, and then probably explain that a game is run by the game engine, but no part of the game is actually in the game engine. I’m enforcing that by moving the game (as opposed to the game engine) into YAML, which stands for YAML ain’t markup language. The game is data. The game engine runs that data. ...

NPCs don’t want to hit their allies while they are attacking you with ranged attacks. Some objects in the room can block them as well – and using the objects in the room to deal with larger swarms of enemies will be an important strategy in the actual game. Today we go over the line of sight algorithm. As before, you can always test the latest state of the game engine by following this link to Trinket IO. I’d rather work with something that has the latest version of Pygame, or at least let me use a larger screen, but ya work with the tools ya have. ...

Path finding is central to all rogue-likes. If an enemy can’t find you, they can’t fight you… and that wouldn’t be any fun. Tonight, I go over Dijkstra’s famous pathfinding algorithm, the differences between that and A*, and how I implemented them in the engine. Once again, you can play the engine as it currently exists by clicking this link and then clicking the “Run” button near the top of the window. New for today: pressing the F5 button on the keyboard creates a new, random map. I don’t pretend this is a game – the game has to wait for 7DRL to officially begin. ...

I didn’t make a lot of visible progress today, but I decided it was time to take a step back and do a vital step in any programming project – refactoring. As usual, you can “play” the current test engine by following this link to Trinket and then pressing the “Run” button along the top of the window. Trinket is a “good enough” solution for now. I’d like to move to a native browser implementation, but it ticks the checkbox that says “can run in browser”, so I move on to issues I haven’t yet addressed. (For one thing, Trinket doesn’t use the latest version of Pygame, so sometimes I find myself using features not yet available there). ...

Tonight, I made it so my sprites had a walking animation, decided to show all four walls of the room, and found out some things about Trinket I didn’t know before. Also, what is a roguelike, anyway? And why not use something like Unity that solves most of the problems I am having? I am building a rogue-like engine to use in the upcoming “7DRL” game jam. You can see my current progress by heading to Trinket via this link and pressing the “Run” button up along the top. ...

One of the items on my 7DRL checklist for this year is to have the game run in a browser. The last time I did this, I used Pygame and could only share it with people by handing them the source and hoping they happened to have Python and Pygame installed. As part of the Rogue-like game engine development, I’m looking into ways to get the game playable in the browser, while still being able to use Pygame to develop it. Today, I’m looking at Trinket. ...