Lessons From My First Gamejam

ZakG — Tue, 20 Feb 2024 20:10:55 +0000

Hi! I'm Zak. This is my first blog post. About my first Gamejam. And the first game I've made since university.

Me

I'm a software engineer that studied computer science with a game development concentration, like a bunch of people. I'm also recently unemployed and decided to take a swing at building a portfolio to better pursue game development positions. Enter: Brackeys Game Jam.

The Jam

The theme was "What's Behind That Door?". I was honestly hoping for "Web", but hey, what can you do? It was voted on by the participants and who am I to disagree with the most holy of democratic processes.

The Lessons

Design and Plan Early

Okay, yeah. This one is kind of a gimme. But seriously, DESIGN AND PLAN EARLY. I didn't really have a concrete idea of the game I was going to make before my hands hit the keys. That was my first mistake, and one that I really shouldn't have made after working for 6 years in software consulting. The result of this was that I ended up not really incorporating the theme as much as I wanted and I didn't have any idea of what I would minimally accept as "done".

I would recommend planning out in more detail than you'd expect what you consider to be a complete game. I'm talking things like sound, credits, UI, all of it. Establish your "Levels of Success": without them you won't really know where you're going and you don't have any way of knowing that you've arrived when you get there. Trust me, it'll save you time re-evaluating mid-development and keep you from spending the limited time allotted in a jam working on things that aren't really that important.

Know Your Tools (optional)

I built my game using Unreal Engine 5.3.2. It was my first honest attempt at building anything in Unreal Engine so I was doing a lot of learning over the course of 7 days. Personally, that's why I chose it. Having a concrete goal like that is motivating to me and helps me keep after it with a new tool. That may be true for you, too, and that's great! If you're shooting for polish and prizes however, I'd recommend using something you're more familiar with to avoid sinking time into doing things the "wrong" way or having to look up how to do things in your engine/framework of choice.

Build Often, Test Often

Familiarize yourself with the building and packaging process of your chosen framework early in the process. If you can, get an end-to-end build going early. This means making sure you know how to work the editor, make a debug build, make a release build, upload it to the destination, and then download/play it to verify functionality. Do this with the simplest level you can construct with your given toolkit.

Why do I recommend this? Because I didn't do it, of course. I did almost all of my testing in-editor and with debug builds, which resulted in me spending several hours troubleshooting strange errors I was getting while trying to package my game for submission. About 5 hours before I would no longer be at my computer to submit it before the deadline. Don't be like me. Give yourself room to breathe.

Conclusion

I had a blast and learned a ton. If you're interested at all in game development and have the time and energy, I'd highly recommend participating in any of the numerous jams hosted on Itch.io.

Automating Your Node Workflow with Gulp and Nodemon

ZakG — Mon, 20 Feb 2017 16:47:46 +0000

Disclaimer

Allow me to preface this article by saying that I am a newcomer to web development, and most of the veterans here will likely already know these skills. However, these are things that I found incredibly useful when I set out to make a professional website for myself, and hopefully any other newbies looking for help will find this information useful as well.

What is this "gulp" of which you speak?

According to their website, "gulp is a toolkit for automating painful or time-consuming tasks in your development workflow, so you can stop messing around and build something." In fewer words, gulp is a task runner that can save you boatloads of time and stress.

Okay, why do I need it?

Developing a modern website is no simple task. Most projects use SASS or LESS, Bower, Browserify, maybe a compiler if you're writing in CoffeeScript or Typescript, and the list goes on. It's a giant pain to have to constantly compile your stylesheets or javascript after each tiny change. Sure, some of these technologies offer some sort of "watch" functionality, but you'll still have several of those running at the same time. Gulp allows you to bring all of these things into one task, recompiling any styles or scripts that you may have every time you make a change.

Alrighty, I'm sold. Now how do I do it?

EDIT: As Nick Moreton pointed out in the comments, Bulp is a package that offers an easily configurable boilerplate gulpfile to help you get started. If you'd rather not write your tasks completely from scratch, go check it out.

First off, you'll need to install gulp. This can be done via npm, like most things nowadays.

npm install gulp-cli -g

All of your gulp tasks are stored in what is known as a gulpfile, usually titled gulpfile.js. The following is an example of a gulp task that compiles scss styles. (Example source found here. Comments added by me.)

'use strict';

var gulp = require('gulp');

//This is another package to install via npm
var sass = require('gulp-sass'); 

gulp.task('sass', function(){
    // '**/*.scss' recursively searches the specified directory for any files
    // with the .scss file extension.
    return gulp.src('./sass/**/*.scss')
        .pipe(sass().on('error', sass.logError)) //define error behavior
        .pipe(gulp.dest('./css'));               //specify compile destination
});

//This task watches for any changes to .scss files in the directory and
// runs the 'sass' task defined above whenever a change is detected.
gulp.task('sass:watch', function(){
    gulp.watch('./sass/**/*.scss', ['sass']);
});

There are a plethora of "gulp-whatever" packages that will allow you to automate almost any task. Below is an example of a set of tasks that automate the development of a webpage written with coffeescript.

var gulp = require('gulp');
var sass = require('gulp-sass');
var coffee = require('gulp-coffee');

gulp.task('sass', function(){
    return gulp.src('./styles/**/*.scss')
        .pipe(sass().on('error', sass.logError))
        .pipe(gulp.dest('./css'));
});

gulp.task('sass-dev', function(){
    gulp.watch('./styles/**/*.scss', ['sass']);
});

gulp.task('coffee', function(){
    return gulp.src('./app/**/*.coffee')
        .pipe(coffee({bare: true}))
        .pipe(gulp.dest('./js'));
});

gulp.task('coffee-dev', function(){
    gulp.watch('./app/**/*.coffee', ['coffee']);
});

// This means that the when 'gulp dev' is run, it runs the
// sass-dev and coffee-dev tasks
gulp.task('dev', ['sass-dev', 'coffee-dev']);

With this gulpfile, simply running gulp dev starts watches on all of our styles and coffeescript files. Any changes trigger an automatic recompile, and we don't have to do anything.

But wait, won't we need to restart our node app whenever we change backend code?

Yes, but this is where nodemon comes into play. To use it, first install it via npm.

npm install -g nodemon

Once this is done, we simply start our app with nodemon instead of with node, like so:

nodemon index.js

Nodemon will now monitor our source code, and anytime it sees a change it will automatically restart our app. Pretty sweet, right? Now all we have to do is refresh the webpage to see changes in our front end or our backend.

DEV Community: ZakG