gamedev

Publish or Perish, or How I Stopped Worrying And Learned To Love Extensions

Leave a comment

THE GAME

Here’s my game for the June Challenge:

Publish or Perish!

(screenshot)

I’ll explain the game, but I also wanted to talk a bit about extensions and making games as a hobby to provide a bit of perspective on where I come from as a game maker. But first, the game!

Controls are on the start menu. The mechanics aren’t as well sign-posted (I ran out of time) but here are the basics:

  • Killing enemies gets you SCIENCE;
  • 1000 SCIENCE means you can publish! Hit Enter to do so;
  • When you publish you generate BUZZ. You start with 30 seconds worth of BUZZ, and if you drop to zero you’re dead! Keep publishing to top up your BUZZ!;
  • When you publish you get PAPERS! PAPERS increase the size of your area attack (active every 3 seconds);
  • The more papers you have, the greater your passive chance of getting CITATIONS! CITATIONS also increase the size of your area attack; and finally
  • You can get hit 6 times before ‘dying’. But dying doesn’t mean you end the game! You just get both your papers and citations reduced. Think of it as being found out as a fraud. :P

PoP is based on my experiences during completing my PhD a few years ago, during which I would hear this refrain ‘Publish or perish’ over and over again. The saying is referring to academic papers: the one most-looked-to metric of judging how good a scientist you are in academia. For those not familiar, an academic paper is a summary and explanation of your work that, as a scientist, you publish in peer-reviewed journals in order to get citations (basically ‘likes’ by other scientists [although that’s probably a little cynical]) to show that your work is relevant and of high quality.

To me this system of publications, citations, and networking has always seemed like a game. It’s too easy to fall through the cracks as a young academic, too easy to exploit the mechanics as an established one. So I thought I’d try and make a game to illustrate that. It’s definitely not nearly as polished as I’d like it to be, and it’s probably not what I’d call finished, but I’m moving to a new city in three (3!) days and I needed to put it down and finish up my packing. :P Now, onto my discussion about extensions!

MY THOUGHTS ON EXTENSIONS

If it’s not already incredibly obvious, I used extensions to make this game. Specifically, wLewis’ Platformer Engine, and PixelatedPope’s Retro Palette Swapper. Both are excellent examples of what a good extension should be: well commented, pretty straightforward to work out, and not bloated or made with inefficient code. They’re great! Also, big apologies to wLewis for using his player sprite; I ran out of time to properly animate this little guy. It’ll happen one day.

Anyway, I kind of just wanted to put forth the idea that using someone else’s extension/engine is not a sin if it helps you make games faster. Since I started using GameMaker, I’ve been learning the same way everyone else does: by watching tutorials and Googling my way through how to build particular types of systems. And I do think that it’s important to build at least a couple of systems as a way of learning how to use GameMaker itself. But beyond that, for a hobbyist like myself (and many other people that are using GM) I think there are definitely diminishing returns for trying to build a complicated engine from scratch.

Why do I think this? Well I struggled to build a pixel perfect platformer engine that could handle different enemy behaviours, walljumps, one-way platforms, etc. for 3 whole months. That’s 3 months that I could have spent refining a mechanic like my (terrible) papers/citations mechanic to be more enjoyable and challenging. That’s 3 months I could have enjoyed doing something like working on art assets. That’s 3 months I could have spent digging into level design and making multiple arenas for our ‘scientist’ to publish or perish within. It’s 3 months I could have used to be creative with ideas rather than code.

tl;dr Basically what I’m saying is that if you’re already a hobbyist game developer, and you’re already using an IDE like GameMaker, then do your creative self a favour and have a look at using extensions to give yourself more time to spend on the parts of gamedev that you enjoy more!

 

Disclaimers
Coding an engine can definitely be fun, not saying it can’t. I really enjoyed challenging myself to make a platformer engine and I’d probably do it again if I had the time. If you’re someone who only enjoys the coding side of things, ignore me entirely!

Most of my argument comes from the fact that, as a full-time worker, I haven’t got as much time as I used to to work on creative outlets. If you have time, learning how to code effectively is a totally worthwhile effort. Do it!

gamedev, gm48

‘Gravitas’ gm(48) post-mortem: Phill

Leave a comment

Untitled

HELLO

Welcome to the first post-mortem for the Titanfist effort in gm(48) for April 18th — 20th. As usual we had a pretty great time putting together a game for the jam, and walked away with a lot more knowledge of how GameMaker works and ideas for how to better manage our time. One of these days we’ll actually fit in a bug fixing schedule…

I should also note that we were unaware of the rule that you could use code and engines that you had worked on before the gm(48) as long as you listed them. It’s clearly stated in the rules, so obviously it’s our fault for not reading them properly. But we were under the impression you needed to write every bit of code fresh for the jam. So maybe take that into consideration when you rate our game? We’d appreciate it. :)

THE GAME

Our team made Gravitas, vote for it here!

Play the latest version of the game (updated with fixes and extra content) here!

And you can also listen to the excellent soundtrack:

Without further ado, kick back and read how our gm(48) went from my perspective!

AIMS

For this gm(48) we had a few aims from our previous efforts that we wanted to hit:

  • Keep it simple: our entry to the ‘You are the enemy’ game jam, Evil Fist, was full of a lot of pretty complicated systems. Far more so than a lot of people probably realised! Reinventing pokemon isn’t easy. For this gamejam, we wanted to have a base mechanic that was simple and easy to iterate on.
  • Easy Content generation potential: one thing we wanted to have in spades was content, and from the beginning we wanted to make it so that any team member could sit down and code up some levels quickly and easily. As you’ll read, we kind of hit this one, but then failed to follow through.
  • Sound effects: Our last effort had practically zero sound, so this time we wanted to have a bangin’ soundtrack and crunchy fx. For that reason (and because he has wonderful hair*) we brought on a new team member to be the sound guy. And he delivered!
  • More coherent art assets: This was a personal goal of mine, as I had a feeling I was going to be most suited to dealing with art assets due to some time commitments meaning I wasn’t going to really be able to be around when the engine was being developed. So I really wanted to nail my art assets and develop a constant, coherent theme. Did I nail it? Let me know!

DAY 1

Morning: Breakfast of champions

As is tradition, we travelled to the fabled Northbridge McDonalds to eat a hearty breakfast of bacon, sort-of eggs, and the most perfectly average coffee known to man. Armed with enough paper to start a reasonable bonfire, we waited patiently with full and slightly upset stomachs for the theme to be announced. Five minutes until the reveal. Four, three, two, one…zero! The theme for the 14th gm(48) is…”Top Down ____”? Groans from around the table. This was not one of the themes that we had wanted to go through. The argument could be made that it should’ve been tossed out as not actually being a theme as much as it’s a prescriptive design suggestion.

unnamed

But you’ve got to work with what you have, and the people had voted. We immediately began to think of ways to avoid having to look at a character’s head and shoulders, starting with James’ suggesting we should make a game taking ‘top down’ literally…by making a game about yanking people’s tops (that’s shirts for non-Aus people) down and off. Unfortunately that one contravened the gm(48) rules about explicit content. James kept riffing off the idea of not doing an actual top-down perspective and soon came up with another, not completely terrible idea: a game where you fall from the top of the screen to the bottom. A top-down scroller. We started imagining the kind of gameplay you could have from it, and pretty soon we had all gotten that excited glow which comes from talking about grandiose ideas that you have yet to try and implement. With that glow of optimism still firmly on our cheeks (or perhaps the McDonald’s blocking our hearts) we set off to make the best top-down scroller we could.

Mid-morning to late afternoon: Speed bumps

We started work while co-located at Zac’s place, which actually turned out to be the only time when we’d all be in the same place at the same time. If there was one defining characteristic of this gm(48) for me, it was the fact that I couldn’t get into a full rhythm until the final evening. Unfortunately, being old, I had a lot of commitments that weekend, including a 30th birthday party, a 1st birthday party for a friend’s daughter, and a soccer game. They were all spread out like speed bumps to prevent me from fully getting in the zone until we only had 10 hours left. Super frustrating for me and, no doubt**, the others.

unnamed (1)

Anyway, enough about me. That morning we put together a list of art influences, things we wanted to do and could do, and felt out our role in the team. James got stuck in to coding the engine and…well, he basically didn’t stop doing that until the end of the jam. The term ‘workhorse’ comes to mind. So while I can’t really describe his actions much, I can say that his system was really intuitive, very clean, and included checking the box for one of our aims of making content generation of levels easy to distribute. Everyone could jump in from the second day and program up a level if they felt like it. I think he’s writing a post as well, so I’ll leave it to him to explain in a bit more detail, but it was really freakin’ cool to jump in at different points and see it come together.

Anyway, still at Zac’s place, Zac got started defining the collision and death conditions, as well as putting together some sprites that we could use to play with level design as it was being put together. Tim was away from his main audio desktop but started working on sketching out some basic sound exploration, as well as putting up some images for inspiration. I began working on animating some explosions, but soon stopped as I realised that a particle system would probably be faster. Pixel explosions are some of the hardest things to get exactly right, and when they don’t look perfect, they look terrible. So I abandoned that just in time for Tim and I to need to leave to head to our friend’s daughter’s 1st birthday party.

Afternoon and evening: Rollerama

After Tim and I returned from our friend’s daughter’s 1st birthday (including an amazing patchwork sponge cake made by another friend of ours that gave me a sugar high for several hours) we found that James and Zac had gotten the engine into a workable state. I began filling in some of the animations and character sprites, as well as sketching out a list of assets that would make the game feel varied enough to warrant repeated play-throughs. Tim, now seated at his audio-making battle station, immediately jumped into drumming up some awesome beats for the title screen and main game, and also the sound effects. In the few hours I had before I had to leave (again, I know, I’m a pretty shitty team member) I managed to sprite up some of the wall variations and import them into GM so that we could see what the art style we had decided on would look like when rushing past the player. For me it was important to have enough variation in the wall sprites that the player wouldn’t be able to notice that they were repeating that often. I shouldn’t have worried since our end product ended up being frantic enough that most people aren’t going to be looking at walls. But hey, every little bit of juice helps.

1

With the walls complete and rushing by the player, I headed out to my friends’ 30th birthday party, where I would stay sober the entire night so that I could do more work when I got back, and still play soccer the following day‡. When we eventually got back from the party I kept working on the sprites and helped Tim out with a few particle systems issues, introducing him to the excellent particle design tool: Particle Designer! Not going to lie, he was kind of upset that he’d spent a lot of time working out how to manually put together a particle system only to find out there’s a program that can do it for you interactively. He may or may not have almost started crying. We finished up a couple more assets and then hit the hay to get an early start the next morning.

boomboomboomletmehereyousaywayo

DAY 2

Morning and afternoon: Sprites and soccer

On the dawn of the second day I decided to take stock of the sprites I had done:

  • Player sprite including spin animation;
  • 5 level themes consisting of between 5 and 8 wall sprites each, with narrowing and widening connecting sprites.

And the sprites I still had to do:

  • Title screen;
  • Middle obstacle sprites and background sprites (Tim eventually did the backgrounds while I was fiddling with particles);
  • Enemy sprites and bullet sprites for any enemies and the player.

unnamed (2)

That doesn’t look like that much, but at the end of the jam I had made over 125 sprites total. That’s a lot of sprites for someone who doesn’t really identify as an artist! The morning basically went towards making a dent in that number, before I was forced (once again) to leave the jam and go play soccer for a couple of hours. If we had lost the game I’d have been seriously salty, but despite a few tense moments we defeated our opponents 5-3 and I could return to the game jam victorious. From around that time onwards I was working alternately between art (and importing art, which was seriously beginning to be a pain in the arse) and level design with James.

Evening and morning: Last-minute mindf*ckery

As mentioned earlier, level design consisted of writing lines of letters and numbers that had been mapped to wall and obstacle objects. Unfortunately we ended up creating all the levels essentially as the last thing before the game shipped which was around 4:00 am, the morning before a work day. Picture us trying to write these lines of ascii, where there were five themes’ worth of wall objects, each with with different legends due to me not having sprited the same number of wall sprites. Rather than being able to say that, say, the number ‘1’ always represented the left-hand wall, it was sometimes randomly the letter ‘q’, or ‘5’. I felt really bad for not having the foresight to have made a common number of sprites across the themes. And it was a bit of a mind f*ck at the worst possible time. But you live and learn!

Close to the submission time we were trying to get an end state into the game where the player would essentially loop back to the start of the game, but with an indication that you had beaten it. Unfortunately when we tried to put this into the end condition we ended up complicating it to the point where random crashes were happening. By this stage it was around 5:00 am, so we all desperately needed some sleep. Despite it not being ideal, the decision was made to cut it and let the players play essentially forever if they wanted to (or could). Last-minute changes to collision were made, the executable was compiled, and Gravitas was uploaded to the gm48. Big sighs all around, and time for bed.

LESSONS

There were a few lessons that we learned during this gm(48):

  • Assign roles early: We decided relatively early that James would be coding the engine, Zac would be handling modular bits of coding, Tim would be doing sound, and I would be main artist. This helped us to be able to focus on our areas and not run around trying to do some of everything and overlap.
  • Generate levels early: We left our level generation a little bit late, which meant we couldn’t really do much in the way of iteration. If your game relies on making levels,maybe place a priority on that.
  • Juice counts for a lot: Our base game mechanic is very simple, but one of our aims was to juice the hell out of this entry, and I think that does a lot to make it a lot more enjoyable than it would be without it. Out of all our achievements, I think the way it looks and feels is probably what I feel most proud about.
  • Leave time for testing: Even though James is an epic coder and managed to put everything together such that there weren’t that many bugs, we still found a few situations after the submissions where players could reach an unsatisfactory game state. If we’d had a bit of time planned for testing, we might have been able to fix those up.

WRAP-UP

Thanks for reading, please feel free to comment with feedback on Gravitas, we’re always trying to learn and improve with each game we release.

—

*It’s glorious.

**No really, there’s no doubt. They gave me shit for my absences for the entirety of the jam.

‡Playing a full game of soccer in the harsh Australian sun when you have a hangover is not advised.

challenges, gamedev

March Challenge: ‘wmra’

Leave a comment

The Game:

Before reading, you can play this month’s challenge game, ‘wmra’, right here! Give us some feedback here in the comments if you feel like it. :)

The Challenge:

As you may know from my HORSE JUMPER ULTRA XXL post, every month the r/gamemaker subreddit hosts a prompt consisting of a beginner, intermediate, and expert challenge. This month’s prompt invites people to:

  • Make a game with the restrictions of a past console;
  • Make a game including stereo sound; and
  • Make a game that makes use of steering behaviours.

I put quite a bit of effort into this month’s challenge, so I thought I’d do a post-completion post on how I went about my process. Here we go!

Braindump:

At the start of any creative project, I try and do a braindump. It’s basically just a conversation with myself typed out on the screen. Its purpose is to get a few ideas onto the page and argue out their pros and cons. Here’s what I dumped for this challenge:

Gameboy palette and screen size.

What lends itself to a small screen size? Either you have to make a game that has very small sprites or very large sprites and uses that in conjunction with simple gameplay.

Endless avoider? Could combine this with the stereo challenge to make it so that when a sound plays in one stereo it means a block is coming from that side?

Sounds good. Could ramp it up as you go, introduce platforms and shit. High sounds for higher spears.

I’m pretty informal when I talk to myself. Once I had my idea, I needed some art!

Art:

First thing to do was find the right resolution and colour palette for an old-school Gameboy. Once I had that, I sketched out a background to get the flavour of the game. I don’t usually start with assets, but I hadn’t done any art for a really long while and I already had a platformer engine coded up from a previous project. So I felt like doing some artwork. Here’s what I ended up with to start with:

I know, it’s super small, but that’s the resolution that Gameboys had! A teensy tiny 160×144, geez. I was going for a kind of Mayan theme with the maze-like motiff at the bottom. It was fun to try and make the maze vary enough to be interesting; I even put a  skull in there for anyone that looks closely.

Anyway, once I’d gotten the basic background done, I imported all the resources from my platformer engine project and animated a quick little player sprite in idle, running, jumping, and falling modes. With such a small resolution (8×8 to match the size I wanted) it was actually way easier to get all the animations done and dusted. Once that was done, I put together very basic spearthrower and spear sprites. And bam! Artwork done (for the moment, but we’ll get to that).

Gameplay:

So my basic idea for gameplay was just literally a single-screen arena where you dodge spears and try and get a high score. Easy! So I went through and created a control object with a state machine (of course) that would randomly choose a mode of attack and trigger that set of spears being made:

statemachine

I initially planned to have an ALL state where all the spearthrowers would fire at the same time, but I found that to be just a little bit too hard for players to get around. An example of the way I did the single random spear throw is shown below; just a simple randomiser feeding into a switch. switchYou’ll notice that with each switch I also move the emitter. This is how I used just one emitter to do all the sounds for the game. Wherever there was a spear object being created, I would also move the emitter to the same location and play a sound from it. With the in-built 3d audio functions, all I needed to do was tie the listener to the play object and boom! Instant stereo audio. Here’s a .gif of the spears doing their thing at that stage:

Level design:

You’re probably thinking, “It’s a single arena-style level, what possible level design issues might you have run into?”. Well I’m here to tell you that level design and getting people to playtest your game is essential if you want even a tiny little idea like this one to work. Initially I had every platform existing as a bouncing platform, i.e. you would get a little bounce boost off it if you landed on it from above. The feedback from the playtesters (James and Tim, thanks!) told me this was way too hard and a little janky.

0317--fuckingspearchuckers--no-incentive

So I changed it up and put static platforms. Oh, and here’s me cheating at my own game after I discovered I hadn’t exactly placed the platforms quite right:

0317--fuckingspearchuckers--cheating

Having done that though, I needed to make sure that the player even had the incentive to jump up on them. Because if you’re playing to get the highest score, at this stage of the game’s development, the most optimum strategy was to just stay on the lowest level and jump over the spears there. So to get the player moving around I employed both a carrot and a stick. The stick was to have the spear’s lines mean that you got hit if you stayed on the ground, and also at every platform bar one, which I’ll go into later. The carrot was to put a regularly spawning mask at the top of the screen that could only be reached by a leap of faith from the top platform.

leapgif

Every spear jump was worth 1 point, so I made the mask worth 20 points to incentivise it even more. I also didn’t tie the mask score to the increase in spear throwing frequency.

Oh! That was something I forgot to mention, the higher your score gets, the higher the spear frequency and so the faster the beat. It caps at a certain level so it doesn’t become impossible. I decided I didn’t need to incentivise the player from moving from that top platform because the random nature of the spears meant that more often than not you needed to jump down anyway. But I did put in a platform that would fade and cause you to fall through in the second tier, so that players would have to make a quick decision there. I think it all works pretty good to get players to move around a lot!

After that it was just banging a quick and dirty high score system in, and wrapping it up in HTML5 for y’all to play.

Concluding thoughts:

  • Smaller resolutions and limited palettes are kind of fun to work in, and they mean you’re spending way less time on art assets because you are so limited.
  • Audio can make a big difference to a game!
  • Playtesting is important, even with such a small game. This is a way more enjoyable game thanks to getting rid of the bouncy platforms.
  • I really want to play around with more level design in the future. I like trying to second guess how players will approach a problem.

Thanks for reading!