Let's get the big news out of the way: On May 14th, I graduated from Champlain College with a Bachelor's Degree in Game Programming!
That's right. This blog was started just before the start of my Freshman year, with the goal of documenting my work throughout my studies. Its purpose is now fulfilled, but I have no plans on stopping anytime soon. I'm going to keep posting as long as I can, so don't worry about me disappearing.
Now that I have my degree, I also have to start considering how to divvy up my time for working on projects. I doubt it'll be very long before I'm working 40 hours a week, so I need to come up with a solution that will last beyond my current 'vacation'.
The Plan
Right now, I'm planning to adopt an Agile-like method of working on my projects. Every week, I'll figure out which tasks from various projects to work on, and then try to get them done that week. For now though, that seems like a bit of a leap from my current carefree work-on-whatever schedule, so I'm going to be taking this transition in steps.
For now, I'll be trying to make a list of several projects every week, and focus on one or two every day. This should give me enough content to make at least one post per week. (No promises, though)
It's likely that you'll also see more non-programming content. I've been meaning to do more with art and audio for a while, but school got in the way time and time again. I'm hoping to practice those skills a bit, and maybe that practice will turn into posts once in a while!
It's been a few weeks since my last capstone post, and quite a lot has happened! Last week we finished The Last Light and presented it at the senior show, and it got a pretty great reaction all around. Even better, the game got several Let's Plays after we put it up on itch.io, and the overall reaction seems to be pretty good.
By the way, you can download the game here:
(Sadly, it's Windows only right now. I might see if I can put a Linux build together at some point though)
Now that the dust has settled, I thought it might be a good time to go over some statistics from the project. I got a few requests from fellow team members, and also wanted to do some things myself, so here we go:
(Please keep in mind that these numbers are estimates pulled from hastily-constructed git queries. They should be close to the right number, but may not be perfect)
Total Number of Merge Conflicts
When dealing with teams that have more than a couple of members, it's only natural that at some point, merge conflicts are going to happen. This problem becomes even more common when your project consists mostly of binary files that can't be merged normally. We certainly had our fair share with 122 merge conflicts resolved.
Floor_400x400
For some reason, a random unused asset from the UE4 starter content folder, Floor_400x400.uasset, kept getting marked as changed. My team was curious how many times it got 'updated' in git. Apparently, 60 times. That's about once every other day!
Substance Plugin Kill Counter
Unreal really loves the Substance plugin. If your machine has it installed, Unreal has a habit of quietly slipping it into your project when you're not looking. Then, everyone else on your team gets a little popup saying something along the lines of "This project requires the Substance plugin. Do you want to download it now?"
Naturally, this message is a tad irritating, so we tended to go into the project file and purge the plugin. We did this 34 times, in fact. That number actually seems remarkably low, but I think it's because we didn't always remove the plugin immediately if we were busy, so sometimes it would stick around for a while.
Total Number of Binary Updates
Have you ever an artist to go compile some code? It's not pretty. Although Unreal makes compiles pretty easy, we programmers made a point to include the compiled binaries in git so that our fellow team members could spend less time compiling and more time developing. This happened 96 times.
That's it, but hang on to your seats, boys and girls! It's time for.....
Uncle Huey's Repo Analysis Awards
The "Biggest Git" Award for Total Commits
Let's start with a simple one: Who made the most commits overall? It was a close race, but the winner is: Chris Johnson, with 292 commits Second place is Vincent Loignon, with 288 commits. Simple, right? On to the next category!
The "Man of Mystery" Award for Commits under an Alias
Not everyone keeps to a single name, especially when jumping from computer to computer. This award is for the person who made the most commits under a non-name: Jesse McKinley, with 122 commits listed as 'Dekeche'
Second place is Hugues Ross (me), with 121 commits listed as 'DF458'
Looks like it's another close one. Next!
The "Fashionably Late" Award for Latest First Commit
You know what they say: The early bird is a total loser. This award goes to the person who was the last to start making commits to the repo. Who won? Why, it was: Paul Scardera, who first committed on April 13th
Second place is Kyle Patterson, who began on April 8th
I think it's important to mention that these awards are meant to be fun, and that this isn't any sort of condemnation. Paul and Kyle are both producers, so they only joined in with direct development at the end to help with 11th-hour grunt work. They've been super helpful throughout the project, just not with commits.
And speaking of strange awards...
The "Writing is for Losers" Award for Most Commits Without Changing a Single Line of Text
Git keeps track of how many lines of text were added, removed, or changed in text files. This award goes to the developer who made the most commits while maintaining a perfect 0 in all of those categories. Let's hear it for: Paul Scardera, with 7 commits and 0 lines
Second place is Scott Beecher, with 6 commits and 0 lines
Again, be nice, not everyone's work is represented by commits, yada yada.
Now, time for the final award:
The "Who's That Pokemon" Award for Most Enigmatic Team Member
Among the huddled masses of our Slack channel, there are rumors of a secret developer, spoken of only in hushed tones, working from the shadows. Who are they? Where did they come from? No-one knows for sure. Of course, I'm talking about: Unknown, with 18 commits
Yeah, so someone probably just forgot to enter their name into git before committing. Still, it's good to have fun with these things, that's what the awards are for!
Actually, I just double-checked and apparently it was me all along (with one commit from vince). Whoops!
Project Development Visualization
All this text is pretty boring. Thankfully, I have a solution to that problem. In addition to all of these stats, I also have a visualization of the project's development, starting from February (Fullscreen viewing is recommended):
This video was made with a super-cool tool called gource. Go check it out!
This semester, I posted twice about console programming projects. They were small, carefully scoped projects to help me get a jump-start with DFGame. Now, it's time for the big reveal: My final, 2-month long console programming project. That's right, I
PORTED DFGAME TO HTML5/WEBGL
Yes, all of it.
One of the requirements for Console Programming is to develop at least one project on an unfamiliar platform or with unfamiliar tools. I decided to try my hand at developing a web-based game framework that was fully compatible with DFGame. The project was a big success, and I actually have a playable demo up on my site (based on the demo I produced for my previous project).
You can check it out here. (Note: you need a relatively recent version of a modern web browser such as Firefox or Chrome. IE won't work and Edge/Opera/Safari are untested)
Now, let's talk a little bit more in-depth about the project.
History
When I originally kicked off this project in class, I had much bigger aspirations. My original goal was to port both DFGame and Halberd, then add an HTML5 export option to Halberd's editor. Obviously, that was way out of scope. After a week or two, I decided to scope down to only porting DFGame, and that's what I stuck with throughout the project.
I wasn't sure how much of a demo I'd be able to put together, but I managed to complete the DFGame port quicker than expected and ended up with a couple of spare weeks to work on the demo.
The current demo doesn't have a title screen or audio in it, but is otherwise mostly indistinguishable from the desktop version.
Now, let's talk about the platform in general, and weigh the pros and cons of the platform.
Pros
This setup is mostly cross-platform. I don't have to worry as much about weird edge-cases, at least compared to developing native Windows and Linux versions of my games.
The games that I make with this are more accessible in general. There's no need to download an executable, just load up a link and play.
Since the library draws to an HTML5 canvas, I can pretty much embed DFGame into any web page that I want.
Those are some pretty good benefits. However, there are some pretty big problems with it as well.
Cons
Unlike the C version of DFGame, all IO is required to be asynchronous. This isn't necessarily a bad thing, but it means that I need extra boilerplate to ensure that the right assets are loaded before the game begins.
The actual performance of DFGame is way lower when using the HTML5 version. This is to be expected, of course--You can't really compare raw C to embedded JS, especially not in web browsers with single-threaded renderers, such as Firefox's current release. Chrome currently gets way higher FPS than Firefox, but it still lags if enough is happening on-screen.
The WebGL API is currently outdated, compared to the current OpenGL and OpenGL ES standards. As far as I can tell, WebGL is still locked to the GLSL 1.0 standard, compared to 4.3 in GL and 3.2 in GLES. As a result, I need to rewrite all of my shaders whenever I move something over.
Further Work
Despite the problems with developing HTML5-based games, I'm actually pretty happy with the result. I think it's worth my time to continue developing and using the DFGame port, especially for game jams and other simple prototypes.
The port is currently behind, because I've been recently developing DFGame some more. I'll be posting about some of the new improvements soon. I also want to look into optimizing for WebGL better. I can't get a comparable framerate to the C version, but maybe I can eke out some more performance out of the web.
Lastly, I want to polish the demo some more. If I get it into a good enough shape, I think it could make a good portfolio piece. For now, I'm going to let it sit in a dark and dusty corner of my site until it's properly finished. Hopefully I'll have more time to do that now that my finals are over.
