https://www.linkedin.com/in/chris-labauve-72ba27187/
https://github.com/jiminychris
In March 2023 (a week before my first child was born), I performed as Jimmy Ray, one of the leads in an independent production of the musical Bright Star. I created a web app to help me study and practice my lines.
http://jiminychris.com/bright_star/
My wife and I got an early tip before trivia one week that the half-time questions would involve matching state outlines to capitals.
We got all ten points.
http://jiminychris.com/states/
In the summer of 2019, my wife and I participated in a "boozy spelling bee" at Wheelhouse, a gastropub in Dallas (since permanently closed). This was a weeks-long affair, and I eventually ended up taking home the grand prize of a dinner for 6 after correctly spelling "pendeloque." The bee organizers published the word list ahead of time, so I of course created an app (in Python) to help us study.
After we moved to Nacogdoches, we were invited to participate in Thomas J. Rusk elementary school's adult spelling bee fundraiser, representing the Fredonia Brewery. I resurrected my old spelling bee app and turned it into an easily shareable web app, now kitted out with a firebase backend for serving up and creating new word lists.
We are three-time consecutive champions of the TJR spelling bee (with my wife carrying the team every year), with no end in sight to our reign of victory. This spelling bee app also led St. Boniface High School to win the 2023 Archdiocesan spelling bee in Tyler, TX.
During some time off, I decided to see what I could do if I just focused on writing a game engine from scratch. I'd heard that every game programmer should write an Asteroids clone at some point, so I got to work on that.
And, by the way, when I say from scratch, I mean no code at all that wasn't written by me. Since I started following Handmade Hero, I really fell in love with the idea of knowing exactly what all the code in my project is doing, and having the ability to just go and fix something that's broken. The only libraries in TROIDS are the C Runtime Library and primitive Windows libraries (e.g. Win32, DirectInput, XInput).
I ended up writing a pretty decent software renderer, and a collision detection system that took a good deal of trial and error and a good deal more pen-and-paper geometry sessions. A lot of coding time went to writing and maintaining the debugging/profiling system. The effort was definitely worth it for how easy it was later to visualize execution time and memory allocation. The debug display can be accessed by clicking the frame timer in the top left corner when playing the debug build of the game.
You can browse the code at GitHub.
You can download the game here, but be warned that it wasn't tested on many machines. My dev machine has an NVIDIA GeForce GTX 780, but the only hard requirements that I'm aware of are Windows (only tested on 8 and 10 so far) and at least 256MB RAM. The debug build requires 3GB RAM. TROIDS tries to use OpenGL, but if that fails it should fall back to GDI blitting.
As for controls, you can use a keyboard, a DualShock 4 controller, an Xbox One or 360 controller, or a USB Nintendo 64 controller manufactured by Retrolink (it's the only generic gamepad I've got). Xbox controllers vibrate in the release build. Here's a table describing the controls:
Fire/Confirm | Accelerate | Spin | Start | Back | |
---|---|---|---|---|---|
Keyboard | Space | W or Up | A / D or Left / Right | Enter | Esc |
DualShock 4 | X | Up | Left / Right | Options | Share |
Xbox One | A | Up | Left / Right | Menu | View |
Xbox 360 | A | Up | Left / Right | Start | Back |
N64 by Retrolink | A or Z | Up | Left / Right | Start | B |
Back in 2013, I had been reading alot about game architecture and the "best way" to organize game code. I came across the entity-component-system (ECS) concept and thought it was the cat's pajamas. I tried to make The Legend of Zelda (LoZ) with the idea in mind that I was going to use ECS at all costs. This became very frustrating because of my flawed understanding of ECS, but also because I decided ahead of time what the entire architecture should be without writing a single line of code. I also desperately wanted to shoehorn every aspect of the game through this ECS framework even if it didn't make any sense to do so.
After burning out on that first attempt at writing LoZ, I vowed to just start writing the code that would make the game work. I got pretty far, making much of the lower parts of the overworld map and all the rooms in the first dungeon. I used XML files to describe each room, including the monsters that could spawn there and the color palette to use on the tiles.
You can check out the code at GitHub. I wrote the game in Python using Pygame. Instructions for running it are in the README.
After working on the Python LoZ remake, I figured it would be nice to port it to HTML5 and finish it there. After all, it would be way easier to get people to look at it if they could just browse to it instead of having to download a bunch of files.
Anyway, I didn't get any further than drawing a green box that collides with a map defined in JSON (XML is sooo Web 1.0). What I did spend a lot of time on here was a fun little map editor that can load and spit out JSON data.
You can check out the code at GitHub. The editor itself is here. If you really want to look at the green box, you can find it here.
When I was in school, I participated in a few programming competitions. I kept a bunch of my solutions to practice problems hanging around on my hard drive until I decided to back them up in 2015.
Like all the rest, the code is over on GitHub.