posted February 16, 2020 | tagged
- have the structure of the test point-and-click (mostly) figured out
- “pencil test” versions of three more rooms drawn but not in-game yet
Another weird week for me. I swear I have other “real” posts in the pipeline, just haven’t had a whole lot of time to write.
See you next week!
posted February 09, 2020 | tagged
- decided that I needed an actual game to test out my visual novel prototype, came up with an idea for one
- started to lay out the game with sketchy “pencil” drawings
This week has been a little crazy for me, so I’ve gotten a bit of Gruedorf stuff done (though less than I’d like) but no big post. Oh well! The weekly post must go on.
At some point I need to explain more about what I’m actually building. I probably should have done that earlier. Truth is, I’m at a weird point right now with multiple projects. Soon, I hope, I’ll have something to actually talk about and for you to play with.
posted February 02, 2020 | tagged
- cleaned up “room” handling for the visual novel prototype; they’re real scenes that swap around now instead of just background changes
- you can put NPCs and other clickable entities into rooms
- a bunch of trial and error on writing cutscenes and making that system more manageable
I have a problem.
One consistent issue I’ve had throughout my personal development projects is that I am constantly making things harder on myself than they need to be. I have a pretty destructive streak of perfectionism, at times, and it hits me worst when I’m working on a project that combines a few fatal flaws:
- It’s a personal project; no one else is paying me for it or calling the shots.
- It’s got no real deadline.
- It’s something I actually care about it, and “counts”.
I have, thankfully, managed to pack away most of these impulses in my professional life. I can get myself motivated to figure out what’s good enough, rather than what’s an unattainable Perfect, when other peoples’ money, expectations, and time are on the line. It’s not that I don’t care about my work, it’s just that I’ve learned to find reasonable trade-offs and negotiate.
When I’m working on games in my spare time, though, I often have all three of these in full force.
It’s really the third point that gets me. Like any good indie game developer I have a lot of projects that have taken up residence in the back of my mind, poking at me occasionally to work on them. Sometimes I can quiet these with a couple of drawings or a few hours of tooling around on the weekend. Others, though, have gnawed away for more than a decade.
All of that time lends power to those ideas; it makes me see them as bigger than they are. Let’s face it: an idea with no follow-through is pretty small (and pretty useless). The years of thought and mental work I’ve lent to them, though, makes them seem monumentous and weighty. It makes them see important.
Which makes it hard to let them be just “good enough”. They have to be perfect.
In Defense of Good Enough
“Good enough” really is good enough, though, you know? It’s right there in the name! An idea that’s executed at three-quarters of its potential (over-blown) greatness is way better than an idea that sits in the back of your mind making you more afraid of trying it with each passing year. Getting it out in the world means it can be bad and get better, instead of existing as an elusive, useless platonic ideal of what it could be.
I know this intellectually, but it’s much harder to put into practice than it is to recognize.
I love a lot of stupid jokes. An old standby of mine is, “If you always assume the worst, you will only ever pleasantly surprised.”
One way to deal with this unfortunate perfectionism is to set your own expectations low. Really low. Tell yourself you’re building a piece of garbage. Garbage can be useful, after all! You can use it to shake the kinks out of some ideas, or to test an engine you want to use. If you can’t make something brilliant (because your only ideas demand brilliance from you) than make something bad. Maybe you’ll surprise yourself with what you get out of it.
This method has let me build an entire (small) jRPG, and write an unnecessarily-long novel (but, sadly, not to actually edit it into anything readable, yet). In both cases, I was pleasantly surprised. Neither of them are great masterpieces, but in comparison to the “terrible garbage” I set out to make, they are pretty good.
I can’t actually really recommend this to anyone else, though. Just writing it out sounds dumb enough that I suspect it is, in fact, actually dumb. It has helped me a bit, but it fails in crucial way:
It doesn’t actually get the projects I want to do done. It just delays them. It’s just procrastination, really. Who wants to spend all of their spare time making garbage, anyway?
In Defense of Perfection
There’s nothing wrong with wanting to make something good, and not just merely something that exists.
There’s something magical about an idea that’s stuck with you for a long time. It has grown up with you, and changed over time. Maybe you remember earlier iterations of the idea, and how you’ve morphed it into something you like much better. Maybe you remember the discarded part, and can work them back into it later, but better. You can see how different things in your life have influenced your plans and your thinking. That magic, the source of the unfortunate seductive perfectionism, also gives the project life for you. It’s easy to be excited about that old project.
There’s something to be said for actually aiming high, but being accepting of the fact that you won’t ever quite hit what you want. Accept it the exact same way you accept the fact that your “piece of absolute trash” game is actually better than you anticipated. Treat the ideal in your head as a landmark to guide you, even if it doesn’t end up being your destination.
At least, I hope this all works. I’ve still only made garbage.
posted January 26, 2020 | tagged
Technically this is stuff I’ve done over the last few weeks, not just the last week, but a bunch of it was done in the last week. I’m establishing a baseline here.
- Finished up a Godot-based prototype RPG that I started a couple weeks ago. It’s got…
- standard jRPG-style movement, including proper obstruction handling
- walk-on events and button-triggered events
- asynchronous/re-entrant cutscenes
- Got a start on a VN/point-and-click game prototype in Godot. It’s got…
- speaker portraits
- asynchronous cutscene handling
- background image switching
Cozy Engine is a web-technology-based game engine that I started working on in 2015. Originally, it was called Egg, but I eventually renamed it because I discovered an existing game engine using the name, and because I liked “Cozy” better anyway.
It’s my latest iteration of building a general 2d game engine, which I feel like I’ve been doing pretty constantly, under various names, for most of my adult life. Settling on web technologies was a way to make it familiar and quick for me to work on, since I’ve been primarily a web developer for my entire professional career so far. Earlier attempts had been built in C++, with embedded VMs like Lua, LLVM, or V8; I believe I started at least one attempt with Monogame or XNA, and there was definitely one shot at building it as a collection of scripts in Unity. I’ve looked into graphics libraries in Python and Ruby, and various so on.
I keep doing it because every time I try out a game engine, I kind of hate it. “Hate” is a strong word, I suppose. I invariably run into some eccentricity in the architecture, or something in the language, or something about its performance, or whatever other thing bothers me t the time, that makes me disenchanted with sticking with it for long enough to make an entire game.
So, of course the obvious solution is to build my own.
I’ve released it under an open source MIT license, and it’s available on github at https://github.com/speveril/cozy. I also built a page for it at https://cozyengine.com/. Its icon is a cute cat. I even built a (small) complete game with it, SimpleQuest.
It does a few things that I still think are interesting and novel, but my interest in continuing the project is, admittedly, waning. It represents a lot of work, and it clearly works to make a video game. I’m less convinced though, now that I’ve done it, that it was worth my time to spend years building an engine to my specifications, rather than learning to live with engines that other people are already working on.
Living With Someone Else’s Decisions
I wasn’t always this way. Back at the tender age of 14, when I was apparently much wiser, I discovered a game engine called Verge. I didn’t really know much beyond the basics of how to build a simple text-based game, but I had wanted to make them basically since I was old enough to play them. While I’d learned bits and pieces of programming up to that point (mostly various flavours of Basic, a tiny bit of C, and a little bit of MicroMUSE scripting), Verge let me put graphics on the screen and move them around so much more easily than anything I’d worked with before. It let you make maps with layers, and animated sprites. It was very exciting!
So exciting that I eventually learned how to use Verge quite well. I didn’t manage to ship anything to anyone else until years later, but I got pretty familiar with it. By the time the third iteration of Verge (aptly named Verge3) rolled around, I was ready to actually start making things. Over time, thanks especially to some “Hours of Verge” competitions (think early game-jams), I got quite comfortable and fast while working within its constraints.
Its constraints were pretty… constraining. Its built-in language, a straightforward C derivative, had bugs, and design decisions driven by what was easiest to implement. It had hard-coded limits to the number of sprites you could use at once. It was a lot of fun, and the community was vibrant, though, and that was enough for me, at the time. I made multiple starts on a Big Game.
Old and Picky
Eventually I “outgrew” Verge. The slow dissolution of the community (as most online communities experience, eventually) is probably what did it, honestly. It was easy to overlook the technical faults of the engine when there was a community of people to share excitement with.
The idea of Verge also, early on, sparked in me the realization that an engine can be made by anyone. I love the idea of a reusable, useful core to build lots of games on top of. This realization has been a bit of a double-edged sword, though – I have a pathological need to build things as generically as possible now, and to approach every game in the content of an “engine”. I want to make a game, but I also want to write as little as possible in a way that it is specific and unique to that game.
This led to me splitting my time between trying other game engines, and building my own. No engine that I tried ever seemed to match Verge, even though they were technically more capable. I realize now that the problem never really was the technical issues, but it was me: I’m an introvert by nature and will not usually immerse myself into the community. Even with Verge it took me quite a while to become comfortable engaging with everyone else. With other engines, I just never did, which meant they always felt incomplete.
Given all of that, it seems silly that my fallback would be to build my own engine, but here we are. I started a lot of them. The one that’s gotten closest to complete (in that, I ever shipped anything with it) is Cozy. I’m realizing now, as I write this, that I think I’ve finally figured out why. No matter how much I tried to keep myself focused on technical issues, in the back of my mind I was thinking about how Cozy would support people working together and sharing things, and how a community could build up around it. That might have been what kept me going, the imagined future community.
Always an Engine, Never a Game
The problem with all of this is that I don’t actually especially want to build a game engine. I want to build games. Forcing myself to build an engine first, before a game, is just procrastinating. Without an engine that I like to hang my hat on, though, the other option is just hand-rolling things at a lower level, and I hate that idea.
So recently, during the end-of-year holidays, I decided to suck it up and take a hard look at some Actual Engines. There were a few stipulations I had…
- I have to enjoy using it
- I have to be able to hold my nose and accept the architecture
- I have to have some path for future portability of the games
- I can’t be the only person maintaining it
In retrospect maybe I should have put “It needs to have a community around it” but I hadn’t written this post at that point.
Cozy, by the way, fulfills the first two of these well, almost by definition. It absolutely falls flat on the last two. Being based on web-technology, the games work great on Windows and Mac and in a browser. Linux would be fine too, but I haven’t tried it. Consoles and phones would be a garbage fire, and would probably just mean rewriting everything from scratch, losing most of the benefits of the engine that made me create it in the first place. The last point is particularly salient too – like I said, I want to make games, not maintain engines.
I tried a handful of different things, and maybe I’ll write more about them in the future, but for now I’ve settled on Godot. I’ve still only been working with it for a couple of weeks, but so far it’s feeling pretty good. I’ve been building small prototypes in it, and am just about at the point where I want to build something a little more “real”, something new along the lines of SimpleQuest.
Years ago, Gruedorf was a pact between myself and McGrue, a friend/nemesis, to get us both working on our game projects consistently.
We did it for years, mostly between 2008 and 2011 or so. As things do, it fell apart from lack of time and interest. Everyone could use a little bit of a push now and then, you know? Shortly after the new year, McGrue re-challenged me – there was a virtual glove slap and everything. So I guess we’ll give it another go.
The rules are pretty straightforward, really.
- Work on a project for at least an hour (or so).
- Write up a blog post (or something) logging the work. If it’s applicable and time permits, include some thoughts about the work, eye candy in the form of screen shots, etc.
- Once the blog post is out, you have seven days in which to repeat the first two steps. If seven days pass and you have not posted again, you are now losing. You continue losing until you post again, at which point your seven day timer is reset.
Anyone can join in, if you also need a little bit of a consistent push to get working on that thing you’ve been putting off. As you may have surmised from reading the rules, this is primarily a competition between you and yourself. Unless you are McGrue, in which case this is absolutely a competition between you and me, and you are going down.
Well, this week I set up a blog again. I hate setting up blogs, and pretty much all blog software. While in the future I’d like to dig more into what I’ve been doing each week, re-litigating getting this set up would mostly just be self-indulgent whining, so I’ll let it rest.
If you’re reading this, it’s probably working, though! The worst is behind me.
I’m also working on two(-ish) projects in my spare time. I’ll post more about them next time. They’re both in a bit of a weird state right now: I’ve been working on them for a while but recently have become displeased with one or another of the decisions I’ve made in the past, and have been wrestling with how to get myself productive on them again.