Forem: Terrillo Walls

Theater Alpha - The Rewind Update

Terrillo Walls — Sun, 09 Nov 2025 20:38:23 +0000

Alpha 3 introduces the feature that defines Theater Alpha’s identity: the Rewind System. It’s not a panic button. It’s a resource. You get two shots per mission to take back the last 15 seconds and choose a different line. Use them well and you’ll create momentum. Waste them and you’ll feel the weight of every decision that follows.

Why Rewind exists

I tested slow‑motion early on. It worked, but it turned into a tax. If a game gives you a “think longer” button, you’re punished for not pressing it. It becomes mandatory. The Carrot not Stick design approach in Game Design

Rewind flips that. You’re not avoiding mistakes—you’re learning from them. Try the flank. If it fails, roll it back and try a smarter angle. The story still includes the miss, and the adjustment is the point. It feels earned instead of automatic.

Also, let’s be real: rewind moments are where the best stories come from. That breath before you commit. The oh‑no into the clean redo. That’s the clip you tell your friend about.

How it works

Two rewinds per mission
Up to 15 seconds of time rolled back
Positioning, orders, and squad state all revert
Once you’re out, you’re out—every call after that is permanent

The hesitation this creates is intentional. Do you save a pinned soldier now, or hold a charge for the final push? That small moment of doubt is where the game lives.

New systems in Alpha 3

Ammunition and reloads

Soldiers carry limited ammo (180 rounds total capacity)
Magazines empty and require reloads
Weapons have distinct fire rates and reload timings
Running dry in contact is a real risk now

This combines cleanly with Rewind. Burn a roll‑back to fix a wasteful spray, or live with the cost and adapt your route.

Combat pacing

Fire rates introduce rhythm to fights
Reload windows create brief vulnerability
The 4‑soldier squad (down from 6 in earlier tests) makes each reload matter

Design principle: carrot, not stick

The goal isn’t to punish you for skipping systems—it’s to reward you for engaging them. You can clear missions without touching Rewind. If you do use it, it should feel powerful and earned, not required.

What I’m watching in playtests

Do players hoard rewinds and regret it?
Do they spend them too early on minor mistakes?
Does the ammo economy create tension or just chores?
What happens emotionally at 0 rewinds—good stress or bad friction?

If you test this build, I want to hear about the moment you almost rewound but didn’t. What made you commit instead?

What’s next

Alpha 3 validates core systems. Next up: mission structure—multi‑phase objectives, escalating threats, and a “gauntlet” format where ammo and health carry across phases. Rewind works. Now I’m building missions that make you desperate to use it.

Try Alpha 3: Itch.io

The Carrot not Stick design approach in Game Design

Terrillo Walls — Fri, 07 Nov 2025 19:29:00 +0000

You're playing a strategy game where every system seems designed to punish you. Miss a daily login? Penalty. Ignore the crafting system? Your progression slows. Skip the tutorial? Good luck figuring anything out. Sound familiar? This is "stick" design—using punishment to force player engagement.

But what if games rewarded you instead of punishing you? What if every system felt like an opportunity rather than an obligation? This is the philosophy behind "carrot" design, and it's transforming how we think about player motivation.

Common Examples:

Durability systems that punish players for using their favorite weapons
Hunger/thirst meters that constantly drain and demand attention

These systems work, but they create anxiety. Players engage not because it's fun, but because they're afraid of what happens if they don't.

"Carrot" design flips this psychology: Do X and get bonuses. Instead of punishing avoidance, you reward engagement. Players choose to interact with systems because they want the benefits, not because they fear the consequences.

The Stick Design

When designing the tactical combat for Theater Alpha, I faced a classic problem: how do you give players time to think in a real-time tactical game without making them feel like they're being punished for not being fast enough?

The obvious answer was slow-motion. When your soldier is detected by an enemy for the first time the game slows down.

Slow-motion creates an invisible pressure: you should be using this. If you don't slow down time when things get chaotic, you're playing suboptimally. You're being punished for not engaging with the mechanic. It becomes a crutch you have to use rather than a tool you choose to use.

The Carrot Design

Instead, Theater Alpha gives you 2 rewinds per mission.
That's it. Two chances to say "Wait, let me try that differently."

It's a gift, not a requirement. You don't need to use rewinds to succeed. Skilled players can clear missions without touching them. But when you do use one? It feels powerful. Strategic. Earned.

It creates choice, not obligation. Do you burn a rewind on this ambush, or save it for the reinforcements you know are coming? That's an interesting decision. "Should I slow down time right now?" is not.

It turns mistakes into learning moments. Instead of "Ugh, I have to reload my save," it's "Okay, now I know that approach doesn't work—let me reposition." You stay in flow. You stay engaged with your squad.

Rewind adds depth: now you can take risks, experiment with aggressive tactics, try that flanking maneuver you weren't sure about. You have safety net, but it's limited. Use it wisely.

Carrot, Not Stick

The guiding principle here is simple: game systems are more fun when they reward you for engaging with them, rather than punish you for ignoring them.

Theater Alpha is a real-time tactical game about high-stakes decisions and limited second chances. You lead a 4-soldier squad through Alpine combat zones where stealth can turn into chaos in seconds, and every bullet counts.

What do you think? Does rewind sound more interesting than slow-motion? I'm curious how other tactical game fans feel about this approach. Let me know in the comments or try the current build on https://theateralpha.itch.io/theater-alpha

Games design themselves. From RTS to Tactical Strategy game

Terrillo Walls — Mon, 27 Oct 2025 14:44:54 +0000

Theater Alpha started out as a RTS game. I setup the Notion project on September 13th, and you can check out the first version of that game in this YouTube video I made - Welcome to Theater Alpha — A New Strategic Defense Experience #001 (Devlog).

This project started out as a custom game engine project. I was up for the challenge, then I noticed I was basically implementing Unity GameObject lifecycle. So I made the move to Unity2D then to 3D. My experience was mostly with small projects using 2D.

I took a break from the game to focus on other client work, but during this time I started consuming lots and lots of GameDev content. Learning how grids work in 3D and other things like the terrain system.

Then this conversation really stuck out with me. Thomas and John spent a lot of time talking about a game hook and unique feature. My game at this point didn't really have that.

What I had was a Game Design document for an RTS game and a grid to move units. My design had some good ideas but I didn't focus on that. I had a big vision: persistent campaigns, adaptive traits, living battlefield but no working prototype. The health/combat math was overly complex, and I hadn't validated if the core idea was actually fun.

The Problems I Faced

Complex systems without a clear hook
Overly complex health/combat mathematics
Big vision but no working prototype to validate fun
Focus on RTS mechanics rather than the unique story potential

The Realization

While contemplating the design of a prototype and dedicating time to creating a soldier system, I shifted my focus to the concept of controlling six soldiers within the same world-building framework. The majority of the story and core hook ideas revolved around the units rather than an RTS.

What Changed

The shift from RTS to tactical squad management opened up new possibilities:

Focus on individual soldier stories and development
High-level strategic decision making rather than micromanagement
Meaningful consequences for every tactical decision
Smaller scope allows for deeper systems

Instead of managing hundreds of units, you command a small, elite squad. Instead of complex resource management, you make strategic decisions with real consequences. Instead of abstract warfare, you experience the human cost of tactical command.

Implemented Features

3 soldier system with named units
Two operational modes: Stealth & Engage
Advanced cone-based vision system (130-ray raycasting)
Distance-based combat with hit chance calculations
Win/lose conditions with meaningful consequences
Real-time tactical combat system
Health tracking (0-100 per unit) with permadeath
Line of sight blocking via colliders
Visual feedback with colored rays and bullet projectiles

Technical Architecture

The game is built in Unity 6.2 with a component-based architecture:

Unit System: UnitBase, UnitFriendly, UnitEnemy classes
Combat System: Distance-based hit calculations, stealth bonuses
AI System: Cone-based vision, automatic engagement
Manager Systems: SoldierManager, CombatManager, EngagementManager

Lessons Learned

On Scope and Focus

The journey from RTS to Minister of Defense has been about finding focus. Sometimes the best games come from constraints, not ambitions. By narrowing the scope from massive RTS to tactical squad command, the unique elements of the game became clearer.

On Prototyping

Having a big vision is exciting, but without a working prototype, it's just a dream. The shift to focusing on 6 soldiers and core mechanics first has been crucial. You can't validate fun without something playable.

On Finding Your Hook

Every game needs something that makes it unique. For Theater Alpha, it wasn't the RTS mechanics - it was the human stories of individual soldiers and the weight of tactical decisions. Sometimes you have to step back and ask: "What is this game really about?"

You can play the Prototype today.
🎮 NOW LIVE on Itch.io: [theateralpha.itch.io/theater-alpha[(https://theateralpha.itch.io/theater-alpha)

A quick introduction to using Git/Github — ADD, COMMIT, PUSH

Terrillo Walls — Thu, 02 Apr 2020 14:00:10 +0000

As of April 2nd, 2020 I have 106 Git repositories, which is more than any person should. Git is an open-source project developed by the creator of Linux — Linus Torvalds.

Git is a (Version Control System). The idea behind Git is very simple. Instead of having only a single place for code for software. Git offers a remote copy of the code in what’s called a repository and that can contain the full history of all changets at a contributor level. It’s also designed with performance, security, and flexibility.

Git is currently the industry standard. A requirement in any programming environment the level of experience can vary a lot. From a single person to a 50+ team with code reviews. If you are an inexperienced developer wanting to build up valuable skills in software development tools, when it comes to version control, Git should be on your list.

Ready to learn a practical example of Git?

Before starting I highly recommend using Git on the terminal instead of GUI. My reason is simple — Git UI doesn’t scale well in a collaborative environment. When I hire a new Software Engineer the first habit I break is using the GitHub desktop app.

Let’s say you started a new Bootstrap 4 project.

example-website
 — index.html

index.html

<!doctype html>
<html lang="en">
  <head>
    <!-- Required meta tags -->
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<!-- Bootstrap CSS -->
    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous">
<title>Hello, world!</title>
  </head>
  <body>
    <h1>Hello, world!</h1>
<!-- Optional JavaScript -->
    <!-- jQuery first, then Popper.js, then Bootstrap JS -->
    <script src="https://code.jquery.com/jquery-3.2.1.slim.min.js" integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN" crossorigin="anonymous"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js" integrity="sha384-ApNbgh9B+Y1QKtv3Rn7W3mgPxhU9K/ScQsAP7hUibX39j7fakFPskvXusvfa0b4Q" crossorigin="anonymous"></script>
    <script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js" integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl" crossorigin="anonymous"></script>
  </body>
</html>

1st — Set-up a Git repo. (GitHub and Bitbucket are the most popular)

GitHub Example

2nd — Go to project folder and Initial Git

cd example-website
git init

3rd — Add a remote

git remote add origin git@github.com:terrillo/example-website.git

Adding a remote connects your local computer with remote repositories. This process can be repeated across multiple computers. Alternatively, you can clone a repo to your local to get started.

git clone https://github.com/terrillo/example-website.git

When I first started using Git in 2010 I started using GIT as a way for me to try other people code I searched for on Github.

4th-Add your files

The Git process is based around three workflow steps ADD -> COMMIT -> PUSH
Each file must be added to a staging environment before you can commit.

Add a single file

git add index.html

Add all files

git add —-all

After adding files you can use the status command to see what you have done for.

git status

Git status response —

On branch master
No commits yet
Changes to be committed:
 (use “git rm — cached <file>…” to unstage)
new file: index.html

Each file and directory can be easily identified by the green and red
statuses.

5th — Commit

After adding your files. The next step is to commit your work. Each commit is attached to a message.

git commit -m “First commit”

This message is what you will see when browsing your history. In the beginning, you’ll have nice and beautiful messages. With time your messages started to become more crypt-like, “ugh”, “another bug fix”, and “oops”. It happens to all of us.

[master (root-commit) 6581e1b] First commit
 1 file changed, 22 insertions(+)
 create mode 100644 index.html

After each commit, you get this motivational message with the number of files changed and lines inserted and deleted.

Before going on to the next step. Git is even better when used with a modern text editor like Atom or VS Code. These editors make Git worth it for personal projects. After changing the title in the index.html Atom highlights that line as a change. A small feature that can have a big impact on your workflow.

git add --all
git commit -m “Title change”

6th — Push

This next step is the process of updating your remote repo. Its best to push after every commit but it’s really up to you based on your workflow.

git push origin master

origin — the remote name
Master — the branch name

Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 1.09 KiB | 1.09 MiB/s, done.
Total 6 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To github.com:terrillo/example-website.git
 * [new branch] master -> master

Done

That’s a really basic introduction to using Git. With this basic setup, you can start backing up all your code remotely with the option to view the complete history of each file.

Thanks for reading

A quick introduction to Python Multiprocessing Pools. Speeding up your workflow

Terrillo Walls — Mon, 23 Mar 2020 15:43:45 +0000

How many times in python have used a for loop and watched your terminal go through each item taking hours on end?

This article goes over the Multiprocessing module for Python. People get excited that Python uses threading. I know I was coming from PHP land. Threading is different than Multiprocessing by the way.

The threading module uses threads, the multiprocessing module uses processes. The difference is that threads run in the same memory space, while processes have separate memory. This makes it a bit harder to share objects between processes with multiprocessing. Since threads use the same memory, precautions have to be taken or two threads will write to the same memory at the same time.

The multiprocessing module in Python's Standard Library has a lot of powerful features. - Official documentation

Basic loop without Multiprocessing

def f(x):
    # Run Code
    print(x*x)
for item in [1, 2, 3, 4]:
    f(item)

Run

time python3 main.py
>> 1
>> 4
>> 9
>> 16
>> python3 main.py  0.04s user 0.01s system 89% cpu 0.059 total

0.059s is nothing. Let's say that the f() function executes some code that takes 2 seconds long (Updating a database, Resizing Images, scaping a website, etc).

Basic loop with 2s delay

import time
def f(x):
    time.sleep(2) # Wait 2 seconds
    print(x*x)
for item in [1, 2, 3, 4]:
    f(item)

Run

time python3 main.py
>> 1
>> 4
>> 9
>> 16
>> python3 main.py  0.04s user 0.01s system 89% cpu 8.067 total

8.067s adds up over 200 items. This when Multiprocessing can become your friend. Imagine running multiple items at once over that same two-second period. Parallel processing is getting more attention nowadays. As CPU manufacturers start adding more and more cores to their processors, creating parallel code is a great way to improve performance. Python introduced the multiprocessing module to let us write parallel code.

There are plenty of classes in Python multiprocessing module for building a parallel program. Among them, three basic classes are Process, Queue and Lock. These classes will help you to build a parallel program. This is an introduction to Pool.

A process pool object which controls a pool of worker processes to which jobs can be submitted. It supports asynchronous results with timeouts and callbacks and has a parallel map implementation.

Basic loop with 2s delay using Multiprocessing

import time 
from multiprocessing import Pool
def f(x):
    time.sleep(2) # Wait 2 seconds
    print(x*x)
p = Pool(8)
p.map(f, [1, 2, 3, 4])
p.close()
p.join()

Run

time python3 main.py
>> 1
>> 4
>> 9
>> 16
>> python3 main.py  0.08s user 0.06s system 6% cpu 2.180 total

2.180s vs 8.067s means each item in the same array took 2 seconds. Impressive right. It's really nice when you do this on a Linux box. Your code can better use the resources available to you. So, that's multiprocessing Pools in Python.
Thanks for reading.

Sample Code — https://github.com/terrillo/learn-python

Using Python to resize and get HEX color values from images

Terrillo Walls — Mon, 16 Mar 2020 17:23:03 +0000

Python is by far one of the easiest programming languages to use. Writing functions are intuitive and so is reading the code itself. When dealing with images I found Python to be easier to use compared to NodeJS and PHP.

Use Case

Let’s say you were building a website that’s similar to Unsplash. Users are uploading 10MB images to your website from their DLSR camera. Displaying these images on the front-end is asking for a terrible page load. So how do you resize images with Python?

Locate your image
Open as an Image
Resize Save
Dependencies

webcolor: https://pypi.org/project/webcolors/
python-resize-image: https://pypi.org/project/python-resize-image/
colorthief https://github.com/fengsp/color-thief-py

Install Dependencies

pip3 install webcolors python-resize-image colorthief

Resize Image

from resizeimage import resizeimage 
from PIL import Image
image_path = './dog.jpeg'
new_max_width = 1800
new_filename = './dog-1800.jpeg'
with open(image_path, 'r+b') as f:
  with Image.open(f) as image:
  # Resize
  smaller_image = resizeimage.resize_width(image, new_max_width)
  smaller_image.save(new_filename, image.format)

Your image needs to be open as bytes and readable. image.format re-saves the image as the correct type (dog.jpeg is saved back as a jpeg). If you run the code above you just resized an image. The height is auto-calculated based on width keeping the ratio. The PIL package stands for “Pillow” and is installed with “python-resize-image”. Pillow is the ultimate package for dealing with an image. A quick way to get the current height and width plus other metadata.

With the same open(image_path, ‘r+b’) using ColorThief a palette of colors are found.

Get the HEX color value from image

from resizeimage import resizeimage
from PIL import Image
import webcolors
from colorthief import ColorThief
image_path = './dog.jpeg'
new_max_width = 1800
new_filename = './dog-1800.jpeg'
image_colors = []
with open(image_path, 'r+b') as f:
  with Image.open(f) as image:
        # Resize
        smaller_image = resizeimage.resize_width(image, max_width)
        smaller_image.save(new_image_path, image.format)
        # Get Colors
        color_thief = ColorThief(new_image_path)
        color_palette = color_thief.get_palette(color_count=10, quality=10)
        for color in color_palette:
            print(webcolors.rgb_to_hex(color))

color_palette = returns an array tuples of RGB values then, webcolors.rgb_to_hex converts each tuple in to a hex value.

Examples

>>> import webcolors
>>> webcolors.rgb_to_hex((255, 255, 255))
u'#ffffff'

Get color by name

>>> import webcolors
>>> webcolors.rgb_to_name((255, 255, 255))
u'white'

Sample Code — https://github.com/terrillo/learn-python
YouTube video — https://youtu.be/modMAADs71w