DFGame - The road to 1.0

I haven't written much about DFGame in a while. At the end of last year, I gave the project two small paragraphs but didn't get into any specifics. In this post, I'll be getting you back up to speed on the project's status and where things will go from here.

The plan

When I started going back over DFGame, there were a few outstanding problems:

The build system

DFGame was started before I learned about Meson. As a result, the library was being compiled with a makefile. In order to make the project fall in line with others (and hopefully organize it better) I needed to ditch the makefiles and switch over to Meson.

Changing the way that your code compiles can be a bit drastic, especially if the two systems aren't very compatible. In order to simplify things, I decided to try and build each module of the framework as I got to it.

The modules

DFGame was started not long after I started breaking my code up into modules. For the uninitiated, modules are pieces of the codebase that are separated from the rest, and typically compile separately. This allows programmers to use their code in multiple projects, or have multiple applications in their project that share the same code in the backend. As you can imagine, this is a good thing.

The problem with DFGame was that I didn't make enough modules. I broke my code up into five parts, based on whether it was editor or game code and frontend vs backend (plus one for common code). The result is that the common module was a gigantic mess, with 46 code files spanning subjects from audio to rendering to error logging, and everything in-between.

At the tail-end of last year, I decided to try and separate things further. Now, I have 7 modules: Application (game frontend), Audio, Core (logging, memory, etc.), Editor, Graphics, Math, and Resource (asset loading/management). This keeps the different aspects of my framework separated in a more logical fashion, and makes it easier for me to find what I'm looking for.

Inexperience

I don't claim to be an expert, especially not at C. I spend a lot of time programming and practicing, but I still learn new things every day. As a result, there are many small lessons that I've learned since I started working on DFGame. As my knowledge of programming has improved, I've found better ways to do the things that I've already done, so the temptation to rewrite things follows.

With that said, I'm trying to preserve as much as possible. I'm keenly aware (from experience, of course) that rewrites can seriously slow things down, and I want to try and get things sorted out at a decent pace. To that end, I'm going over each file individually to try and improve what I have without scrapping it. I hope that this methodical approach will save some time over a simple redo.

Where are we now?

I've finished going through the core, math, and application modules, and now I'm working on the graphics module. Unfortunately, that means that I don't have much to show for my work yet. I do have this stylish hot-pink triangle though:

Thrilling, I know!
Now that things are showing up on-screen, I expect to have more to show in the coming weeks.

Coming up

Now that I've caught you up to speed, you might be wondering what I'm planning on in the long term. I'm not the best at keeping to my plans, but I do have a goal that I'm aiming for. In about 4 months, it will have been 3 years since I last participated in a Game Jam (aside from 7DRL, of course). That makes me sad, as I really enjoy doing them. Looking at the games page on my site, it seems like when I started DFEngine and AMAZE I mostly much stopped doing game jams altogether.

This year, I want to turn that around. To accomplish this, I'm setting myself a deadline now: I will have DFGame ready for an initial release by August, and I'll compete in Ludum Dare around that time. From my experience, the Ludum Dare game jam usually falls smack dab in the middle of something important and college-related, either the beginning of a semester, finals week, or the move back home. In other words, it wasn't really convenient for me to compete back in college. Now that I don't have a weird seasonal schedule to work around, it seems like a good way to get back into the rhythm of Game Jams. I think that the timeframe I have between then and now is pretty reasonable, and I expect to be finished well before my deadline. Any leftover time that I have can be spent trying things out and building tools.

Conclusion

So that's it! I'm hard at work fixing up DFGame for a release later this year, and hopefully once the dust settles I'll be able to make games again like I used to. I played around with DFGame last fall, and even though I didn't post the results were promising. Whether those results will be replicated with future projects has yet to be seen.

No tutorial this week

This week's tutorial has been delayed to next week. This is mostly because I fell ill recently, and wasn't really in the best shape to do anything serious like preparing tutorial content until a few days ago. I did get a few mindless tasks done on my website, but besides that I didn't accomplish much.

Not to worry, though! I'll have a new post up later this week.

Site Update: Updated software page and more

Last week, I mentioned that I would start posting content on non-tutorial weeks. Now, it's time to make good on that.

I was stuck home sick this week, so I took the opportunity to make some improvements to my site. Some of the changes are obvious, but others are much more subtle so let's take a closer look. Generally, the changes can be broken up into three categories:

Accessibility Improvements

When building my site, I didn't really put too much thought into it beyond how it looked. On a whim, I decided to toss my site's HTML into the W3C Markup Validator, and found its structure lacking.

The two main issues were the misuse of headings and missing alt text on images. In a few places, such as the notes in my tutorials, I was using <h1> tags. <h#> tags have a number that indicates their "level" in the document, like so:

Heading

Heading

Heading

...and so on. The numbers in these tags are used by screen readers and other applications, so it's good practice to ensure that the headings reflect the structure of the page. In my case the stray <h1> tags were breaking the structure, so I changed/removed the offending tags.

Alt text on images is the text that is displayed if the image doesn't load or you're viewing a page in a program that doesn't handle images, the alt text is displayed. Since the images on my site had no alt text, they would effectively be missing if my site were put through a screen reader. Fixing this was pretty simple, since it was just a matter of going through and adding some simple descriptions where applicable.

For the average visitor, these changes are essentially invisible. However, if I ever get any visits from someone who's visually impaired then these changes will hopefully make their life a little bit easier.

Updated Software Page

This change was a long time coming. Ever since I gave the Games Page a fresh coat of paint back in September, I've been meaning to do the same for the Software Page. I've replaced the old design with the one currently used for the Games Page and I've also added some more entries, for a new count of 5.

Right now, there isn't too much content in each entry. I'm still trying to decide what I want to put there, and I also need to get some screenshots/logos for my software. In the meantime, it's still a step up from how things looked before:

The software page (before)

The software page (after)

Mobile-Friendly Styling

Another thing that I'd been meaning to do for a while was making the site responsive. For the uninitiated, responsive websites are sites that can adapt their design to different screen sizes and orientations. Obviously, this is quite important for any site that receives mobile traffic.

Now, almost all of the content on the site is responsive (there are still one or two exceptions).

Along with the above changes, I've also tried to make the site's text a little more readable by increasing the font size and line spacing. It's a small change, but from my experience it makes reading the content easier on the eyes.

If you have any feedback regarding the changes, feel free to email me or leave a comment below.

Let's Make a Roguelike - Generation

In a shocking turn of events, I actually finished this week's tutorial segment last night! This means that I was done a full day early, and I've opted to post the new segment this morning before I head to work.

The trick this time was starting early. I finished the followup last weekend, then did half of the work on Saturday and the rest on Sunday. I'm pretty sure that if I keep to this formula, then I should be able to keep up with the schedule without causing myself too much stress.

As for the contents, I'm continuing my policy of "give the reader some fun stuff early on" by sharing a couple simple random generation algorithms. In my old plan for the tutorial, this probably wouldn't have happened until part 6 or 7 (we're on part 4), so I think this was a good move. I'm also trying to get through things quickly because (as I said before) I'm still not 100% happy with this tutorial and would like to get it out of the way so that I can focus on making better-planned tutorials in the future.

Lastly, I wanted to say that I'm going to try and revive the old one post a week policy from my college days. I've actually been working pretty hard on a couple of interesting projects lately, so this will give me an opportunity to share them on non-tutorial weeks. I'm painfully aware of the fact that the tutorial is the only thing I've written about this year and it's nearly March.

Anyways, you can click here to read the latest part.

Let's Make a Roguelike: Fashionably Late

Had you worried, didn't I?

I almost had this weeks segment done last night, but I was quite tired and decided to put it off. That was apparently a good decision, since I put several hours into it today before wrapping up! This was mostly poor time management on my part, but I'm happy that the delay was small this time.

As for the content, I'm trying to accelerate the early bits a bit more than in my previous iterations. Even for a long-running series, it's important to keep the readers engaged, and the shape drawing from last time didn't seem up to snuff. I'm taking a bit of a write once, refactor later approach this time: I present the technique in a fairly simple and "bad" way first, then show how the implementation can be refined and improved later. This allows me to frontload much of the exciting stuff, while still providing some basic design lessons down the line. We'll see how that goes.

This series has really been a bit of an interesting experiment for me. There are so many things wrong with my approach to writing these that I almost want to start fresh again, but for the sake of actually getting things done I'm resisting that urge. I think this series is helping me learn a lot about tutorials though, and future seasons will benefit from those lessons.

Here's the link to the new part.