4 Hugues Ross - Blog
Hugues Ross

9/27/20

The Big FOSS Game Tech Battle Royale

Lately, I've been in the mood to get back into gamedev. It has been a while since I sat down and made a game for real, so this feels like an ideal moment to look at the landscape with fresh eyes. Over the last 5-10 years, a lot of open-source game engines and frameworks have popped up and grown up alongside the indie scene. I have a little framework of my own, but I want to find the tech that I'm most comfortable with.

To that end, I've got a fun exercise to try. I call it:

The Big FOSS Game Tech Battle Royale


The concept is quite simple: Every week, I'll spend 6 days trying out a new set of tech and building a little breakout clone. I'll write about my experience, then at the end I'll pick whatever I enjoyed the most for my future projects. Also, though it goes without saying--I'll also post the code and assets for each attempt.

I think breakout is a nice 'test game' because it's very simple on a mechanical level but incorporates a decent number of core game development concepts. The simple format is also ripe for expansion--which will be good for testing tech with a fast iteration speed.

 

I've picked out 8 'contestants' for this exercise.

  1. DFGame -- DFGame is a lightweight C framework that I've worked on from time to time... It's not terribly impressive, but works well and benefits a lot from being familiar territory.
  2. MonoGame -- I've used XNA to build games in the past, and I work in C# professionally as well. For that reason, I think this framework is absolutely worth trying.
  3. Godot -- Godot is an engine that I've heard a lot about, but never actually used. While I'm a little skeptical of the hype it's gathered, dismissing it offhand would be silly. This exercise will be a good opportunity to give it a fair shake.
  4. HaxeFlixel -- From my understanding, Haxe is the phoenix that rose from the corpse of Adobe Flash... I never really enjoyed Flash development proper, but I've never tried Flixel before and Haxe has been used several high-profile indie titles.
  5. LÖVE -- Good old LÖVE, I used this engine for a few months back when this blog first started. I discarded it for silly reasons back when I was first learning C++, but the engine is still going strong to this day and I want to give it a second look.
  6. SFML -- Another briefly-used piece of tech, I used SFML for exactly one school project. I have a couple of friends who recommended it while I was building this list, so here it is!
  7. Raylib -- I've never used this one, but at a glance it looks like "DFGame, if it was fleshed-out and actively supported". I don't know if it's any good, but it's clearly worth trying out if it can save me from reinventing the wheel.
  8. Pygame -- I'd forgotten about Pygame until I asked around and someone mentioned it. It seems a bit dated, but how it fares remains to be seen.


What a list! If I knock out one test a week, it should be enough to last me a couple of months. It should also give me plenty to write in the meantime as well. I'm also open to suggestions, if you know a little open-source gem feel free to suggest it in the comments.

8/30/20

I'm Back

This blog has been on hiatus for about a year... I considered making a post explaining why, but I get the impression that no-one reads this blog. This is mostly my fault, of course! I've never been one for branding and advertisement, so it stands to reason that this place would be pretty empty.

I'm thinking of continuing where I left off, and trying to get more eyes on my work. But first, let's talk about where I was and what I was up to.

 

The Blocky Elephant in the Room

If you have been following this blog, you can probably guess that Minetest was the source of my disappearance. As I became more familiar with the project, I got the impression that I would need to invest a lot of time into helping it along. As a result, instead of leaving it as a side thing I dropped my other projects and invested my time and effort into it.

I don't regret doing this, but I'm also not sure how productive it was. RPG16 got a lot of love from the community, something I'm quite proud of! On the other hand, attempts at game development were bogged down by annoyances and engine limitations. Looking at the engine itself, it became quickly apparent that a lot of important things were broken or missing. So, I dropped that project and started working on improving the engine, telling myself "It will take a while, but once the engine is good I'll be able to make something cool".

There were some problems with this line of thinking:

  1. There's a ton of work to be done, and not enough people doing it
  2. The pace of development is greatly slowed by the combination of strict standards and a small core team
  3. The standards can't be loosened because there's a fairly large community expecting backwards compatible and bug-free updates
  4. Joining the core team would effectively cut my own development time

This creates a cyclical problem, resolving the reasons that development is slow would slow development. Worse still, this was taking me even farther away from my original goal. Just resolving blockers was turning into a bit of a nightmare.

In the end, I decided to cut my losses and leave. I suspect that I could invest 5-10 years into Minetest work without seeing any "return", and I just can't justify that kind of thing. I don't hold anything against the developers and community though, and I sincerely hope they can prove me wrong. I'd like to come back to a better engine someday.

At the very least, my time in the Minetest community taught me one important thing: I have the skills to make work that appeals to others. What I'm really missing is visibility.


How About Art?

On a happier note, my art practice has been progressing very well! This year I've been able to accomplish one of my original dreams and branch into landscape art:

I'm still learning a lot, but seeing the strides I've made over time is very exciting. I intend to continue for the foreseeable future, with weekly art streams on Twitch and pieces posted on my Twitter. Follow me in either of these places if you'd like to see my work as I make it.

 

The New Plan

I think that mostly wraps up the last year or so. Now that I have more time to myself, I'd like to continue my old projects and revitalize this blog a little. One of the first things I plan to do is rebuild everything under a new blogging platform. The nature of what I make has shifted over time, and I need something that can better serve my needs.

In addition to programming projects, I'd like to be able to post art pieces, photos, development resources, etc. on this site to give people more reasons to visit it. And finally, I need to start sharing and advertising my work more. There's no point in rebuilding a site like this if there's no community to enjoy it.

9/2/19

Art Project - RPG16

Ever since it came out in high school, I've really loved Minecraft. Despite never mentioning it here, I've sunk hundreds of hours into it over the years. And that's why I'm worried about the future.

Some years ago, Microsoft bought Minecraft. They haven't done anything crazy like the doomsayers claimed at the time, but they have gradually de-emphasized the original Java version in favor of new editions and spin-offs.To my knowledge, those new editions
  1. Don't run on Linux
  2. Aren't moddable
  3. Have been more aggressively monetized with MTX and DLC
None of this stops me from enjoying Minecraft, but it does make me wonder if someday I'll be locked out of the game entirely.

To try and avoid that problem before it happens, I've been looking for alternatives. As far as I can tell, the only really active open-source block builder is a little game called... Minetest.

Nothing in this world is easy though, and Minetest has 2 little problems...
Warning: Strong opinions ahead

It looks bad

As you might expect of a volunteer-run effort, most of the content made for Minetest is made by non-artists. When you start a new game, you're likely to be met with a scene like this:

Not only are most of these textures worse than what Minecraft offers (and it's not exactly known for amazing graphics), there's like 3 different art styles in this screenshot alone!

Like Minecraft, some of this pain can be alleviated with texture packs. Or it could, but for 3 problems:
  1. There are very few texture packs
  2. 90% of the texture packs look as bad or worse (and indeed, many of them are just the default textures run through a filter)
  3. The good-looking texture packs are extremely limited in scope, leading to nasty stylistic clashes with the unaltered content.
Well, at least the game's great fun! Right?

It also plays bad

Whoops.

Now, to be fair this is highly dependent on certain parameters. Minetest itself exists more as a sort of 'platform' that games can be built off of rather than a game itself, and there are a handful of interesting and promising games to play. However, the community almost universally considers the default game to be unenjoyable, and even the coolest games still feel incomplete, unpolished, and just generally not as fun as I'd like...

All of this leaves me in a pickle. I don't want to stick to Minecraft, but I can't see Minetest as a viable long-term way to scratch my creative survival itch. But then, a thought occurred to me: What stops me from fixing this myself?

Introducing: RPG16

Because it seemed easier, I decided to tackle problem 1 first. Consider the following:
My goal with the RPG16 texture pack was to make a big complete texture pack with a fun 16bit RPG look.

Whatever you think of the aesthetic, the visual consistency is much improved. Personally, I'm much happier with a game that looks like this, and I believe that my texture pack makes Minetest visually competitive with its rivals.

I released the pack towards the end of July. And so far, onlookers seem to agree with me! The community have given my textures a fair bit of praise, and I've been busy updating the pack with more content.

If you play Minetest and you're interested in trying this out, you can find it here.
Just for fun, here are a few more screenshots:
A fork in a river

A wasteland of cracked dirt and burnt trees, with some mushrooms on the side (Work in Progress)

Unique armor sets (Work in Progress)





About that gameplay...

This fixes the first of my complaints. However, I still don't feel at home with any of Minetest's current offerings. Ultimately, I'm going to try making a fun and polished game that matches RPG16 in quality.

It's going to be more of a long-term back-burner project, and most of my other stuff will be taking priority. Still, I fully intend to try making more fun content for myself and others to enjoy.

8/13/19

Back to the Maze - 4 - Hey, it Works!

Hello again!

I wasn't expecting it to go so smoothly, but I got AMAZE's rewrite to a point where it mostly works. At the very least, every level is fully playable at this point so I feel happy enough calling Stage 2 of my plan a success (and in just a month and a half, if you ignore how long it took me to sit down and write this)

But how did I do it? Let's talk strategy:

1 - Data

My original goal for this stage of the project was to get the games final data files loading and running in the new engine, but I very quickly abandoned that idea in favor of loading the source files instead.

The main benefit of this change was greatly simplifying the asset loading process. Instead of handling custom compressed binary files, I just had to deal with simple text and xml. Many of these files were similar to existing formats in DFGame, so loading them was pretty easy.

2 - The Critical Path

I thought a lot about how to approach the problem of recreating the game, but in the end I decided to simply play through it. By visiting every level, I could implement just the parts that were necessary to make the game function and ignore the rest, which was another good speed boost.

3 - Writing Bad Code

I think terrible code is underrated. No-one wants it in their codebase and it has a very high maintenance cost, but ignoring quality allows for lightning-fast initial development speeds. Even at work, I usually start by hacking together the "naive solution" to quickly get a prototype in place that I can then redesign to better fit with existing systems.

I applied the same concept here. Since I'm already planning months of cleanup, polish, and refactoring, I just wrote the cheapest possible recreation of the original I could. I'll be paying that debt back soon, but I'll be doing it with the luxury of a working copy.

Like a finely-aged...steak

Since I had to play through the game for testing, I can also give a verdict on the original content! I hadn't touched this thing in forever, so I came in totally fresh. And let me tell you, it sucks!

I remembered that the game was lacking in polish and some challenges were too tight, but but the latter was much worse than expected. Looking back, I think there are two even bigger problems:
  1. Minimal Checkpointing - AMAZE is sort of a hybrid action/puzzle game, but there are no in-level checkpoints. Replaying an action sequence isn't too bad, but following the same steps to complete a puzzle after dying feels pretty bad. (The fact that resetting a level when stuck costs a life is also bad)
    Additionally, running out of lives is very easy and a game over can push the player back pretty far.
  2. Blindness - A lot of puzzles suffer from not showing the player enough in-game. This becomes especially obvious in some later areas, especially with ice puzzles. There are multiple places where the player has to run into areas full of deathtraps, completely blind!
Naturally, the result is a really un-fun game. If I want to make the new game a success, I need to keep these points in mind.

Planning My Approach

As you may remember, the next two stages are about refactoring the new code into something solid, and building tools to produce the new data. Before I can do that, I need a better idea of what to do with this game.

With that in mind, I'm taking a break from the project for a little while. Now that I have it running with newer libraries I can worry a little less about compatibility (though I don't plan to stop long enough for that to be an issue), so I'm going to spend some time on a few other projects and come back to this with some fresh ideas later.

My next post be about one of those projects, which is already released!
Stay tuned.

6/18/19

Back to AMAZE - 3 - Lookin' Good!

In just under a week, I've managed to produce a mockup for the remake. To keep things simple, I decided to redraw the screenshot on AMAZE's game page. I think the results speak for themselves:


Honestly, I'm really happy about how this one turned out. The environment feels like it came straight out of my nostalgia. But that's enough gushing, let's examine some of the changes.

What's New?

If you compare this mockup to the original, the first thing that you might notice is the difference in size. The new one is actually much smaller than the old one. This might seem odd, considering the difference in detail, but in reality the mockup just uses space more efficiently. The original was 640×480, but for the new one I decided on 480×270. This was for two reasons:
  1. It scales perfectly to 1080p (×4)
  2. It gives a similar aspect ratio to the original's viewing area, but with 24px tiles instead of 32px
32 was a really common number to see back when I started making games with GameMaker 6.1. However, I've since come to appreciate 24×24 as a tile resolution because it strikes the perfect balance of time investment and detail. 16 tends to be difficult to work with, and I often feel limited by it. On the other hand, 32 often feels like overkill, and the extra effort feels like a waste of time. 24 gives just enough space to add good detail without creating much more work.

Next up is the UI. The original game has this big tacky bar at the top of the screen with information on it. Most of the information on the bar is fluff, and I'm not convinced that your average player would even recognize what some of the bars meant.

By contrast, the new UI is simpler. The Nintendo-esque counters on the top-left are pretty clear, and the only other element is the active tool. You'll notice that I opted for numbers as opposed to the bar in the original. That bar's ticks didn't always line up with the actual number of uses, which is kind of an insane design decision in retrospect. This time, I wanted it to be perfectly clear.

The last big changes are, of course, the collectible and enemy sprites.
I mostly swapped those out to better fit the rest of the game. It seemed odd for a robot to be dodging fireballs in a cave for gold and jewels, and by changing the sprites I felt that I could get everything to fit a common theme.

The Next Stage

I think I'm happy enough with this mockup to move on. As I explained last time, my next goal is to get the old data working in a new codebase. That means putting this mockup away for the time being, but with any luck it'll be back soon!

Next Time: Good Old-Fashioned Programming Updates