Senior Production: Nearing the End by Thomas McGillicuddy

This is the 2nd to last sprint before the final due date. We’re putting together the final reel, getting shirts and prepping the presentation area, and putting the final touches on the game itself.

We have a fair amount of bugs to bash, but so far everything is coming along nicely. There is no new feature/content to add, only touch ups and basic aesthetics passes to clean up the levels. It’s hard to keep everyone properly motivated and getting their tasks done on time, but hopefully they can keep it all running until the very end.

Senior Production: Beta Boi by Thomas McGillicuddy

It’s been quite a few weeks. Had break, then GDC, then slammed with work, so my sad little blog has been neglected. But I have returned to deliver my report for Tales from the Blasterverse right before we submit our Beta build!

GDC was fantastic. On top of the great connection I made, I got to learn a huge amount about my field and the new tech in it. One of the biggest highlights for sure was when I had an opportunity to talk to some devs that work on Gamesparks (the backend networking service we use) and they took a genuine interest in our work and what we accomplished. The even went so far as to reach out to me with questions and get feedback on the product. A good amount of what I learned at GDC really drove home that, while shaky in some areas, our game and team are trying to use real industry standard tactics to tackle our problems.

Coming back from GDC though, I honestly felt really overwhelmed with the amount of work piling up, and the pressure to deliver “final” versions of everything. I could tell that much of my work was holding parts of the team back, and that really cut into my personal morale early on. I’ve luckily been able to recover by the end of this week, but I’ll need work very efficiently to keep it from happening again.

With Beta comes bug bashing, and boy was it a big week for that. Old errors with mission nodes, and new errors with AI ate into my work schedule. But, both Nils and Zac did a really good job in keeping the entire team moving with little to no roadblocks. On top of that, the new found confidence in our networking system re-lit my passion for it, and I can confidently say that our game is 100% playable with multiplayer now.

All in all, this was a pretty good sprint. I just need to keep the motivation engine running a few more weeks.

Senior Production: Halfway There by Thomas McGillicuddy

It’s the first big push to hit a v2 of the game! Going to MassDigig taught us a lot about what our game’s scope for the semester really should be and we’ve taken that into consideration going into this last week of development before spring break. We want to pivot to a focus more on what our demo should be rather than creating the full experience all this semester. While the team did a fantastic job outlining that long term goal, we lost track of what we’re supposed to be doing here and now, which was made clear last week.

It’s the last week to implement new content, after this week it’s just polishing that content and making it look and feel great!

Senior Production: MassDigi Week by Thomas McGillicuddy

The last week went pretty well all things considered. The programming team was on call for most of it, so sadly we weren’t able to operate at 100%, but that meant we could keep everyone else at 100% instead.

For this week, it’s all hands on deck to get to MassDigi. We’re prioritizing solid content for now instead of the not yet refined features to make sure we present well next week. We’re also a producer down and have a huge mix of other work to keep in line. Fingers crossed we hit the mark again this week and can keep on this pace till the end of the semester.


Senior Production: Build or Bust by Thomas McGillicuddy

The team has been avoiding putting a build together in favor of nailing down any lingering design questions from last semester. Sadly this has left some of the content from out game neglected and resulted in some low team morale.

But luckily, this week the entire team is dedicated to getting a brand new build in game for QA. This would utilize all our pipelines and show off tons of new content for the game. Fingers are crossed that we’ll hit the mark this week!

That mainly means I’m on bug bashing and support, no new features or content.

Senior Production: THE MEGA GUN LIVES!! by Thomas McGillicuddy

This week I was finally freed up enough to get into the MEGA GUN our team has been promising since the game’s conception. I had do a lot of re-abstracting the original gun systems to get the entire thing working properly, but I’m glad the transition was fairly painless.

Right now I’m also adding in features for players to customize colors of their mega gun, but for now I hard set the value to some random bright ones. You might also notice that we’ve started using Nil’s Cel shader on the weapons. The transition is taking longer than I had hoped, but I’m confident we can get our unique style to show through even more now with it.

SPOILER_Capture (1).PNG

One feature of the cel shader is extruding normal to get a kind of cheaper outline effect. Sadly it doesn’t work well with our model, so we may sadly have to forgo using it.

I was also pretty heavily into networking (again) to incorporate the new unlocking system we’re giving players, as well as continuing my on going feud with objective updates.

Luckily, Calvin started getting into the tools I made for the contract creation, and Amanda has taken the map creation in a new direction, opting to making high quality and slightly bigger maps, but reusing them to help expedite the contract creation process.

Lastly, the marketing team has decided that we need to change the game’s name. While I’m sad, I leave it to their judgement, so we need a new name. Gun Galaxy FTW.

Advanced Seminar: Tanden Editor Proposal by Thomas McGillicuddy

The Editor:

For my advanced seminar course my last semester at Champlain, I want to create an editor application built on top of the “Tanden Engine,” and open source Vulkan based game engine I’ve been working on with several other students.

I want the editor to emulate similar workflows to other game engines like Unreal or Unity, with an intuitive user interface and easy file loading and saving. Ideally, this editor will also function as an example “game” built on top of the engine. One thing that I would like to see this editor do is render scenes to images and compile them into a single video file.

This project would be a huge leap into my chosen field of game programming, tools and pipeline. The editor, being the ultimate tool in game development, is a fantastic way to interface with the complex pipeline that game engines offer. Our projected MVP doesn’t seem like too much, so I have confidence that we will meet our goal and very likely surpass it.

The Unknowns:

Right now there are a few unknowns in regards to how the the editor should be interfacing with the engine, and what operations should be engine controlled, and which editor controlled. What’s more, because the engine is not fully complete yet, it’s very hard to determine the entire scope and capability of the editor.

While certain things like the game object management and resource discovery/loading are in a fairly good place for the editor’s development, because the engine lacks certain loading capabilities for resources like images and models, it can’t be said with definitive understanding where an MVP might be.

The hope is that no later than week 7 we will have a functioning rendering system with perspective view, this will give us ample time to have the editor display basic UI elements and give the remaining semester to add in the more complex interfaces for individual components.

The External Requirements:

This is still a team project, and the engine’s development is on-going as said earlier. Because of this, the editor does have some risk to not being able to complete certain features/interfaces if the parent system isn’t ready or needs to be cut. Because my main focus is on the editor, I am almost at the mercy of those other team member’s work, but my extra time allows for defining specific requirements for the engine to help the other two prioritize.

Nils Steinbuegl Advanced Seminar Proposal

Rosser Martinez Advanced Seminar Proposal

Engine Repo:

Editor Repo:

Senior Production: Networking Combat and Objectives by Thomas McGillicuddy

The first week for the programming team went really well! I think everything from the work that I did, to the work that the other programmers did was A+ and I’m more confident than ever that we’ll be a success.

I was able to get a more advanced version of networking running, though I had to shelf specific match instances for now in favor of a working v1 state. Movement and contract selection/loading is sending very nicely, along with a more robust player data tracking service running. I also got a chance this week to finalize some pipeline systems for contract building so that designers can more easily add their content to the game with fewer chances for messing up.

I was really happy with the work the programming team did this week, and everyone was fairly active in responding to questions from other team members and reaching out for new work. I hope that they can both keep up with the growing complexity of work we’ll be doing, but hopefully we can get to a state where we’re mainly running support instead of forging new systems from scratch.

Senior Production: Startup Week by Thomas McGillicuddy

First week of classes in my last semester and we’re already deep back into Tale from Space!

I was able to spend a little time over the break adding some new features with networking and mapping out the new method of tracking player data using GameSparks. Hopefully we’ll be ramping up production on design and art side now that better tools and pipelines have been defined.

I chose to have Nils stress test the systems early on this week to highlight any problem areas with the tool or pipeline docs I wrote, which should give me a chance to fix the issues before the rest of the team gets heavily into them.

Fingers crossed that networking goes smoothly from here on out.

Capstone Blog Post:First Semester Postmortem by Thomas McGillicuddy

Tales from Space Flat 2.png
Bullet Logo Transparent.png

So it’s over! Capstone has come to a close and my team’s game, Tales from Space, made it through! Learned a lot from working on it this semester, both for my skills making tools, but also just as a team member and developer. Here you’ll find my postmortem on how I think the whole thing went.

The Good

Bullet has been hands down the best team I’ve worked on while here at Champlain. We had a solid concept, worked well together and had great team cohesion, and were able to prioritize things effectively. I’m glad that most if not all of the team members actively listened to my ideas and concerns when they came up, and they offered just as many creative and fun solutions. Everyone was actively reading documentation and solving issues on their own. We gave everyone opportunities to let go of any frustration with the team, and that helped alleviate any pressure early on.

The Bad

This semester went pretty smoothly for the most part, not that many bad things to note (but I will note them anyway). I think the main negative item was the early setbacks we faced due to how we ran our sprints. With team members needing work from the other in the same sprint, we failed some sprints because of just the unforeseen time one task would take which cascaded into the other tasks.


Overall, we are well prepared to handle next semester. Senior production, here we come!


Capstone Blog Post: Final Dev Week by Thomas McGillicuddy

This was the final week our team was dedicated to wholly working on the game before getting ready for the final presentation.

Because of this, we wanted to return to the core system of our game, the guns. I was in charge of making the elemental effects really show in the game world, in the bullets and enemy status effects. Luckily, Amanda was able to use my gun builder to very quickly put together a bunch of new guns for us to show off in the latest build.

I also was fixing up some sequence breaking bugs for the objective system that would confuse or stop the player’s progression through the level. These changes were warmly received as at the latest QA, aside from a minor bug with the control scheme, everyone was able to go through the motions of gameplay without any guidance.

All in all, we’re in a good spot for the end, and any issues or lacking content are easily being added this final touch up week.

Capstone Blog Post: Feedback Week by Thomas McGillicuddy

This week the team focused mainly on player feedback and getting combat to a satisfying state. I was in charge of fixing a few bugs with the objective manager and working on some polish (an area I’m not super engaged with).

Our feedback consisted of screen shake and a fun little physics rigid body effect with the robot that explode into various pieces when they die. The robot’s death was rather simple, each mesh has a box collider and a rigid body, then a manager adds random force and direction to each object making it look like it’s spinning.

I also overhauled the combat system this week since the previous input detection was rather inconsistent and not as easily traceable over the network. Things like new input streams and checks for interaction made the whole experience a lot less buggy. Did still hit a bug with the objective tree though, where the ECS tree instance lost connections.

Finally, we went to QA twice this week with different builds. One from the week prior, which had minimal feedback, and again with the new build. The responses were much more positive and engaged with the new feedback systems. One comment that really stuck with me though was that the enemies were fun to kill now, but not really fun to “fight.”

That has influenced what our next big focus needs to be going forward, creating challenge.

Capstone Blog Post: Mission Manager by Thomas McGillicuddy

this sprint I focused on making a mission editor for our team’s vertical slice. Using xNode, I was able to very quickly create a node management system using Unity’s Scriptable objects. Part of the challenge was creating the system in an abstract way to allow my designers to build future missions easily.

While the end product was what I wanted, there needs to be more feedback in the game itself, with better audio and UI prompts. There also needs to be some challenge with an enforceable lose state in game.

Capstone Blog Post: GameSparks, The Redemption by Thomas McGillicuddy

I learned a lot this long weekend diving back into GameSparks to get networked multiplayer working for our game. This was a goal we setup early in development, but failed to get working right off the bat. But now I stand triumphant!

There were many obstacles to learning the setup for this system. Managing real time match instances, packet op codes, player registration and login, and player inventory management. In the end, I was able to setup 4 player matches and get a strong foundation for further networked development going forward.

As for the whole team, because of the break, we’ve been a bit everywhere. I don’t think we got as much done as we could have, but with no other long breaks until midmortem, I think it’s a great chance for all the members to stock up on mental rest.

Capstone Blog Post: GUNS GUNS GUNS by Thomas McGillicuddy

For this week, I was focused a lot on the combat of the game and getting the gun system to really produce unique feeling guns. Luckily with all the setup that we built these past sprints, implementing new guns was super easy. As a team, we continued to find ways to add character to the game, be it through narrative elements or finding a strong tone for the game we wanted to express.

My actual work this week involved implementing a variety of unique gun traits, from bullet behavior to auto generated gun names. While work has started on auto generating the descriptions, it’s still a little ways off before want to use it in-place of hand written descriptions. I also revamped the texture system to work around a pipeline the team’s artist and I came up with.

We ended up taking an early build to QA that let the players use 5 guns with different traits. I was happy to see that feedback on the gun’s names giving them personality and the game as a whole character.

These are the guns we gave the testers to mess around with. At the time, it was really to see what kinds of trigger and muzzle types were popular.

These are the guns we gave the testers to mess around with. At the time, it was really to see what kinds of trigger and muzzle types were popular.

Of course there isn’t only positives, and as we started to get more and more feedback from testers on the individual gun’s balance, we realized that there would be a great deal of balance concerns to take into account. While we don’t want to fix something outright that isn’t showing signs of breaking, it’s still a nice thing to note going forward as we make this immensely scalable game.

Another great thing that happened this sprint is that we started to get some real art assets in engine. Our team’s artist Mike got around 15 parts into the engine, though sadly after our planned QA time. With that, I was able to really let the gun system flex it’s muscles and mix and match all the parts at random. While there’s still work to do, especially around balance, we’re all excited to see our hard work come to fruition.

There are 630 possible combinations of guns with the current roster of planned and implemented traits. We were able to get around 360 unique combinations of the assets Mike made, though that doesn’t include things like textures and stats, which will give each gun even more character.

There are 630 possible combinations of guns with the current roster of planned and implemented traits. We were able to get around 360 unique combinations of the assets Mike made, though that doesn’t include things like textures and stats, which will give each gun even more character.

Capstone Blog Post: Tone Maps and Gun Editor Tools by Thomas McGillicuddy

This week my team decided to give another week for both concepts to better flesh out the mechanics of the western mystery game, and the world of the atompunk twin stick shooter.

Because we only have one (stellar) designer, I went ahead and tried to assist with creating the world of the atompunk shooter. I made a tone map with a laundry list of our references. I used anything with atom punk references like movies, comics, tv shows, and other games, then put them on a X axis scale going from more serious tone to more ridiculous. Then I gave the map a Y axis for player dependence, or how much the game NEEDS other players to be played. We looked at lots of other co-op games, or games with a strong co-op culture, like Halo, and had them going from player independent to player dependent. Then, I move everything on the map along the opposite axis (unless it wasn’t a game), to get a clearer 2D map. Finally, I was able to go to my team at the end of the sprint, and simply ask “Where do we see our game?” Which we all pretty much agreed somewhere between Jetsons and Flash Gordon in seriousness, but as close to Borderlands in terms of player dependence as we could get.

Here’s that tone map

Here’s that tone map

The other 4/5s of my week was focused around building the foundation of the procedural gun system. Defining gun classes was easy enough, they have part IDs, and some base stats saved to a json file. Part classes were pretty much the same, stats, auto generated part ID (used by gun) and a string for the file name for which mesh it uses. What was a REAL challenge, but fun to do, was creating the editor window itself in Unity. It comes equipped with a preview screen to let the designer view the model of the parts and guns, and lets them edit the Json without looking at straight text. Guns can be spawned into the scene and given to players, and it automatically reads the various part’s information to determine the different traits, like fire rate, elemental effects, etc. It was tons of fun to learn about and watch come together, and I can’t wait for my designers to start using it with new gun ideas.

a screen shot of my gun editor

a screen shot of my gun editor

Capstone Blog Post: Gameplay programming for Western Shooters by Thomas McGillicuddy

This sprint I got to focus more on gameplay programming instead of backend technical work. We decided that we would have both programmers work on the gameplay prototype, which resulted in having the third person shooter systems and a few miscellaneous systems assigned to me.

I was able to get the third person shooter system running easily enough, with a few minor tweaks for a basic UI screen and score trackers. I used a basic raycasting system for the combat, so the damage is instantaneous. It makes it harder off the bat to do interesting things with particle effects, but it should be fine for a demo. I also added in a special camera rig that allows the player to zoom in when they want to fire, it also raycasts against the ground to prevent clipping.

Overall I think the team is working really well together. We weren’t as sure about the type of game this western one would be when we started, but by almost forcing us to think about the concept as a contrast to the other atompunk game, we came up with some really cool ideas that we may be able to take for the rest of the semester.

Capstone Blog Post: Fun with Gamesparks and Technical Challenges by Thomas McGillicuddy

This week, I had to focus on the prototype of the Atom-punk twin stick shooter. WE still haven’t come up with a name for it, but that should be fine until we decide with game idea we’re going forward with. My role was to get the backend service with gamesparks working with multiple instances of Unity and begin creating wrappers for the data being sent across the network. I envisioned just being able to send transform information of two game objects, which I could tie into Zach’s prototype of the controls.

What ended up happening was that using gamesparks wasn’t as simple as I initially thought. While getting the instances to connect to the backend was easy enough, breaking them out into multiple match instances was harder than I anticipated. I had to define what a match was on the client side, which I was able to do. However, actually joining those matches and subscribing the data stream for that information was out of scope by the end of the weekend, when we have our code freeze scheduled. Going forward, I will need to better evaluate the needed attention for integrating gamesparks into our game. I still think it’s the best option for our game, just needs more work than I expected.

Game Engines Blog Post: Engine With Cloud Based Render Farm Capabilities by Thomas McGillicuddy

This semester I'll be creating my own rendering engine to experiment with advanced graphics techniques and cloud based rendering.

It will start off fairly simple. Using either Vulcan or DirectX to create a basic rendering engine for displaying models and a basic scene. There should also be a object manager to handle object placement in the world, and describe simple functionality, such as an animated camera. There will also be a simple shader system, that can allow for various interesting graphic systems to be applied. Then I want to create an exporter that can save individual frames as images from a scene's camera. Right now, there are no plans to include a video encoder, but each frame should be able to be linked together to create a coherent video in another program. That is what I would consider my minimal viable product, the absolute minimum for this project to be satisfactory.

Going forward from that, I would want to integrate some form of advanced rendering techniques, potentially ray tracing or subsurface scattering. Then, I would want to pair this with a system to send raw input data to a cloud server to calculate the lighting information, which would be sent back and applied to the output frame render. 

My current plan is to use AWS EC2 instances to process those large calculations. This allows for the hardware that the engine instance is running on to be lightweight, and handle more immediate processes. This is a practice currently used by many companies, both large and small, to mitigate overhead costs of server maintenance and provide a scalable solution. 

My "end goal" is to display a comparison of the output video, one with the cloud rendering, and one without. The time it takes to complete rendering all the frames should be significantly lower on the video that used cloud servers. Another option is to show a complex scene being rendered on a very low spec machine, since the actual heavy lifting will be handled by the cloud instances.

Some potential technical risks up front are: creating an output system for the individual frames, the integration with AWS EC2 instances, and building a proper, but rather simple version of a complex graphics practices. To try to mitigate these risks, I will most likely be hard coding some of the data that will be displayed, and greatly limiting the flexibility of formats. I will also most likely not be creating a preview window of sorts, instead almost running a console application to render the scene.


IDE Picks:

Initially, I decided that since the issue of using a cross platform capable IDE was important only if the working environment changed, all I needed to do was retain the exact same environment. Thus a remote desktop would be perfect, since from any platform it could be connected into, and wouldn't need any amount of set up for different development platforms.

However since that solution would lead to an inability for grading my work, I've elected to use CLion. It has intelligent code completion and can easily work on any OS right out of the box. 

Capstone Blog Post: Concepts and Prototyping Tech by Thomas McGillicuddy

This is the blog to keep track of the development for my ever exciting and interesting senior capstone game at Champlain College. For the next dozen or so weeks, feel free to check back here to see what's new on the game, the team, and what wacky tech I choose to learn how to use.

For the first week of my capstone project the team had a great ramp up of game and team branding concepts. We started with around 50 game ideas and 15 team ideas that had to be culled rapidly so we could hit the ground running.

We settled on the two main concepts we'd prototype, an Atompunk Co-op twin stick shooter with RPG elements, and an Western themed 3rd person shooter with animals as the characters.

For the team name, we thought that the name "Bullet Mullet" had a lot of potential and could fit both game's feeling without much adjustment.

Finally, I started to prototype the high risk elements of both games, networking systems. Luckily I have had a backend provider in mind for quite some time, Amazon's Gamesparks. Because it uses AWS, it can scale up rapidly at no extra effort, it can support anywhere from our 2-4 player games, to 120 player games that we could experiment with. Getting the base account setup was easy, with a school account getting free 100,000 monthly active users, and well maintained Unity packages already made. I had requests to the main server running in less than two hours. The next steps going forward are creating the game state wrappers, and some concept specific systems for both the atompunk and western game. I will probably complete the atompunk baseline weapon loot generator in these last few days.