Posted on September 14, 2019
Tricks and Treats
Yeah, it’s not Halloween yet, but by the time I get to another post it will be.
We’re still working on DeathMall! and on Dungeon Sweepers. These are the two isometric games that will blaze the trail toward Grindcraftia.
Next week, I’m meeting with an acquaintence to discuss marketing strategies for a GrindCraft2 Kickstarter. So, something could start happening this winter. There were 6 years between Bejeweled and Bejeweled 2. I mean, they probably could have just made another one the next month, but it took six years. Knowing that makes me feel better about Grindcraftia taking so long. Marvel took like 40 years to finally bring their characters to the big screen. So, neener or whatever.
I’ve been doing a lot of design on Grindcraftia. I get like one idea a day, so it’s probably good I’m not coding or I could end up forcing the design in a bad direction just to get it done. I like doing it right.
I’ve been looking at a looooooot of engines. Right now, Unity is the big craze. Evbuddy’s crazy bout Unity, yawl. But it’s a lot of 3d overkill for the type of game I’m making, and there are a lot of features I’d have to program by hand anyway. Seems like every engine has it’s limits. Some don’t port to console. Others do, but not to web. Others only do iOS, or only XBox and Windows phones. I notice that a lot of them use graphic card accelerators, which can be nice, but it can also do things like tiles slipping and movement between textures and things. These are things that people have grown accustomed to in 3d engines. But Grindcraftia needs to be pixel perfect. And cross-platform, and run in browsers. So I’m giving some serious thought to C++ and WebAssembly. C++ never goes out of style. It’s been around since the 90’s while other engines have come and gone.
I’ve been making a game a week for a client. I love the work, and I feel like I’m in a game development boot camp.
Anyways, here’s my new Grindcraftia mug:
Here’s some things that save me a lot of time, whatever I’m working on:
Organize everything by how you use it. (Called “organize by use”.) For example, I don’t put all my controllers in one folder. Instead, I put everything for a single process in its own folder. I don’t have a “left shoe drawer” for all my left shoes.
But wait, what if you use those components elsewhere? Now they are in the total wrong folder! Nobody can find them! What should we do? … Following the principal of “refactor when needed”, move the components/classes/etc to another folder as needed.
Within each file/class, organize by use again. At the top of the file, Public and Private declarations per usual, then everything that gets called once, like constructors and initialization. In the middle of the file, organize functions by user stories, the first or main user story at the top. Organize attributes, properties, and variables from “most general” to “most specific”. Consistency in organization helps me save a lot of time. I know that “isActive” is always near the top of a class, followed by isVisible, position, size, style… I can dedicate brain cycles to coding, rather than wondering where a variable or function is.
Similar to refactor as needed, program WET. If working in a team, program WET and then convert to DRY before committing to the repo.
I put brackets on the same vertical line, called Allman Style. It’s because when I code a game, I have to code and recode a lot. I think of it as sculpting. So, I’m cutting and pasting a lot of code blocks, commenting and uncommenting. When the opening and closing bracket are on different vertical lines, its very easy to accidentally copy two code blocks, or miss a bracket when commenting. Can it be undone? Yes, at the cost of losing a little momentum and a little train of thought. So, Allman Style.
Abilities vs Permissions. Just because a character has the ability to swim does not mean the character can swim at any time. We use the word “can” in everyday speech to mean both “has the ability to” and “has permission to.” Remember “Can I go outside?” -“I don’t know, CAN YOU?” That’s what we’re talking about. canSwim vs maySwim. I use the “can” prefix to mean the character has the ability to do something, and the “may” prefix to mean the character has permission to do it.
When a character or entity has transitions from one state to another, the transitions should be separate states. Use -ing to mean something is moving or animating, or playing. character.isWalking, door.isOpening, video.isPlaying. Use -ed to mean a static state like chest.isOpened, orc.isDead, song.isFinished. Don’t use verbs that can mean several different things. Like, don’t use “open” because it could be either a static or animated state, or even a command. I’ve been a part of meetings that went way too long because one person was talking about an animation and another was talking about a static state, or a user action, all because of poor naming conventions.
Adopt your conversation in meetings to use the same naming conventions in code. Name your assets using common English, bringing idea and language into parity as close as reasonably possible. redBalloon.png instead of balloon_red.png. To avoid lumping all your “red” assets in one area, break them out by use, in their own folders. A sprite of an opened door is “oakDoorIsOpened.png”, a video of a cut scene is “markAndSarahTalkingAboutTheMonster.mp4” An animation sprite sheet of a goblin dying is goblinDying.png. The extra seconds that it takes to type descriptive variables will be worth the minutes it takes to figure out what cryptic code is doing.
“move” means that an object is changing it’s position toward a desired destination over time. “position” means that an object instantly changes it’s position. “animate” means that an object is changing the way it looks over time, either by a component moving within the object (like a rigged character moving an arm), or by replacing it’s pngs to create a frame-based animation.
There’s probably a lot more tricks than this available. But these are the ones I keep coming back to that save me time, but for some reason aren’t talked about too much.
Thanks for reading.