- 4 Nov 2023
As a kid, I wanted to learn how to program to make computer games. That was the original goal, anyways. I’ve always felt there is a weird sort of magic being able to type structured sentences into a text file, ram it through a compiler (sometimes with fun, cryptic looking incantations typed into the terminal), and seeing something come to life on the other end.
Programming has always been an on again/off again sort of hobby. I think it’s more the act of making something from nothing that draws me to it then actually making something. A few years ago (actually closer to a decade, somehow) I found the Complete Roguelike Tutorial using Python and libtcod. I didn’t know Python when I started the tutorial, but the end result of that project was amazing - I had a mostly complete game. I tweaked and customized, modified and played around with that project for a while. Eventually hit a wall, probably due to my lack of knowledge with Python.
[Read more]
- 18 Sep 2018
One of the big goals for Barbarian and one of the coolest things on my to do list was to add animations into the game. How exciting is it to see an arrow flying toward your character, a firebolt explode in the face of an undead horde, blood splatter flying from the wounds inflicted by the mighty barbarian decorating the walls of the dungeon?
Obviously, the excitement added by all these visual effects is well worth the time spent adding them in. I started thinking about how I wanted to incorporate animations during the Tutorial Tuesday Challenge, and started jotting implementation ideas down in my notebook almost two months ago. For the life of me I could not find a good writeup on creating procedural explosions on a 2d grid, and could not wrap my head around how to make them look decent. I shared my struggles on the r/roguelikedev sharing Saturday post, and another dev (u/darkgnostic) gave me some fantastic ideas about reusing my line-of-sight code.
[Read more]
- 26 Aug 2018
Over the course of the 2018 r/roguelikedev Tutorial Tuesday Challenge I decided to invest some time learning some fundamental programming concepts that I probably should have learned years ago. The fun (and challenging) part of being a hobby programmer is that most of my learning comes from books, and then random tutorials on the internet. Somewhere in the course of my “education” I never learned about basic data structures and how they can be used.
Around week three of the challenge I decided to implement a scheduling system for Barbarian - which led me to learn about creating lists and priority queues. STL has std::priority_queue, but like many STL classes never seems to want to play nicely with my code. Again, likely a byproduct of me learning C++ from a book and probably not the fault of STL.
This is my very first attempt at writing a tutorial - expect some errors and feel free to comment with any corrections.
[Read more]
- 9 Aug 2018
I didn’t do a lot of coding over the last week, but I did finish the challenge! Had a bit of a scare after finishing part 12, I found a horrible lurking bug in the program that caused a LOT of little errors and I wasn’t sure (at first) how to track it down. Basically, shortly after finishing adding in some cool randomization functions I found that some entities weren’t being copied correctly, or saved correctly. Turns out, the C++ Rule of 3/5/0 is actually a rule and not just a suggestion/guideline.
This project was the first time I attempted to use smart pointers and write more “correct” C++ code, and apparently even when using smart pointers to allocate memory you should write at least a copy constructor and copy assignment function. I’m still not sure what I would put in a custom destructor if all the memory that’s allocated is done via smart pointers, and that might be something I need to clean up now the challenge is over.
[Read more]
- 31 Jul 2018
Oh man, this has been a super exciting and productive week - this project is starting to feel like a real game! Started off last week a bit behind schedule, having just finished part 8. After my rant last week about my source code files getting too long, I decided to spend a bit of time going back over my core classes and cleaning up the code. I also split Engine into multiple files - which ended up making a lot of things a lot easier. Heck, recompiling a huge source file each time I make a minor change was tedious, and the time savings alone was worth splitting the files. Each of the Engine main functions now has it’s own file, and then each of those main functions calls separate routines depending on what GameState the game is in. Each of those separate, state specific functions has its own file.
[Read more]
- 24 Jul 2018
Another very productive week for this project! Although I was unable to finish last weeks goals of getting Parts 8 and 9 completed by today, I still feel pretty darn good about what I did accomplish. Besides, Parts 10, 11, and 12 are all fairly simple - heck the code is already in place, just needs to actually be used!
After finishing Part 7 last week I decided to try and fix/change a few things that have been bothering me. The square, 12x12 font, looked great for the map tiles but it was really ugly for text. I figured my alternatives were to either use two fonts (like a 6x12 for text and a 12x12 for map), or just use a different font altogether. All my years playing games in a terminal window pushed me to the second option - if it’s good enough for the best roguelikes, it’s good enough for me!
[Read more]
- 18 Jul 2018
The past week has been equal parts frustration and excitement with this project. I ran into a pretty common design problem: entity components need to know about the rest of the game. Well, since each entity is just a collection of components it shouldn’t be difficult to pass a pointer to the game engine. Then, the components would have a pointer to the entity that “owns” it. Simple and clean… or so I thought. This didn’t work, at all. Individual entities could access the engine just fine, but the components just could not access anything about their owner. Even trying to print the address of the owner caused the game to segfault and crash. GDB was no help, and I tried MANY things to get this to work.
I realized that I was bashing my head against this problem, and totally stumped, so I decided to work on something else. I changed the Engine’s entity list from a std::vector<Entity> to a wsl::DLList<Entity> (from the fancy list class I created last week).
[Read more]
- 10 Jul 2018
I originally planned for this week’s blog post to cover my adaptation of part 5 of the Python RL tutorial - but after finishing part 5 in a matter of minutes I realized there wouldn’t be much to write here! Part 5 is basically making new entities and getting the collision logic in place before combat is added in part 6. However, before adding combat I thought it would be beneficial to start thinking about game time - it’s far more fun when some enemies are a lot quicker than the player, forcing the player to devise strategies for survival.
Naturally, there’s a few articles on roguebasin - one of which I’ve read many times over the years, and never understood a word of it. Pascal is a goofy, blunt looking language and really makes you appreciate how nice programming languages read these days. Or, maybe I’m just dense and don’t get it.
[Read more]
- 2 Jul 2018
I decided to split the third week into two separate posts so that I wouldn’t ramble on as long as last week. Over the past week I continued fighting the BSP dungeon generator I had attempted to write the week prior, and gave up again. I’ll probably revisit the dungeon generator later, and will definitely write something about whatever I end up doing. The artificial deadlines imposed by following along with the rest of r/roguelikedev really helps motivate me to call something “good enough” and move on… Heck, I think I could be satisfied just tinkering with dungeon generators and never moving on to actually making this a playable game!
I did some reading on writing clean C++ by google, which prompted me to take another look at the code I’ve already written. The big thing I gleaned from the Google article was to avoid “in-lining” things in headers, and put most of the code in the implementation.
[Read more]
- 25 Jun 2018
So this week’s goal is to finish part 2 and part 3 of the tutorial - I worked ahead because I was excited to get this project going, which worked out well since shortly after finishing part 2 I switched to SDL from SFML and it gave me some time to work on this blog.
The Switch to SDL So the game logic is completely divorced from the rendering system - I don’t want to be tied into using a set framework if I want to change later, and I know for a fact from previous projects this will make save files much easier to generate. I briefly described last week that the game has a virtual console that is written to, and is read/translated into graphics to be displayed by SFML. Well, the console is a grid of say, 80x50 (960px x 600px). Each cell in the grid has a glyph that needs to be translated and rendered.
[Read more]
- 20 Jun 2018
Last year r/roguelikedev did a really cool thing with a weekly post where everyone followed along with a tutorial, shared ideas and problems, and motivated each other to actually finish a project. Well they’re doing it again this year, and with the announcement last week I decided to take a look at the new and improved, Python3 version of the tutorial.
For those not familiar with this famous tutorial - each part covers a small chunk of building a roguelike using simple language and easy to follow code. In just 13 parts you have a working roguelike to build off of and branch out from. A really, really cool idea. I did the old Python2 version a couple years back, and it blew my mind. After completing the last part I finally had made a game, and was pretty proud of the results. I didn’t know Python when I started, and hadn’t done any coding before beginning, but was able to follow along and even add my own stuff along the way.
[Read more]
- 16 Oct 2017
Man, I really don’t do a lot of work on this blog - maybe because I am not a web programmer but I can see when this blog does not look very good.
Well, I officially gave up on web design. Yep! Turns out, I should probably leave that to the professionals. Oh, and I also decided to heck with Jekyll. It was cool, and worked well - but searching for a premade Jekyll theme was a chore. Not to mention getting all the silly ruby nonsense to work. Even tried playing around with Ruby and seeing what all the fuss was about. No thanks.
Stumbled upon Hu(go) - another static blog generator. Well, Hu(go) is blazingly fast, and has a ton of cool features that you don’t have to even try hard to get to work. Not to mention the themes are easily searched through, easily switched, easily customized/expanded, and look darn good.
[Read more]
- 7 Jan 2017
Over the past couple of weeks I’ve been working on simplifying the code for my roguelike project - heavily inspired by one of my favorite books on my shelf, Game Programming Patterns.
I’ve seriously read this book cover to cover, multiple times - and every time find a new use for one of the ‘patterns’ in it. I just discovered that the author’s blog has a bunch of good reads on it as well. One of the biggest problems I’ve had with the roguelike project was a simple way to issue commands (which should have been a clue) from the player to the character, and from the computer AI to the enemies.
The first chapter in the book, and this blog post had the answer - the ‘Command’ pattern. I have no idea how I didn’t think of this sooner - basically, all the actions that an actor (player or enemy) can take are issued as ‘commands’.
[Read more]
- 22 Dec 2016
So, every time I get the urge to write a blog post about whatever random bit of code I’m writing - I look at the blog and think: “Hm, this is kinda ugly.” Then, I have to rewrite it until I’m mostly satisfied with how it looks.
Recently, I’ve been working on writing a nice little interface for handling menus and other parts of the UI for my roguelike project. Unfortunately, like the layout of this blog, I can’t seem to find a satisfactory ‘look and feel’ - I think I’ve got a good start though.
While procrastinating working on that, I’ve spent a lot of time thinking about the map, and my ECS system. At the risk of prematurely optimizing code, it seems like an awful waste of space to make every tile an entity. Most of a tiles properties are simple boolean flags anyways, so why not make tiles just a bitflag and glyph to represent them?
[Read more]
- 15 Jul 2016
Continuing in my never-ending project to make a “simple” roguelike in C++, I decided to tackle something I have never before tried: artificial intelligence. My first rough idea was to implement some sort of component-type system, and build the AI up like I built up entities. This turned out to be far too complicated, and even getting a monster to move randomly was a chore. Obviously, this wasn’t going to work.
After browsing /r/roguelikedev and RogueBasin I came across a few articles on “need driven AI” - an absurdly cool concept, and so (seemingly) simple to implement I wasn’t sure how I didn’t stumble across this earlier. Basically, creatures in the game assign a value to things they know about (treasure, the player, exits, other monsters they are friendly with, other monsters they are terrified of, etc. etc.) and make an ‘informed’ decision about where to move next. A monster could desire killing the player over treasure, and would “decide” to move towards the player instead of a closer pile of gold.
[Read more]