Download the Mac game and source code here!

My first Global Game Jam went without a hitch! Completing a game within 48 hours is a feat on its own. What if it's with people you just met in the room? Oh. Also, what if the game should fit a theme that's revealed minutes before you find your team? We did all of that!

The internet, and even the official GGJ website, has many articles about becoming a jammer, so I won't go into that. Instead, I'm briefly offering my perspective as a seasoned engineer on my first time as a jammer.

The GGJ

George Mason University gave us a grand start to the festivities with this theme reveal video! At this point in the night, I was concerned about finding a team to help me make a "Bubble" themed game. Is it standard practice at game jams to put color-coded stickers, i.e. red for programmers, on your name tag? That helped me spot artists and programmers. A complete surprise to me was that the people who I sat next to all became my teammates after the theme reveal. We exchanged game ideas and it just worked out that way.

The first night went by faster than I imagined. Most of us simply got the tools needed for the rest of the game jam and went home. The next day was an exhilarating whirlwind of collaboration, progress, and coffee trips. The last day easily won as the most stressful day of the event, but it was worth it. We had a finished, polished game! The work that could be done after submission was correctly delegated into the "Wish List" column.

On AI

Something I quickly noticed during development was how much my teammates got done using AI-generated code. Now, I have been critical of AI in the past, mostly due to how AI "creativity" is trained on images it finds on the internet, but I've been lax on generated code because it's easier for AI to show attribution for text. I have used AI for some professional work but it's safe to say that I'm a late adopter.

That being said, AI and game jams go together like peanut butter and jelly. It's the right kind of code for a 2-day project with a presentation to make. We used AI to allow us to make a larger game than what we might have attempted without it. Yes, some game jams don't allow it, but the GGJ does. My takeaway is to learn to freely use AI to help scaffold ideas. For game jams the scaffolding is the final product, so let the AI rip.

Post-GGJ: "Fixing" the bomb

In Bubble Battle's gameplay, a known issue with the bomb happens when you fire it while facing towards the right. The bomb should explode but it will look like it implodes. Huh? While this looks cool it wasn't what the team had expected.

I tackled this problem by simplifying it to gain clarity. I like to think of this as if I'm running a binary search for the issue. I find code that, when removed, doesn't affect the problem I'm seeing and by repeating that process eventually all that's left is problematic code.

In this issue, I noticed that the bomb's projectiles were inheriting unnecessary transform details from the parent like scale and rotation. There has to be a nice way to say this, but I split the parent-child relationship. After changing that the explosions stayed consistent no matter which way the player faces.

GameObject projectile = new GameObject("Projectile");

// From this
projectile.transform.SetParent(transform);
projectile.transform.localPosition = new Vector3(xAngle * _radius, yAngle * _radius, 0);

// To this
projectile.transform.position = new Vector3(
    xAngle * _radius + transform.position.x,
    yAngle * _radius + transform.position.y,
    0
);

The ideal version

I could stop here but I wanted to know how the twisting effect worked. During the game jam I assumed it was something in Unity's physics engine affecting the velocity. Here's the effect:

Aha, now I see that the projectiles start at an angle so that they move along the edges of the bomb. Slowing down the effect made that easy to spot. Here's the code that sets those angles:

/*   
 * Rotate the projectile using Atan2 to get the angle between the   
 * projectile and the center of the circle  
 */
float angleOffset = (float) Math.PI/4;
float angleInDegrees = (Mathf.Atan2(yAngle, xAngle) + angleOffset) * Mathf.Rad2Deg;
projectile.transform.rotation = Quaternion.Euler(0, 0, angleInDegrees);

This was so close! At the game jam I tried a few different angleOffset angles and stopped at Math.PI/4 because it created that swirl effect. The angle that I intended to use was 90°, or Math.PI/2. Except that didn't look correct either:

If I flip this by 180°, i.e. set angleOffset to -90°, -Math.PI/2, things look better.

Now let's see how it looks in the game with 10 projectiles.

Future game jams

I enjoyed the passion that everyone brought to this event. My first game jam couldn't have gone better. I went into this blind, I didn't prepare, so I know I'll have goals for the next time I attend a jam. For now, I'm re-learning Unreal Engine and hope to try that out for a jam in the future. Until next time!

Walk through Philadelphia and learn about Philadelphia's street trees.

Try the TreeCity demo in your browser or browse the source code on GitHub.

About

This WebGL demo was made in Unity and uses Mapbox's Unity SDK. Before this demo, I had only read or heard about GIS and didn't understand it at a deeper level other than "it's about mapping." After Hurricane Harvey hit Texas, I started to learn more about how storm-based flooding becomes more prevalent with the mass removal of trees in urban areas. Out of curiosity I looked at street tree maps where I live, in Philadelphia, PA, to gauge how well gathered our data is.

Controls

• Arrow keys or W,A,S,D keys: Walk
• Left Mouse Button: View tree information on selection
• Esc key: Quit demo
• C key: Show controls

Instructions

At the center of the screen is your aiming reticle. Walk around the city to see trees. Click on a tree to learn what kind of tree is planted there.

This is a rendering of a 3D model I made. I gained deeper skills in Autodesk Maya while being challenged to model larger smooth surfaces. I was more experienced with starting a model using polygonal meshes, like a cube or a plane, but I didn't want to manage a dense mesh. I could have depended on subdivision previews to see smooth surfaces, but the result was always an approximation and sometimes looked lumpy. Instead, I started with NURBS because it lets you see a smooth surface immediately. Another benefit is using the NURBS to polygon command to create a polygonal mesh while still having NURBS curves for further tweaks.

Skills Used

• Used picture references within Maya while modeling using NURBS
• Converted NURBS surfaces into lower-res polygonal meshes
• Rendered with Mental Ray rendering using final gathering and HDR lighting
• Composited the wireframe with the beauty shot using Adobe Photoshop

See sfml-pong on Github.

This project served as C++11 practice for game development using SFML. I also wanted to learn better task management for open source projects. I kept track of tasks using Trello, but only at the start of development. It was fine for Pong since there weren't many tasks. I did get tired of manually moving tasks along category lanes, so I started searching for a way to track tasks with actual pull requests. That's how I found Waffle. It's a task manager that always shows a current task board without having to manually move tasks and it does this by linking to Github. What's there left to do? This demo would be a lot more fun with networked multiplayer gameplay.

Game Features

• Two paddles
• One ball
• Two score keepers
• Serving
• A win screen
• Restart the game

Tools Used

• Visual Studio 2015/2017
• Xcode 8.3.1
• Git + Github
• SFML 2.4.2
• Trello
• GifCam

Resources Used

• Programming: Principles and Practice Using C++ (2nd Edition)
• SFML 2.4 tutorials

This project dates from college. I worked with five other student game artists and developed all programming solutions using Unreal Engine 3, UnrealScript, Kismet, and Maya Embedded Language (MEL) scripting. I was the primary software engineer on the project.

Work Done

Technical Art

• Created identical shaders for Autodesk Maya's viewport and Unreal Engine 3
• Automated 3-point light rigs in Maya using MEL script
• Imported animation skeletons from Autodesk Maya into Unreal's editor

Gameplay

• Implemented hit detection using tracers for melee weapon fighting
• Setup a top-down fixed camera with smooth zooming
• Blended animations with Unreal's C++ API using available animation nodes
• Teleported an out-of-bounds player to their nearest node path
• Faded trees with occlusion using Kismet and Material Instance Constants
• Implemented health pickups

View source code on Github

I started this project to learn more about video game graphics and how it fits within the art pipeline. I thought the best way to discover these technical art intricacies would be to start in a 3D modeling program in which artists spend a lot of time in. I wrote an Autodesk Maya viewport shader from scratch. This shader would have to be capable of providing a good variety of choices for the artist. It would also have to be of at least PS3/360 generation. Its user interface would be kept as simple as possible, but not watered down.

A Big F- Shader

This shader, lovingly named "BFS 2500," clocks in with 68 distinct shading attributes. I wanted to retain current-gen standards and 68 of them is just the tip of the iceberg. Starting with foundational lighting, this shader provides two lighting models called Blinn and Phong. They’re named after the people who created them, Jim Blinn and Bui Tuong Phong. These aren’t the only models around. There’s also Ward anisotropy, Cook-Torrance, and Oren-Nayar to name a few. We don’t see these often in PS3 or Xbox 360 games because of their high mathematical overhead. In this post’s image, all of the materials use Phong lighting and are hooked up to one directional light and two point lights. They’re all also in linear color space, a gamma-correct format meant to portray real-life lighting more accurately. Lighting is less likely to look overblown within a linear color space, mid-tones are preserved, and color resolution appears more true to life.

Let's Add More

BFS 2500 also includes two different types of parallax mapping. Parallax is an ever-evolving term with numerous amounts of techniques floating around. I included basic offset mapping, seen in Unreal Engine 3, and also parallax occlusion mapping [1] which is used in CryEngine 3. Their parallax is superior to Unreal’s but it comes at a higher cost. This parallax technique uses iterative quality sampling which increases the offset quality at steeper angles. Offset mapping is faster but it can look the most distorted. The second sphere from the left uses a cube map to reflect an environment. A cube map, which is an environment unwrapped into six images, can be used for reflection, refraction, or even ambient lighting. The sphere furthest away is using only a pre-blurred cube map for ambient lighting. It’s the same cube map used on the second sphere. You can see that the top of the sphere is blue and as you go lower it turns brown. The method I used for blurring is called diffuse convolution. It’s an algorithm that scatters light from the cube map and averages them. This gives finer color results than normal blurring. The third sphere uses ideas from Team Fortress 2’s lighting scheme. They use a technique called diffuse warping [2], usually used with cel shading. However, Team Fortress' cel-shading doesn’t have hard edges because the texture they used was designed to keep a smooth edge. In the third sphere, the texture is comprised of five shades of color with no transitions.

An Interface For All

This mockup GUI to control BFS 2500 focuses on being informative, useful, and unobtrusive. I started with Autodesk Maya’s dark theme UI and kept its appeal because users are already used to it. The texture wells were created to make the UI feel more interactive. It partitions the shader’s features and lets users remember what part of the interface they need to use based on the texture well locations.

Research Papers

• [1] Parallax Occlusion Mapping
• [2] Illustrative Rendering in Team Fortress 2

In 2010, back in the early days of smartphones, a friend and I decided to create a different type of mobile game from what was currently available. Sushi Loco is a project we worked on from the ground up to make a side-scrolling platform game that uses the accelerometer.

It's Open Source

I'm excited to have my largest personal project written released as open source code on Github.

If you aren't inclined yet, are you here looking for a way to make a Katamari Damacy clone? Are you curious to see how linear impulses affect a circle shaped body in a Box2D physics world? Perhaps I've written similar features to things you've written and you'd like to see what conclusions I've made. Learn from this code base as I have from open source code.

Early Day Android Challenges

My friend and I didn't have many options to create a quick mobile game for Android. We both had Android phones with an accelerometer, something that was a desired feature then, and that made our hardware specific enough to begin with. We easily ruled out the Android NDK because we didn't have an existing C++ code base to port. More so, the debugging and build tools were absolutely minimal or non-existent. We couldn't work with blindfolds on! Eventually we well understood that Java was the only way forward. This is why Sushi Loco is written with LibGDX. There simply was no other framework at the time that was fast, worked with native platform tools, and had a strong community presence with active developers. Times have changed and so have the tools. If I were to make a new project today I'd pick LibGDX, Unity, and Unreal as a starting point and then evaluate for my needs. Even the Android NDK is a solid option for an existing code base in C++.

Skills Learned

• LibGDX game framework architecture
• Box2D physics for movement and hit detection
• Java on Android (back when public field access was a CPU optimization)
• Frustrum culling
• Texture atlas packing and retrieval
• Google Wave (RIP) to organize docs and collaborate with teammate

There could not have been a better way to start 2017 than by fixing this website. What started as a small task of self-hosting actually spiraled into many smaller projects. The additional time demands, along with a full-time job, culminated to breaking ivanarellano.com for nearly a year. And yet I've been able to script a way, a convenient one, to spin-up this website and a photography site. Enter Docker Compose.

Background

First, I have to explain how Docker can be a downside. I quickly started writing scripts after going through an enormous amount of setup steps for each container. All setup scripts can then be fired in a correct sequence from another script to re-create this website, like a reset.  For added convenience, I saved each script onto private Github gists, so that I could download and execute them in a terminal, with something like wget -qO - https://gist.github.com/ivanarellano/[gist_hash]/raw/start_website.sh | sudo bash.  Initializing containers this way isn't so bad at first, but there are too many pieces to maintain. There are also unforeseen issues. Containers can fail to restart after a server restart. The scripts needed constant documentation for every new solution. The tech debt was real and I started regretting containers.

How It Went Uphill With Docker Compose

Docker Compose is able to run multiple containers with only one file to describe dependencies. After installing it, you should be able to run docker-compose from your terminal. All of your container dependencies are then listed in a file named docker-compose.yaml. Here is a sample based on this website:

# Describes a Ghost blog with a host name, build variant, Mailgun info, and Let's Encrypt info 
my_blog:     
  image: ghost   
  volumes: - /my_path/blog:/var/lib/ghost
  environment:
    - VIRTUAL_HOST=example.com 
    - NODE_ENV=production
    - EMAIL_SERVICE=Mailgun
    - EMAIL_USER=postmaster@mg.example.com
    - EMAIL_PASSWORD=1234567890
    - LETSENCRYPT_HOST=example.com
    - LETSENCRYPT_EMAIL=user@example.com
  restart: always
  
# Describes a Koken photo gallery with a host name and Let's Encrypt info my_photo_gallery:
  image: koken/koken-lemp
  volumes:
    - /data/koken/www:/usr/share/nginx/www
    - /data/koken/mysql:/var/lib/mysql
  environment:
    - VIRTUAL_HOST=sub.example.com
    - LETSENCRYPT_HOST=sub.example.com
    - LETSENCRYPT_EMAIL=user@example.com

# Describes an Nginx web server that proxies to other container's nginx server nginx-proxy:
  image: jwilder/nginx-proxy
  ports:
    - \"##:##\"
    - \"##:##\"
  volumes:
    - /my_path/certs:/etc/nginx/certs:ro
    - /etc/nginx/vhost.d
    - /usr/share/nginx/html
    - /var/run/docker.sock:/tmp/docker.sock:ro
    - /my_path/vhost.d:/etc/nginx/vhost.d
  restart: always
  
# Describes a container that automatically creates Let's Encrypt certifications for each other container
letsencrypt:
  image: jrcs/letsencrypt-nginx-proxy-companion
  volumes:
    - /my_path/certs:/etc/nginx/certs:rw
    - /var/run/docker.sock:/var/run/docker.sock:ro
  volumes_from:
    - nginx-proxy
  restart: always

It's straightforward to run this script with docker-compose up. You can optionally add -d to run detached containers in the background. Containers can be stopped with docker-compose stop and upgraded with docker-compose pull.

The Website's Future

This website is going to be my grounds for ideas, thoughts, and stories. Though, less of the stories at the start. It's going to be about discovering new hobbies, game programming, some math, and it's going to be messy while I try to explain it all. Here's to 2017!