Rethinking "fast" Posted on June 15, 2017 at 09:14
A huge focus of mine at work over the past few months has been performance. Performance, in the sense of making sure our product is running not just well enough but truly well.
Unfortunately, that isn't where our product is, but we can get there.
Performance is something that basically has to be a given these days, especially regarding the web. On average, the majority of people will navigate away from your website if it doesn't have a meaningful paint by 3 seconds. Given a halfway decent internet connection, that should not be a problem.
Unfortunately, as projects grow, deadlines arise and corners are cut, performance and forward thinking falls to the wayside in favor of getting stuff out quickly. That, or misconceptions about the "right way" to do things appear.
We've seen this first hand with our product, which is a huge React application. Now, React is fast - but what isn't fast is when you have thousands of components on your page, each doing heavy lifting every time anything updates. We adopted React very early on, before there was a lot of reading about the right way to do things. Because of that, our application does heavy lifting all the way down, so if you need to render something with 10 layers of children, suddenly it chuuuugs.
Anyway, this kind of thinking has driven a lot of my development recently. For one, I found a way of developing and hosting the Evenfall website to keep it quick, super lightweight, and highly available. Granted, it is a small, static website, but I chose that on purpose to allow for this to happen.
The website is built with Metalsmith, a build tool for static websites that is entirely plugin-based. I have just as many plugins as I need, and nothing more. The site builds in about 1.5 seconds, and most of that time is spent transforming the favicon into all formats. Without the favicon transform, it goes down to under 1 second.
The output is then just served from an S3 bucket on AWS, with a CloudFront CDN distributing it. All of it was easy to set up, and serves this website over https, quickly and efficiently for a few dollars a month, at most.
I also apply this mindset when working on the game itself, but I will go into that in another post. Jonathan Blow did a great talk about speed recently, and in it, he used Photoshop as an example: It takes photoshop several seconds to open the "open file" dialog on his beefy laptop. Now, if computers have gotten so much faster, why does Photoshop still take several seconds to open this dialog, when a computer that was orders of magnitude slower took the same amount of time to open the same dialog years ago?
The answer is bloat, for sure, but it makes you think. Virtually nothing in a standard workflow on a powerful machine these days should take more than a second unless it is doing serious computational effort. Like compiling, for example.
Except, woops, this talk is also about his programming language, Jai, of which he shows the compiler compiling and linking a 50k+ line program in 0.4 seconds.
Anyway, its a good talk: (audio starts at about 1:15)
I would cross post it here, but its kinda long and full of videos / images and such all formatted nicely.
After taking off all of last week to solely work on Evenfall, its been a bit of a shift to get back into a normal rhythm, but things seem to be going well.
I've been hard at work on a handful of things, both with Evenfall and otherwise. We've had some interns start at work, and I'm on the team working with them, so that has occupied a lot of my time and thought this week.
When at home, I've been working on balancing some of the content already in Evenfall, while working on new stuff. It does take me a bit to get into a flow where I can churn out truly new content, which is hard when I only have a few hours to work on it a day. That said, there's a lot of refinement I've been able to do, so to those who have played the first playtest, expect a lot of changes!
I'll be posting here when the call for signups for the second playtest goes out, probably in about a month. Those who received the first playtest are auto opted in, so let me know via email or DM if you want to be removed from that list.
I'm also beginning work on a couple of things that I hope can generate a little bit of passive income. I'd like to start making some informative, static websites that use amazon affiliate links or something to generate a little bit of cash flow. It's mostly an experiment, but if I can find a content model that works, it could be good to get a bit of financial freedom that way. Or, at least a dinner out of it.
Part of my time off was adding new stuff, and part was fixing up old stuff. While the art is still very early on, I want to get the gameplay just right, and get the content that does exist to a place where it is compelling. The recent feedback I've gotten is very positive, and I hope to keep on tuning the game to be as good as it can be.
I've been releasing some short form videos (3-7s long) on twitter, but got some feedback that its hard to get an idea of how the game plays in such short clips. So, I've recorded a slightly longer clip. Here is a boss battle from the end of one of the side quests currently in the game:
This is also to say that I've just this morning made a YouTube channel for the game, which you can find here. If you're interested, please subscribe! It would help immensely.
That's all for now. I hope to give more updates about playtesting and such soon.
Thank you all for your support. I look forward to working with members of 64Digits to refine the game through playtesting and discussion. You have all played such a huge part in my life, as I attribute my career and love for programming to 64Digits.
1 Year In Development Posted on May 11, 2017 at 09:20
I looked at my phone yesterday evening and saw a calendar reminder for today. Today is the day that I made my first commit on my project last year. Holy shit. Granted, I've only been working on some nights, mornings and weekends, but so much has been done over the past year.
First off, it hasn't felt like it's been a year. Life really starts to cruise by when you're working full time. I've been trying to combat that by being generally more present in the moment, but even so, you look back and it's all gone by so quick. Luckily, still full of lots of good!
I wanted to do something momentous for today, to celebrate the occasion. Something like truthfully announcing the project publicly. I thought it would be a fun thing to do, but I also still don't think the project is ready to be announced, at least not just yet. I also don't want to rush the announcement, I'd rather have something fun to show alongside the announcement.
Thank you to everyone who participated in the playtest. I got some seriously valuable feedback from you, and I'm taking it to heart as I move forward. It was heartwarming to see that everyone who played it enjoyed it (at least in some capacity), and that most everyone realized something early on in the playtest: this game will fuck you right up.
I don't want to make the game inaccessible, in fact, I want to make sure the player feels that they have complete control, but the original spark of inspiration for this game was one thing: if you step outside of town, you better damn well be prepared to fight for your life.
I think I've captured that to some degree, albeit some tuning is needed. I'm excited to have surmounted the foundation of the game. It's on to content creation now. I've set up useful tooling, both in and out of game, to allow me to get going in full force on making towns, quests, enemies and people. Now it's a matter of hunkering down, and coding / writing / spriting / composing as hard as I can. I have a long way to go, both in terms of where I want the game to be content-wise, and where I want it to be graphics-wise. I've never been strong with the art side of things, and this project will, hopefully, be the one to push me past my limits.
Thanks again to everyone for your support. I hope to have a page on itch.io or something soon. I'm so tired of referring to this project as "my game," but I'm not quite ready to put it out there yet either. Good first impressions, and all.
More to come, as always. Until I have an actual devlog somewhere, 64D will remain where I put the first looks at what I'm doing. Even then, I'll still drop the good stuff here :D
Next blog I do will probably be about an awesome setup I've made recently for writing dialogue trees. If that interests you at all, stay tuned.
Side Project, New Tech Posted on April 24, 2017 at 08:15
With the playtest for my game out there and in the hands of a small group of people, I've been working on a side project to fill the time while I wait for feedback. I'm still doing a little bit of work on the game, identifying a few bugs and making a bit of a smoother experience based on immediate feedback, but overall I am waiting to hear back from more people so I can compile a full feedback list.
The side project is a pretty simple website, but I think it will be a fun experiment. I've been really enjoying Keybase recently, for its personal identification, shared filesystem and chat. One of its cooler features, to me, is that you can have your public shared folder in Keybase, which is signed by your key, served through a shell website called keybase.pub, which will render markdown files automatically, and acts as a dumb web server.
I am drawing inspiration from this to make a tiny platform where you can claim an "identity" (effectively, an account, more on that soon), and create posts just written in markdown, which become available at a short url, similar to the way keybase.pub works. The goal is to allow for a frictionless place to plop posts, which isn't quite as demanding as a blog, and isn't quite as in-depth as Medium. Something simple and quick. Let me just post some thoughts and have it out there.
There won't be much in the way of logging in. You'll identify yourself with your name and passphrase at time of writing, but otherwise, not much in the way of account management. You'll be able to write a bit of a bio by writing a topic about yourself, and visiting the root page at your subdomain will list your bio and all things you have written about.
I might take it a step further and allow posts-as-replies, which I think would be a fun way to add a little bit of depth to the service without making it complicated or spread out too thin. Writing, and posting. That's it. No bullshit.
I am also using a new-to-me database which I've had my eye on for a while, LevelDB. It is a simple key-value store, with not many bells and whistles, but boy is it fast. I will probably be writing a small abstraction layer on it, which I may open source. LevelDB is the foundation for a lot of other database projects, just because it is so simple and quick, and it's JS api can have the backend swapped out for other connectors, which is pretty sick.
Overall excited to work with these techs, and hopefully I can product something nice. My free time is dwindling, though, and most of it is spent relaxing in the evening, or working on the game. Hoping I can find time to finish this project.
That's all for now.
realizing this is about the closest I could get to twisternet 2 without raising alarm bells with legal at my job
The Littlest Keyboard Posted on March 23, 2017 at 09:16
This is going to be a hard one to type. I say that because I'm typing this on a 40% keyboard, which I just plugged in this morning to my computer for the first time. I have virtually no idea how to touch type on this thing when not just typing letters, which, by the way, is exquisite on these cherry mx browns, which actually feel a lot better on this board than on the other board with browns that I have.
If you're not indoctrinated into the wonderful world of mechanical keyboards, this will all be gibberish. Actually, it won't be, this isn't actually complicated.
I bought this keyboard and it arrived last night. late last night. So, I picked it up this morning and replaced my old board with it. I say "old", but really it was just a few months, which my fiancee pointed out quite a few times.
To give a sense of just how little this thing is, here's a picture of my pasty white hand in comparison to it:
Let's see if I can crank out a decent enough post in the next 10 or so minutes before I head to work.
I got a switch launch-week. Very lucky after not pre-ordering to find that a coworker pre-ordered two, just to be sure. I bought his second one from him, and we did this dead-drop situation where he left it at his desk over the weekend in the office for me to pick up. Covert ops.
Of course if I got a Switch, its because I wanted to spend too much money on a Zelda machine. I'm looking forward to the lineup of games coming down the pipeline, but for now, yeah, Zelda (and snipperclips!) machine. Snipperclips is actually very fun and you should try it, though.
Zelda is amazing. I'll not just sit here and add to the swirling river of praise this game gets, but I will say it is well deserved. I want to talk briefly about something else that really makes me just love the switch: speed.
I'm not talking about processing power here, because it could for sure use some more of that. What gets me is that when I turn on the switch, I get right back into the game in single-digit seconds. This may not sound impressive, but it feels so good when I pick up the controller, press Home to turn on the console, then press "A" and I'm right where I left off in my game. It acts similarly to the 3DS, where when you close the lid, it just state-pauses. Only, this feels like a home console, not just a handheld.
I find it to be a killer feature, really. Its obvious that both this console, and Breath of the Wild, were designed to respect the fact that Nintendo's playerbase have largely grown up and have other responsibilities, or limited time. I can get into the game in notime, play for as long or as little as I'd like, then put the console to sleep without having to go through a save process, and knowing I can just resume immediately the next time I swing by it.
If you haven't played with a Switch yet, be sure to see this for yourself. It is much more impressive in person.
Who else has a Switch by-the-by? Are we in need of a "share yer friend codes" blog or do we have one? Don't put your codes here though, since this is a public facing blog. We can set up something more official if there is a desire.
edit: Ayy, 7 minute writing time. I did it. Off to work.
I made the first commit of my game in May 2016, so I'm coming up on a year of development time here soon. In some ways, it doesn't show. For one, I haven't spent all of that time working solely on the game - I've taken long breaks, and even when working on it, I only have the time that is outside my normal working hours.
In other ways, it definitely shows. In the codebase itself, I've formed a foundation which is a joy to work in. The majority of the time spent over the last year has been engine and toolchain development, both internal to the game code and external.
Some of the work I've done in the realm of "foundation" is already open source. gdash, which I've already posted about here a while back, is an open source gml package with a bunch of very useful data manipulation functions that are either missing or sub-par in GML. While it isn't rampantly popular, it has 13 stars as of today, which is actually pretty good for a GML repo on Github.
The GameMaker community isn't exactly the most technically advanced bunch on the whole, but at least from my vantage point, it seems like there is a shift in the wind. With the release of GM:S2 and what seems like a renewed focus on making GameMaker a really nice utility, I've been tinkering with the idea of packaging up a lot of the foundation work I've done as an open source project, so that others may get going quickly with a project idea they may have.
The foundation work I've done is largely game-agnostic. I purposefully kept it so while writing it so that I could re-use it in other projects. It covers things from data manipulation (gdash), to game state management, to saving/loading, to custom event and timer implementations to provide an alternative to GameMaker's frame-focused timers. Not to mention just a big folder of scripts that are basically my answer to "how the hell does GML not have this function?" Examples include "ds_list_add_map" and "mouse_is_hovering".
My current proposed toolchain would be a handful of GML packages that work well in tandem to make for a better starting point inside of GameMaker. No game logic, just tools to help make the game happen. I've spent a year building these tools, which is a year of time not spent building content. Luckily, I'm on the content building phase now, and thanks to a great foundation (which does include game-specific tooling as well, not to be included in this proposal), I can sit down and crank out new content in short bursts, rather than having to build endless situation-specific code.
If this is something at all interesting, I'd like to know. I've been on the fence about this for weeks. I'd like to gauge general interest vs preferring to roll your own solution. Though, I just realized this is absolutely the wrong community to ask the question do you prefer to home-roll solutions :)
Project Structure Posted on February 24, 2017 at 08:19
I got a few requests in IRC yesterday to talk about how I structure my GM:S projects. My current project has a whole lot of resources, and needs to be able to have a whole, whole, whole lot more resources while still being manageable. I'll go over my general process, and talk a bit about other relevant subjects as I see them fitting in.
The first, and probably most difficult resource type to manage is objects. You generally need a lot of them, and sometimes they don't quite lump together in the same way that, say, sprites would lump together under a given purpose. That said, there are still plenty of ways you could try to lump together your objects.
In my project, I have the following top-level object structure, all of which are groups:
walls and objects
I see these as the highest level of taxonomy in my game. Under each is either the terminal of the resource tree with leaves being objects, or more directories to more objects.
Beyond grouping into these lumps, alike objects are named with a deterministic naming pattern, such that when I am searching for one type of object, anything related will show up as I search. GM:S2 has a GoToAnything search (Ctrl+T by default) to bring up any resource that matches your string. This is immensely useful in general, and naming with a solid schema helps here as well. Let's dig down into spells -> elemental -> ice spike, one of the lower level spells in the elemental category in my game.
Everything is prefixed with "obj_spell_ice_spike_". This pattern is the exact same for every spell in my game. I know to search "obj_spell_" to list out every possible spell related object, then its just a matter of narrowing down what spell, then what part.
This pattern is similar everywhere that I could make it in my project. NPCs are all "obj_npc_whereTheyAppear_npcName". This way, I can look up all the NPCs in a given location.
When you start to use this namespacing pattern, natural groupings will appear. From there its just preference how much you want to chunk down into groups.
My project increasingly relies on scripts to do almost all of the heavy lifting. I've built myself up a really strong foundation to manage save/load, world data, item lookups, inventory management, npc movement, spellcasting, hud management and so much more. As much "business logic" as possible is done in scripts. This lets me re-use them anywhere, and write out good documentation in the heading of the script, so that GM:S2 displays context completion when using them.
I name scripts in such a way that they would feel like any other gml function. I see it as "adding on" to gml to create a GameMaker specifically for my game. With that in mind, my naming schema for scripts is:
Let's look at a group of scripts I have: data management. I'll use the script that generates the controls data. The system name here is "data". Everything with the prefix "data" will relate to ephemeral, modifiable data in my game's runtime.
What is this script doing in the system? Well, I'm initializing data, specifically controls data. So, my directive is "init".
Now we have "data_init_".
Finally, this script is initializing controls data, as we've said, so, "data_init_controls" is the final name of the script. Along side that script, I have:
Keeping the order to further specify the system you want to leverage, working you way to the action you want to take can not only help keep you sane when coding, but make it that much easier to just change the last word should you need to refactor.
This is very similar to the object structure, though with a focus on namespacing scripts that work in the same "system". Keeping to this structure means you won't have confusion with name collisions when you've got a bunch of scripts, and as I'm typing a script name, my suggested completions are only related scripts, not something that happens to have the same start to it.
This may all seem super basic, but its something I've learned from previously structuring projects with no real regard for the long term. Being mindful about naming resources has lead to a very nice time expanding the resource tree. The rare cases that don't follow these patterns get me every time.
With these concepts, you can probably structure any resource type. I do a very similar pattern for rooms as I do with objects, only using "rm_" instead of "obj_" as my prefix. I do not use prefixes for scripts, to keep with the concept from before of trying to "extend" gml.
If anyone found this helpful, let me know. I'd be happy to also do a write-up about object structure, going over how I manage data between objects and the save system, and how I handle local variable structure and code structure within objects vs scripts.