DEV Community: Don Juan Javier

Create a Unity to itch.io Deployment Pipeline Using Butler & Bash Scripting

Don Juan Javier — Sat, 22 Jan 2022 21:53:53 +0000

I recently uploaded my first game to itch.io, and discovered that there is a nifty tool called Butler that allows uploading a build from the command line.

However, I wanted to streamline the build -> zip -> upload steps, so here's what I did:

1: Create WebGL build in Unity

First, I followed the official Unity docs for publishing WebGL games.

In the Unity Build Settings, I selected a WebGL build and made sure to turn compression off in Player Settings (Project Settings -> Player), after running into an issue with the build not working in the browser.

Finally, I made sure all of my scenes were checked that I wanted to include, and selected Build (I also always use the Clean Build option). I used the default build path of ./Build.

2: (Optional) add docker-compose to test WebGL build

After the build completed, I wanted to test things out before uploading to itch.io. I followed this guide to set up my own docker-compose file to run things locally.

BTW, getting Docker to work on a Windows machine took some effort... I had to enable CPU virtualization in my BIOS settings. I'm a BIOS noob, so that was a little scary, but I finally got things working, and docker-compose up worked like a charm.

3: Adding `deploy.sh` script

I wanted my script to automate two things:

Packaging my build into a .zip file
Uploading to itch.io via Butler

My Windows machine uses 7-Zip for archive creation/extraction, so I had to add 7-Zip to my Windows path. (Alternatively, I could have used the zip command, but it wasn't working for me - I didn't feel like going through the hassle of installing GoW just to use zip).

Next, I needed to install Butler and add it to my Windows path. I just added a directory called C:\Bin and placed the downloaded Butler folder there, and set the Windows path to C:\Bin\Butler.

After all was said and done, I could run the following commands:

# zip file to archive
ZIPFILE="/path/to/zipfile-to-create"
7z a $ZIPFILE "/path/to/Build" > NUL

(Note, the > NUL above simply silences the output from the zip command; also NUL would be /dev/null on Mac/Linux).

# upload to itch.io
USERNAME="my-itch-io-username"
GAME="my-awesome-game"
CHANNEL="html"
VERSION=1.0.0
butler push $ZIPFILE "${USERNAME}/${GAME}:${CHANNEL}" --userversion $VERSION

Viola! Everything worked like a charm, and my newly-uploaded .zip file now showed up in my edit game page.

Conclusion

Now that this script is in place, deploying new releases for my game is ridiculously easy. Hopefully this guide can help you streamline your game release cycle as well.

Here's my full deploy.sh script:

Config/deploy.sh

#!/bin/bash

USERNAME="my-itch-io-username"
GAME="my-awesome-game"
CHANNEL="html"

#
# COLORS
# see: https://stackoverflow.com/questions/5947742/how-to-change-the-output-color-of-echo-in-linux
#
NC='\033[0m'              # No Color
BLACK='\033[0;30m'        # Black
RED='\033[0;31m'          # Red
GREEN='\033[0;32m'        # Green
YELLOW='\033[0;33m'       # Yellow
BLUE='\033[0;34m'         # Blue
PURPLE='\033[0;35m'       # Purple
CYAN='\033[0;36m'         # Cyan
WHITE='\033[0;37m'        # White
GREY='\033[1;30m'         # Grey

#
# UTILS
#
log() {
  echo -e "${GREY}${1}${NC}"
}
info() {
  echo -e "${CYAN}${1}${NC}"
}
success() {
  echo -e "${GREEN}✓ ${1}${NC}"
}
warn() {
  echo -e "${YELLOW}${1}${NC}"
}
error() {
  echo -e "${RED}${1}${NC}"
}
prompt() {
  read -p "$1 " -n 1 -r
  echo    # (optional) move to a new line
  if [[ ! $REPLY =~ ^[Yy]$ ]]
  then
      warn "user cancelled."
      exit 1
  fi
}
assertFileExists() {
  if [ ! -f "$1" ]; then
      error "$1 does not exist."
      exit 1
  fi
}
assertDirExists() {
  if [ ! -d "$1" ]; then
      error "$1 does not exist."
      exit 1
  fi
}

#
# GET VERSION
#
VERSION=$(cat version.json \
  | grep version \
  | head -1 \
  | awk -F: '{ print $2 }' \
  | sed 's/[",]//g' \
  | tr -d '[[:space:]]')
SAFE_VERSION="${VERSION//./$'-'}"

#
# SCRIPT
#

info "WELCOME TO THE UNITY DEPLOYMENT SCRIPT!"
info "About to push version ${RED}${VERSION}${CYAN} - proceed?"
prompt "(y/n)"

assertFileExists "../Build/index.html"
mkdir -p "../Archives"
ZIPFILE="../Archives/build-${SAFE_VERSION}.zip"

log "creating zip archive for ${ZIPFILE}..."

# zip
7z a $ZIPFILE "../Build" > NUL

log "deploying to itch.io..."

# push to itch.io
butler push $ZIPFILE "${USERNAME}/${GAME}:${CHANNEL}" --userversion $VERSION

success "All done!"

I also added a simple version file containing version info for my game to make it easy to update without needing to alter my script:

Config/version.json

{
  "version": "1.0.0"
}

Cover Photo by Hello Lightbulb on Unsplash

How I Learned to Code

Don Juan Javier — Sat, 08 Jan 2022 20:48:59 +0000

I've been a software developer for over 8 years. I feel very confident and comfortable in Javascript ecosystems, especially ReactJS. But I've also worked in many more frameworks and languages, including Python, Ruby on Rails, C++, C#, PHP, WordPress, and straight up HTML and CSS. I've deployed and administrated servers using Heroku, Digital Ocean, and AWS. I've created and maintained loads of websites over the years.

However in many ways I feel I'm just scratching the surface. The more I learn about software, the more I learn there is to learn.

But today I want to press rewind and reflect on some of the things that helped me get to where I am today, and hopefully provide some useful tips if you're trying to get a job as a developer.

Chapter 1: Curiosity of a Kid

I've always loved tinkering and messing with computers. Growing up, I loved making computers do all sorts of things, like pranking my uncle so that fart noises played when minimizing a window, to creating a simple word-guessing game in Q-Basic, to programming Snake in Visual Basic, to coding a graphical Russian Roulette game on the TI-86 calculator.

I majored in computer science in Community College, where I mainly learned Object Oriented programming in Java.

Then, I switched my focus to study music. I'm a pianist, and music is still a strong passion of mine. But ultimately, I missed the thrill of making the computer respond to my whims.

My friend Ricardo bought a book on HTML and CSS and started learning how to do web development. I followed in a similar vein, and made my first god-awful website to showcase my music. I still have the original codebase, and it's... pretty bad.

Chapter 2: The Labs - early days

Eric, Ricardo, Chiedo (Founder), and Don - developers at Chiedo Labs

Having made my own website, I approached my friend who had just started his own web development business, and asked matter-of-factly, "what do I need to do to work for you?" He pointed me towards a load of YouTube tutorials on HTML, CSS, Javascript, JQuery, PHP, and WordPress. So I got to work learning.

While the YouTube videos were helpful, I wanted to digest the information a little better. So I started going through tutorials on CodeCademy, which I highly, highly recommend. It's such an awesome resource. On CodeCademy, I learned JavaScript and PHP mainly. The knowledge I gained was rudimentary and pretty basic, but it gave me enough to get hired and start working on actual websites using more than static HTML/CSS.

I felt I had a leg up, though, having had CS background, albeit a 2-year degree. But I had a strong grasp on basic data structures and all of the fundamentals of programming, such as variables, loops, conditionals, and functions. I simply learned how these same principles applied to web development.

My first projects were small jobs, like tweaking CSS on websites, slightly altering the order of items on a product catalogue, or changing website copy. Pretty basic stuff. I remember very clearly my first noob mistake of not making a CSS style specific enough, and inadvertendly messed up the styling on a different page on the website. OOPS.

I quickly learned some of the nuances of CSS like z-index and relative/absolute positioning, and the tenets of fluid responsive design, avoiding explicit widths, etc. I started to form opinions for how I liked to structure my CSS classes and file structure.

We developed custom WordPress themes, and this was my first foray into serious full-stack development. WordPress incorporated everything: front-end presentation, a database, a server/controller of sorts, scripting, HTTP endpoints, and my introduction to the painful/exciting world of AJAX. (AJAX was how you got things to update dynamically on a website without refreshing the page before the days of React and the virtual DOM).

I owe a lot of my webdev experience to WordPress, and the many headaches that ensued trying to troubleshoot and debug issues. Because it's a full-stack framework, a bug could be in the GUI content, or the PHP code itself, or one of the many plugins that inevitably accumulate in a WordPress website. As a result, I got really good at problem solving and developed an intuition for debugging. I learned how to decipher error messages and what terms to search for when Googling the problem. As painful as it was, debugging WordPress made me the developer I am today.

Chapter 3: Ahead of the Curve

Don and Ricardo hard at work (making dank memes, and some programming too)

As a small start-up, we were really nimble and trying to keep our thumb on the pulse of the tech industry to see where things were headed. We developed apps in lots of different frameworks, like Drupal, Flask, Django, and Ruby on Rails. We were always trying to find the sweet spot of a framework to develop in, and also finding excuses to try out that shiny new technology.

We landed on Ruby on Rails as a solid architecture for more complex and nuanced apps, where WordPress just didn't cut it anymore. I tried my hand at learning Ruby on Rails, but didn't get very far as I simply didn't care for the "magic" of the framework - how it abstracted functionality away from you.

But before too long, our founder discovered React, a new framework that boasted a Virtual DOM, unidirectional data flow, and the concept of components, and everything changed for me. React fit my brain like a glove, and I found my go-to presentation framework.

We got into React in the early days, when it was still in beta. We had to hand-roll everything ourselves using Webpack and Babel to transpile the code into usuable Javascript. Around the same time, ES6 also came out, and we felt we were living in the glory days of the web. Indeed we were. A lot of us went to the NationJS conference in 2015 and soaked in the new terminology - spread operators, destructuring, const and let, JSX, etc. We marvelled at the idea of EverythingJS, where the entire stack could be written using a single language for ease of cross-development for the entire team. This felt like a new frontier for the web.

Quickly we landed on our preferred stack: Ruby on Rails on the back end, and React on the front-end. This setup seemed to work really well. I learned about REST architecture and HTTP methods, and wrapped my brain around the nuances of Redux in order to manage my app's complex state. "Separation of concerns" became my mantra.

Chapter 4: Mistakes Were Made

Every software engineer that you talk to, at least any good one, should be able to tell you a mistake they made, or some design that, looking back, they would definitely have done differently.

Because of my success with React and how comfortable I was getting with the nuances of JavaScript, I pushed for my company to develop our own server-side framework using NodeJS. It was highly ambitious, but I had worked on several apps by that point and had a pretty good handle on the major components that needed to be implemented. Data models, controllers, JSON responses, error handling; those things couldn't be that hard, right? So we set off to build our own framework. We added user authentication, mailers, and PDF generation. We added ElasticSearch for fulltext fuzzy search. We added a CLI to help build out some of the burdensome boilerplate. We had documentation specifying how the app's filesystem was to be structured. Yes, it was an opinionated framework.

But it took so much damn time to build. And we were constantly working under a budget. And our clients expected deliverables within agreed-upon timelines. But the codebase was ours, and we could add new features to it as time passed. However, we were also laden with the technical debt of maintaining this monstrosity. The burden of that task fell on me, since I was the one who principally designed and coded the architecture. However, a codebase that only one person really understands is a surefire way to impede a team's productivity and sap its morale.

Looking back, a much better decision would have been to use an existing framework like Ruby on Rails, where the non-critical architectural decisions were already made. It might have been annoying (at least to me), but it would have greatly reduced the amount of work that we had to do. Models, controllers, error handling, mailers, authentication - all of that came (mostly) for free, out of the box.

Now, building that custom NodeJS framework is an experience that I wouldn't trade even if I had the chance. I learned so much about architecture and system design, as well as the horrors of circular dependencies, concepts and lessons learned that I use to this day. I even look back on those days of crunching into late hours of the night with a sort of fondness. Even if we were over-engineering our own solution, this was something that we were doing for ourselves. We had a young pride and foolish tenacity in those days. We got here, myself and my teammates, by teaching ourselves how to code. It was a long and arduous journey, full of pitfalls along the way (and lots of curse words), but that moment when things finally work is a thrill that never seems to lose its edge. It never gets old. The lightbulb moment, when you finally figure out a tough problem, when the tests finally pass, or the UI actually animates how you intend - these small wins are the things I live for, and why I wanted to become a software dev in the first place.

Chapter 5: Epilogue

Chiedo Labs - Obligatory Business Stock Photo

So that's how I learned to code, or more generally, how I learned to become a professional problem solver. It really was just taking one day and one problem at a time. After solving loads of difficult problems, you don't feel so afraid when a new one comes. You know from experience that with time, you'll figure this one out, too. Because that's how it always works. Either you'll come across a solution on Stack Overflow, or you'll check your premises, or you'll think of a way to bypass the problem entirely. But one way or another, you will be the badass dev who figures things out. This job keeps you sharp and nimble; it keeps you on your toes for sure.

My journey does not end here; I'm a lifelong learner and want to keep growing, especially in the area of game dev. But how about you? Are you interested in getting into software development? My advice would be to learn everywhere you can: YouTube tutorials, Codecademy, Scrimba, Egghead.io, Udemy, whatever you think you need to learn to code, do it. But even more important: apply it. Get a job where you can start applying these skills to real-life scenarios. I know the market is super saturated for junior developers. It's a tough, competitive environment. In the meantime, you can apply your skills by working on coding projects, and building up a portfolio of demos. Create a GitHub profile where you can show off your accomplishments. But lastly, foster a love for learning. Stay curious. Never lose the love for that thrill when your code makes the computer bow to your will. It feels like raw power, and it's a rush of adrenaline.

Go out there, and code the universe. Peace!

You (probably) don't need that useState + useEffect

Don Juan Javier — Mon, 01 Nov 2021 17:06:17 +0000

The useState and useEffect hooks were a godsend for the React community. However, like any tool, these can easily be abused.

Here's one an example of one misuse I've seen a lot in my tenure as a software dev:

const MyAwesomeComponent = () => {
  const [loading, setLoading] = useState(true);
  const [data, setData] = useState();
  // ---- PROBLEMATIC HOOKS: ----
  const [items, setItems] = useState([]);
  const [itemsLength, setItemsLength] = useState(0);

  useEffect(() => {
    someAsyncApiCall().then(res => {
      setData(res.data);
      setLoading(false);
    });
  }, [setData, setLoading]);

  // ---- UNNECESSARY USAGE OF HOOKS: ----
  // anytime data changes, update the items & the itemsLength
  useEffect(() => {
    setItems(data.items);
    setItemsLength(data.items.length || 0);
  }, [data, setItems, setItemsLength]);

  return (
    // ...JSX
  );
};

The problem with the above use case is that we are keeping track of some redundant state, specifically items and itemsLength. These pieces of data can instead be derived functionally from data.

A Better Way:

Any data that can be derived from other data can be abstracted and re-written using pure functions.

This is actually pretty simple to pull off - here is one example:

const getItems = (data) => {
  // I always like to protect against bad/unexpected data
  if (!data || !data.items) return [];

  return data.items;
};

const getItemsLength = (data) => {
  return getItems(data).length;
};

Then, our component is simplified to the following:

const MyAwesomeComponent = () => {
  const [loading, setLoading] = useState(true);
  const [data, setData] = useState();

  // DERIVED DATA - no need to keep track using state:
  const items = getItems(data);
  const itemsLength = getItemsLength(data);

  useEffect(() => {
    someAsyncApiCall().then(res => {
      setData(res.data);
      setLoading(false);
    });
  }, [setData, setLoading]);

  return (
    // ...JSX
  );
};

Takeaways

The cool thing about this pattern is that getItems and getItemsLength are very easy to write unit tests for, as the output will always be the same for a given input.

Perhaps the above example was a little contrived, but this is definitely a pattern I have seen in a lot of codebases over the years.

As apps scale, it's important to reduce complexity wherever we can in order to ward off technical debt.

tl;dr:

Using useState and useEffect hooks is often unavoidable, but if you can, abstract out any data that can be derived from other data using pure functions. The benefits can have huge payoffs down the road.

Banner Photo by Lautaro Andreani on Unsplash