Oooh Shiny Buttons

In our last weekly meeting, our group made a decision about the display size of our game, choosing to aim for the commonly used “widescreen” 16:9 ratio.  I created a new version of the map that is 1280 pixels wide and 704 pixels high.  Sharp-eyed readers may notice that the height should be 720px for a true 16:9 ratio, but since 720 can’t be divided evenly by 32px tiles, we thought 704px would be close enough.

A new user interface

I added a shiny new UI to the map this week, taking up a vertical strip of space on the right side of the screen.  It looked absolutely terrible in the beginning because I had made the buttons as clickable text objects. Then I stumbled on this invaluable resource that provides thousands of standardized, editable game icons for free.  I picked out four and implemented them as health and money indicators, plus two kinds of “buy turret” buttons.

Latest version of map 1 with a user interface!

Now when you run the game, you can click on those two blue icons to “buy a turret” which will decrease the player’s money by the advertised amount. They also take on a grey tint when the pointer hovers over them.

Small additions to the back-end

My teammate Cliff wrote the skeleton code to set up Phaser scenes for our game. I added some class variables to keep track of things like player hit points, money, and turret prices, plus a couple functions to update these values.

It’s important to keep our code as modular as possible so that we can easily make changes and incorporate new features. I wrote a new create-button function with this in mind.

Add a button by calling createSpriteButton.
Just supply the x and y coordinates, the name of the preloaded asset (in this case the .png of a button), and whatever function you want to call when the pointer clicks down.

All buttons created with this function will have the same hover-over action. Later, I think I want to modify this so that on “pointerdown”, the user can drag a turret to where the want to place it. Then on “pointerup”, if the mouse is hovering over an available map tile, it will place the turret and withdraw money. Otherwise, it will do nothing.

Now to bring it all together

I feel really optimistic about our game at this point.  Everyone has been making great progress and we’re almost ready to merge our separate parts into one cohesive prototype. Next week we’ll be integrating, working out the bugs, and preparing a basic working demo.

Now we can start coding

There are lots of helpful tutorials and example files for Phaser 3.  Since I had never worked with this game framework before, the first thing I wanted to do was to see if I could get one of the example games working on my local computer.  But, these files are not quite plug-and-play.  I needed to make a web server first.

By remembering what I learned from my web development class, I wrote a simple server.js file like so:

server.js image
A simple web server using Node.js and Express

Then I added the example files, made double sure that the file paths pointed to the correct locations, ran the server with Node.js, and voila!  It worked.  I had seen the inner workings of an example game and proved that I had everything I needed to run it locally.  I could now move on to the specifics of our own game.

First try at map-making

One of my main tasks in the group is to create the maps for each level of the game.  At this point, we still hadn’t decided on a specific art style.  So, I browsed OpenGameArt for the best looking tile set and settled on this one, which is from an open-source art competition called the Liberated Pixel Cup.

Terrain tile set created for the LPC. Attribution found here.

I imported the tile set into Tiled (a free open-source map editor with a great tutorial series here) and created a draft of the first map.

My first draft of the first level of our tower defense game.

In this level, enemies march in from the right towards the tower, which will sit in the dirt clearing on the left side.  They can choose either the high road or low road, but they must stay on the path.  Players can place turrets in any open field.  I left some empty space on the right side so that UI elements can appear there in a vertical strip.  A couple small elements like health and money indicators can sit in the top-left corner too.

Some things to figure out

Before I go any further with this map, I’ll need to discuss some things with my group.  One big concern is figuring out the right resolution and aspect ratio.  I had to start somewhere to get some practice with the Tiled software, so for this map I chose the following dimensions:

  • Tile size: 32×32 pixels
  • Map size: 800×608 pixels or 25×19 tiles
  • Aspect ratio: roughly 4:3

It isn’t too difficult to change the map at this point, but it’ll be harder once things like collision boundaries are coded in.  We’ll also have to agree on where exactly UI elements will appear, so that enemies and turrets don’t get lost behind a button.

Welcome to Game Dev

The results are in. I’ll be working on the HTML5 tower defense game for my capstone project! This was my first choice out of five project proposals, so I’m very excited to get started.

The Project

This will be a single-player game wherein the player must defend their “towers” against waves of enemy units. There will be at least three different levels with at least 10 enemy waves per level. Enemies will come in at least three different types. Defeated enemies will provide some benefit to the player (like coins or energy) that they can use to build more towers. Lastly, each level must be challenging (a brand-new player shouldn’t be able to beat it), but winnable within 10 minutes. More details found here.

The Team

There are three other students in the team: Cliff, Nam, and Abraham. We’ve already hammered out our team standards document, which determines stuff like how we’ll communicate (Discord chat and weekly voice calls), work standards, conflict resolution, etc. This week we’ll be focusing on creating our project plan.

The Plan

Our instructor posted an impressive example plan created by students in a past term. It laid out almost all aspects of their game design and a week-by-week task list for each team member. I hope we can achieve a similar level of detail in our plan by next Monday.

This is what I have in mind so far (final decisions pending team discussion). We know our game will run on a browser, so we’ll be programming it like a webapp with Node.js on the OSU engineering servers. We’ll use Phaser 3 as our game framework. Maps will be created using Tiled, then exported as JSON files. We can use open-source art assets from We can even make some custom art assets if needed (I’ve been drawing, painting, and making digital art since I was a kid).

We haven’t decided on a theme yet. Right now, I think everyone is focused more on the game mechanics and how we will share the workload. It would be great if we could figure this out later after we’ve looked at the available art assets. Fantasy and sci-fi settings are popular. We could go that route or try something entirely new. But we may need to make that decision soon so that we can include it in the project plan.

We’ll have all these details hammered out (and more) by next week.

From Collecting Bugs to Computer Bugs

Hello and welcome!  My name is Casey Cheek and I’ve created this blog to document my progress through Oregon State University’s computer science capstone project.

First, some context

I’m originally from Alaska which is where I got my first degree in biology.  Back then, I collected insects for a living. I’m quite good at identifying them too, so if you see a weird bug, send me a picture and I’ll tell you what it is!

I also used to do stream surveys for the Bureau of Land Management, which is how I was able to take cool pictures like this:

Stream survey
An especially beautiful stream survey

But after a certain point, I realized that the years were ticking by but I wasn’t making much money, had no job security, nor benefits.  I needed to try something different.

A fresh start in computer science

This degree program has been a fantastic experience so far.  I find that learning to program has rewired my brain so that I can think about problems in new ways.  I’ve always enjoyed scientific writing so I love that I can use those principles to write clean, modular, approachable code.  And I love understanding how all the technologies that we depend on everyday work.

Over the break between summer and fall term, I completed a five week internship at a patent and prototyping company.  There, I gained valuable experience both designing and coding the user interface for two separate products.  I think I really excelled at the UI stuff and hope I can continue doing that in future jobs.

Which brings us to now

I’ve just taken the “Choose Your Project” survey and am excitedly waiting for my project and team assignment.  Going into this class, I worried that I would be stuck with an uninteresting project, but the OSU project page is full of very cool ideas. As my top five choices, I picked one citizen science app and four different games.  

I know I have the skills to make an excellent citizen science app, because I’ve worked on projects before that try to get the general public involved in active science.  With animal monitoring for example, it can be too much to ask the public to identify something to species without extensive training.  Instead, it’s better to ask them to classify information in broad groups, use quantitative measurements (like, “how many bird calls did you hear in ten minutes?”), or take photographs and send them out to be identified by experts.  This way, everyday people can get involved with minimal training and collect valuable, reliable data.

Tower defense game proposal
One of the four game proposals that I’d like to work on from

Choosing the game proposals felt almost like a guilty pleasure.  It’s just… I would really love to learn how to make games.  I know this class isn’t so much about teaching a specific technique and more about providing support, but I think I need the structure and pressure of a class to learn this stuff rather than tackling it all on my own.  It does seem a bit cliche to start getting into computer science and then immediately jump into “I want to make games for a living!” Sure, it makes sense.  Playing a video game is often the first time a person associates a computer with pleasure, whereas doing “work” on a computer (writing an essay, doing your taxes, filling out spreadsheets) is associated with discomfort.  Also there are probably more important areas to apply a CS degree (healthcare, public infrastructure, scientific software) but you know the video game industry could really use more female voices and… maybe I could help?

For now it’s out of my hands.  In the next post, I’ll have heard back from the instructors, so I can tell you all about my new project and team!