It’s actually just pressing buttons.
Goals going in
Just make a game for this jam. Honestly, the first inspiration and goal was to make sort of a mandatory social experience. The original plan was to have a game where you logged in via Twitter, greeted only with a timer and a button saying “Win the game”. Your score was how long you waited, and it would tweet a vague “Can you beat my score?” for you. I’m glad that didn’t work out.
What went right
There were a few simple successes this time.
It was small! It was 24-hour gamejam small, despite RuinJam going on for quite some time. Which is good, because I procrastinated and ended up writing this all in < 24 hours, including some sleep.
I took a very small chunk and got it playable rather quickly. By the end of the first night, 90% of the actual work was there. All that was left was polish and script writing. That left a lot of time to iterate over scripts and deal with the more obvious flaws.
It’s not perfect, and it’s not even what I’d call fun. But I like it! I feel really positive about this project. It’s pretentious as hell, and I could go on about what it ‘meant’, but frankly it was a fun project and I’m not overly embarrassed by the outcome.
What went wrong (and how I want to address them)
I can’t remember a time when GDX’s deployment hasn’t caused headaches. The way forward is
- The font didn’t scale well, and it’s the default GDX one.
- The three main areas of ‘play’ are too far apart and should be brought together to make it really obvious when something changes.
- I wish I could’ve gotten the button feedback to pause a second so it’s harder to rush through. I wonder how that would’ve changed the script writing.
GWT is the best and worst thing to happen to my gamedev. Before adding a web-playable client, this game would get 1-2 views. Then, add a web-client and the views spike (admittedly, it’s not a perfect test as the game jam was wrapping up and getting press, that sort of thing). Anecdotally, it doesn’t take much for me to play a web game, but it takes a lot for me to green-light a download that I’m going to have to test and trust.
But I’ve never built
gradlew html:dist without seeing errors. Every time I build the web app, something isn’t supported or mysteriously breaks. With Bagger, it was Java’s Observable set up. Fine, I’m not thrilled with it anyway, I’ll make a new one. This time, it was GDX’s handy (if a little cumbersome) JSON parsing. GDX gives a one-line way to Serialize and Deserialize Java classes to and from JSON, which just wouldn’t work in the HTML5 version.
I ended up writing all of that code myself, at some goading from @thetechnoweenie. And I’ll be doing so in the future, pre-emptively.
When HTML5 wasn’t working, I hastily through together a desktop .JAR together to at least get it playable and distributable. And again, there were issues. I’d never considered a Desktop artifact, so I’d never built in Resizing code. If you changed the (very small) window’s size, everything scaled to the eye, but the clickable spaces and the like didn’t expand to account for this.
I was also using Gdx.files.internal, which usually gives a path to the working directory. In GDX that’s usually the assets folder. Thinking myself clever, I just listed the directory and would read the numbered files in order to play the scripts in the right order. But you can’t actually list inside of a JAR, at least through the interfaces I was using, so I instead hard-coded all the filenames to get it out the door.
I’m trying really hard to stop myself from tweaking this game. There’s a few tiny things that really bug me about it, but I don’t want to get swallowed by this project. It’s mostly run its course.
I’ve been working again on Tradesong. It’s a fun little side project that I’m caring less if it ever happens, though I’ve got some fun ideas to explore.
More a thing for myself, I started pulling concepts I reuse and rewrite in games in to a common framework.