Grumpy Gamer

I have a (paid) art job opening for my side project. I’m not going to say much about the game other than what I’m looking for in an artist. Think of it as a puzzle.

I’m looking for a great 2D pixel tile artist. You need to have experience building tiles sheets for a tile-based game, I would prefer it if you’ve worked on a released game, but if haven’t and your art is just a hobby and you’re really good, that’s OK.

I’m looking for someone that can create a very distinct art style and can help set the look and feel for the game. I’d like someone that can do more than just create art based on a task list, but rather someone that can act like a mini-art director.

Qualifications:

• You need to be able to spend 20+ hours a week working on the project for a couple of months.
• This is a PAID position, so you have to have the ability to work.
• Must have prior experience building tile sheets and tile maps (the more the better).
• Understand how to organize a tile sheet and create interconnecting reusable tiles.
• Need to be up on the “state of the art” in terms of pixel tile based games.
• Must love pixel art.

If you’re interested, please contact me and include the following:

1. Your name.
2. Link to your portfolio/website/etc. It MUST include your tile work, but should also include other work to show you’re a great artist beyond just tile work.
3. A list of games you’ve worked on.
4. Why you think you’d be awesome for this job.

I can’t emphasize this enough… I want to create a very unique and interesting look for the game that goes beyond the stock 8-bit tile work out there now (not that it isn’t great, just not what I’m looking for). Your portfolio doesn’t have to include that new look, but it should show me you can help create it.

One last note, please don’t post the above details in the comments, use the contact link.

This is a good video.

But, for the record… I hate the term onboarding. I’m not against the concept. I just hate the word.

This is a great four-part series about Roguelikes from the GOLDEN KRONE HOTEL website.

Part 1: Burden of Knowledge
Part 2: Identification
Part 3: Terrible Controls
Part 4: Bog Standard Dungeons

Roguelikes are one of my guilty pleasures, although I don’t play a lot of different ones and I can safely say I’ve never heard of most of the games mentioned in this series (my first experience with Rogue was on a UNIX machine when I started at Lucasfilm).

One of my many side projects is working on a roguelike. I’ve never made one before, so it’s a fun exercise. Technically it’s not a roguelike (no random dungeons, no permadeath (not like it’s traditionally used)), but it feels like one. I guess they call these roguelites. Or maybe it’s the other way around?

It’s been fun to try and deconstruct the genera and see what is important and what is just legacy cruft. But much like deconstructing adventure games to “just the fun parts”, it’s easy to boil them down to something that isn’t an adventure game anymore. Not that that’s bad, but don’t call them adventure game (or roguelikes) anymore. Maybe you’ve stumbled onto something new.

Grumpy Gamer announces that Alex Jones has been banned from this site.

A Freddi Fish image mashup I thought I’d never see

Last month (maybe longer) I wrote about one of the top three production mistakes we made in Thimbleweed Park. Today like like to talk about the second one.

Just to be clear, these are production mistakes, not design or programming mistakes (although sometimes the line is blurry).

The first one was not integrating FMOD into my engine. As I wrote, it was a Penny Wise and Pound Foolish decision.

The one I’d like to talk about today is Continuous Integration, but first a little primer.

“What the hell is this witchcraft you call continuous integration!” I can hear you saying and don’t feel bad. I wonder how many indie game devs use it. My guess is a lot fewer than should (a quick poll of friends is standing at 0%).

Continuous Integration (or, CI, as the pro’s call it) is when a separate and often dedication machine is continuously building (compiling) your game whenever you check in code.

This is good for two reasons:

1. If you check in code that won’t compile on one of the platforms (I don’t care how good or careful you are, this will happen to you) the CI machine will let you (and the rest of the team) know. It helps ensure that the game can build at all times. If you can run a battery of unit tests, the CI machine will often do this as well.

2. Since the CI machine is a standalone machine, it’s dev environment is a known quantity, so installing some goofy tool or new version of python on your personal dev machine isn’t going to introduce oddities in the build.

3. Bonus point. You always have a build ready to put into test and then distributed to Steam, Xbox, etc.

I’ve used CI on previous projects and it can be a pain to set up, but it’s a time saver from then on. It’s indispensable and you should always use it!

Did we use CI on Thimbleweed Park? Of course not! That’s why I’m writing this blog entry.

When the Thimbleweed Park engine got to the point where it could actually be used and David was brought on, I thought about CI. Previously I had used a dedicated machine in the office with Jenkins installed. I only ever needed to make a Windows build (or builds that used VS) so it was one machine with a few different flavors of builds.

For Thimbleweed Park I need to make Windows, Xbox, Mac, Android, IOS (and later Switch and PS4) and Linux builds. Without some fancy hoop jumping, this was going to require three machines.

My mind fuzzed over and I said “later”.

Throughout the project I kept revisiting CI, and being overloaded with work, I kept saying “later”. As the end of the project rolled around it seemed pointless since the project was almost over. Of course, I was wrong and we continued doing updates and ports for a year.

At the time I was looking at CI, cloud-based services like AppVeyor and TravisCI either didn’t exist or never showed up on Google searches. Today you can just use these two cloud services to build Windows (or anything that needs VS), Mac (Mac and iOS) and Linux. Android can be built on any of them. If you don’t mind waiting 10 or 15 minutes for the build to start, both services are very reasonable (and free for open source projects).

In the end, I built the Windows, Mac and Linux builds on my local machine. I had the entire process scripted, so it was running a single bash script and all the Mac versions were built. I ran a Windows VM on my Mac and would launch it was run a .bat file to built all the Windows flavors. Same with Linux, boot the VM and do the builds.

Thimbleweed Park was a tad complex because there were two parts that had to be rebuilt (the engine and the game), and while intertwined, they were separate and it was common for one to be rebuilt and the other not. It was also complicated by all the game build tools being on the Mac, so you couldn’t actually build the game code on Windows. This didn’t matter since the game code/files were 100% cross-platform. I could build them on the Mac and they would run on Windows, PS4, Switch, etc.

It makes CI a little more complex because your CI might be building the engine but something had to merge it all together (another CI process). The game code needs to be built first (and you don’t need to rebuild it for each platform), then the engine process could grab it and merge it, or a third process could combine it all, but everyone would have to know when each piece was done (if a new build was needed). My point isn’t that it’s impossible, just that it’s hard and a problem that I ultimately (and unfortunately) didn’t need to solve.

Back when the project started, if I had known about AppVeyor and TravisCI, I would have set them up and ultimately saved me a lot of time and stress.

Next time for sure!!!

No, really, next time for sure.

…the cosmos is littered with time travelers adrift between the stars.

I’m quite enjoying Octopath Traveler. I’m not a big fan of other Square games and generally don’t enjoy the JRPG format, but for some reason, this game has stuck with me for hours and hours. I’ve just hit the first boss I can’t defeat (to avoid any embarrassment, I’m not saying which one).

I’ve beat my head against this boss for quite a while and I’m about ready to just quit. As a game designer, it’s an interesting experience. Players clearly have this problem with the games I design and it makes me wonder if it’s a good experience.

I’ve resited hint systems in my adventure games for almost ever and had to be beaten down by the rest of the TWP team to add one, but in retrospect, it was the right decision and should have been in there from day one.

The point of a game is to enjoy it and if a little hint, nudge or one-shot can often help someone do that. The danger for a designer is that the hint system becomes a crutch and it becomes how people play the game and they have a shitty experience because they spent most of there time looking up (or calling for) hints.

I severely run the risk of not picking up Octopath again. I’d love a way to circumvent bosses, even if it took me a little grinding to do so. Maybe there is and I just haven’t found it yet.

Hint systems are good, but they do need a little friction.

All I want to do is pass a #define on the command line to msbuild. Why does MS make this so hard? Why not have a simple /DFOOBAR option? This kind of pointless complexity drives me crazy. I’m sure some nerd at MS was super pleased with their wicked powerful solution… fine… but provide a simple solution for the thing 90% of people want to do.

Sorry, I just needed to vent.

P.S. Apparently you can do the following kludge:

set CL=/DFOOBAR

Before you call msbuild.

Yeah, but does it run GraphicsBASIC