Recently, I discussed some mistakes I made working on my game. I still don’t have a Hacker News account, because I still wish to waste less time on the Internet. Fortunately, I have very good friends who post sometimes my blog posts there. The friend who submitted this post, MJD, is looking for a job. He’s brilliant and empathetic and you should hire him.
Anyway, here are some responses to the Hacker News comments:
I arbitrarily picked the number six for the number of mistakes, but I’ve actually made way more than that. For instance, when I got my veneer, what I should have done is asked my dad how to use it. He’s a real woodworker, and undoubtedly the advice he would have given would have matched that of mauvehaus on HN: a complicated gluing and clamping procedure for a tricky material.
I also probably could have gotten away without gluing the veneer at all, but I was worried about it wiggling around while trying to position things on it.
Someone asked if I would release High Mountain Abbey anywhere other than Steam. Definitely – it’s the right thing to do, it’s not much more hassle, and maybe it’ll get me some more sales. I’ve created an entry on Itch. Note that the price may change – I have very little idea how to price games.
gmueckl made two suggestions:
His first was “wild walls”, a film production technique where walls can be removed. I’ve consider this, but:
This screws up the lighting much more than holes. I think film has really bright lights, which means any light leakage through a wild wall would be minimal. But getting that kind of lighting into a tiny diorama is tricky.
If my dioramas were really precise, there wouldn’t be gaps between the wild wall and the rest of the set. But they’re not. It’s particularly tricky to avoid gaps in the cave walls, which are not at all flat.
I actually do this where it’s feasible. For instance, in one room, the floor is “wild” – the rest of the walls lift up. Rocks hide the seam. In another, the ceiling lifts off. And in a third, the side wall is wild, and I hide the edges with some columns.
User gmueckl’s second suggestion was to use a SCM other than git.
If I were collaborating with other devs using this SCM, I would worry
about what was best for collaboration, or maybe, most space- and
bandwidth-efficient. But I’m honestly mostly using a SCM because it’s
how I’m used to building software. I almost never need to look at
history. And in the unlikely even that my primary dev machine dies,
and I need to clone a few hundred gigs to restore it, I can afford to
wait a few hours or even a day – I’ll just spend the time working on
some other part of the game.
The big advantage of git is that I know it really, really well –
I’ve even contributed a little code to git myself.
Someone else suggested using git-lfs. This would, in theory, help –
I wouldn’t need to download all of the raw assets if all I need is the
game portion. But I can already do that with partial
clones. Github has some
better pricing for LFS storage, but (a) I prefer to avoid Github
because I think monocultures are bad for the web, and (b) most of my
files aren’t actually large – it’s just that there’s a large number
of moderately-large files (about 20k files so far) and (c) I don’t
trust git-lfs because of their treatment of a bug report I
filed. I recognize
that this last one might be somewhat petty – after all, lots of
people successfully use git-lfs. But I get frustrated by having my
bug reports closed without anyone checking if they’re still
bugs.
Another commenter wrote:
Yeah, this plus the apparent lack-of-planning regarding lenses & field of view make me wonder if OP had any of the background they should have had in stop-motion animation?”
This one is easy to answer: absolutely not! Instead, I have relentless enthusiasm and a willingness to make mistakes. It’s working out well so far!
I’m a mostly self-taught programmer. This has given me the arrogance to believe that I can do almost anything.
Dioramas weren’t my first choice for art. They were my third choice, after finding two illustrators who failed to work out. I think if I had had the choice, I would have rather signed on to this particular game as just a puzzle designer and programmer, leaving the art and story to someone else. But that didn’t happen, so I’m muddling through. I think the results speak for themselves: nearly everyone I’ve shown this game thinks it looks cool.
I say “do almost anything” above, because there are at least two things I know I can’t do: illustrations and music. My inability to illustrate is why I’m using dioramas. For music, finding a composer has been really tough – between a small budget and rather idosyncratic tastes, I don’t have a lot of options. I’ve actually got a composer under contract, but I don’t want to say more until I’ve got at least a few rough mixes in hand.
Anyway, the point of the post is: you can make a lot of mistakes and still succeed in making a cool game.
A few folks mentioned enjoying learning about my process. For you, here are two videos:
Speaking of comments, someone at a meetup suggested that I should film my work process, because everyone likes YouTube craft videos. It’s easy, he said. Well, no, it’s not easy – it’s yet another craft.
That kerning video, for instance, omits the bit where I fix up the kerning after taking a photo, because it turns out that it’s not quite right for the aspect ratio Steam wants. And the books video took me three tries, because the first time, my hands ended up out of the frame, and the second time, the hands were out-of-focus because the camera (that is, my phone) preferred to focus on the background.
Previous post: Six mistakes I made and one I avoided