But now that I've settled down a bit, lets talk about what we're looking at here. The following five games are the products of an incredible amount of work by a bunch of incredibly talented people with whom I had the privilege of working during my first semester in the EAE program at the U of U. These are student prototypes, built on extremely tight schedules, so please excuse the titles, plot holes, bugs, and so on... :) We had a lot of fun making these games and learned a lot in the process, but these are meant to be rapid explorations of an interesting concept, and lack the polish of published projects.
Each prototype was constructed on a multi-disciplinary team of 6 or fewer people over a period of 4 or fewer weeks, using a variety of development tools. The team, the tools, and the creative freedoms we were allowed were changed up every time, so these projects are examples of work in a frenzied, high stress, environment demanding extraordinary amounts of rapid adaptation and learning in every case. Check 'em out.
Angry Balls - 8/25 - 9/22/2015
My first ever Game! Angry Balls is a Brickles meets The Incredible Machine mashup of drag and drop preparation and real time play in a destructable environment.
Technology: Monogame with Farseer Physics Library.
Written in C# using these two libraries, this game was constructed entirely without the use of any Game Engine editors. We were unsatisfied with the clunkyness of hardcoded levels, so we tacked on a JSON file IO system and a drag-and-drop level builder for this game as well.
My Role: Lead Engineer
I took an early and decisive lead on this project, mostly due to a vacuum of decisiveness and leadership, but I think it worked out pretty well and I was well reviewed by my team in the aftermath. I directed our technology selection and integration, designed our high-level architecture and distributed taskings, and managed our repository through github.com which was a bit rough, but "it go' be'er..."
agalaG - 9/22 - 10/15/2015
Game Numba' Two! As you gamer geeks out there will surely recognize, this is a reboot of the classic 1981 Arcade Shooter, Galaga. We took a different spin on the game and put the player in as "the swarm", deploying groups of "enemy" ships to attack the "hero ship" as whom you would have played in the original. I have no idea whether that last sentence makes proper use of real grammar and syntax...
Technology: HTMLV and JavaScript
Just what it says. The borderline ambiguous syntax of vanilla JavaScript running a canvas based browser game in HTMLV. Still, it was a fun project and a pretty clever idea if I do say so myself.My Role: Engineer and Repo Manager
I took more a more typical engineering role on this project than on my first, and things turned out pretty well. I still managed the gitHub repo and wrote the framework code for the game, effectively deciding the architecture, but the engineering tasking and organization took a bit more of a free form flow on this one, which worked out pretty well due to the small team, big talent, and relatively simple architecture.Pill Pal - 10/27 - 11/5/2015
Unity Time! And a positively absurd development schedule... but this was a serious game (a game with a purpose) meant to help patients with chronic disease (diabetes, organ transplant recipients, etc.) manage their medication in a way that was more fun and interactive than a calendar. Think Tomagotchi meets Medisafe. We wanted to develop and leverage the compassionate relationship between the player and their avatar, who requires the same care as the patient, to promote self-care and medication compliance.
Technology: Unity
The incredibly powerful Unity game engine provided the under-the-hood horses necessary to accomplish this project in the time we had. The concept was an App Store delivered game to promote patient self-care so the prototype is super-imposed into that context via artwork. Since the prototype delivery we have polished this project quite a bit, properly delivered it to the target platform, and entered it in a few medical innovation competitions. I'll post on those outcomes when we hear back.
My Role: Lead Engineer, Design Lead
The architecture for this project got a bit deep again due to the need for persistent, manipulable data, so a slew of Singleton managers came to the rescue! I also had learned quite a bit about how to properly run a github repo by this time, so development was executed using a branched development work flow intended to maintain a stable Master branch at all times. I also had a pretty significant role in the game design on this one, it was a subject that was easy to be passionate about and we're all pretty excited to see where it goes. I'll probably put up a page specifically dedicated to this project in the next little while.
Fowl Situation - 11/10 - 11/19/2015
Fowl Situation is another delusional time-line based Unity title, but we had learned a lot from our first pass. A minimalist art-style drives this mobile platform dungeon-crawler meets hack-n-slash game, pitting a chicken with a bone to pick against a horde of protective penguins.
Technology: Unity
Unity once again! This time developed on android devices right of the bat to take advantage of, and plan for, touch screen features. Extensive use of navigational tools like navMesh and navMeshAgents to bring the AI to life and provide a simple tap-to-navigate, swipe to attack control scheme. This game was simple, addictive fun, but it ended up being more fun to just sit still and punch the shit out of cute little penguins than it was to pursue the end objective. Oh well...
My Role: Lead Engineer, Design Lead
This was the one prototype in the semester where we didn't change teams from the last, so I continued in the lead engineer role without contest. I directed the development and managed the repository per usual, and the team cranked out something pretty awesomely simple and entertaining. This was my first foray into any kind of substantial AI, and it turned out pretty well, but we definitely had some lessons learned at the end of it: omniscient enemy AI's kill explorative game-play, and incessant tapping to keep your character moving is pretty damn obnoxious. We took these lessons with us in our creation of the continuation title, Fowl City.
Fowl City - 11/24 - 12/15/2015
Unreal Engine 4.0! Fowl City is a longer dev cycle iteration on the basic concepts of Fowl Situation. We smoothed out the navigation, added some weapons, and deepened the art style. Ended up being pretty cool looking but, ironically, not quite as addictive as its predecessor.
Technology: Unreal Engine 4
This game took us back to a 4 week dev period and introduced us to Epic's ultra powerful Unreal Engine. We iterated upon the original controls of Fowl Situation to add gesture based controls with tap-and/or-hold for navigation and combat, enemies with limited detection capabilities, and weapon and health pickups to make the world more interesting. We were going for an inner-city grit sort of feel, so tall buildings and narrow streets were an intrinsic part of the picture, which meant dynamic transparency on the scenery was a must to keep the player's view unobstructed. This was a challenge which we met with moderate success.
My Role: Lead Engineer, Design Lead
Since this game was an iteration upon my previous title with a new team, I was quickly nominated for the Lead Engineer roll once again. To leverage Unreal's native repository support, I administrated this project using an SVN server hosted through cloudforge.com and continued the development branch and build master branch work flow. This game ended up being a wee bit buggy, pretty good looking, and a fair bit of fun. The interface improvements from Fowl Situation were notable, but the overall gameplay turned out to be a little bit less engaging... who'd a thunk?
No comments:
Post a Comment