Nathaniel Bostick

Game Designer | Unity | Unreal | C# | Visual Scripting | Level Design | UX

I'm a Designer with a background in IXD and UX, with a drive to help people make the most of their ideas. I seek to learn, work, and connect with others in the creative industry throughout my life.

• Games
• Projects
• Contacts

Games

Projects

Contacts - Let's connect!

• LinkedIn
• Email
• GitHub
• Itch.io

Going into this project my team had some goals to show off our capabilities as developers. Our goal was a simplistic platformer with a unique mechanic that showcased our character’s animations and world in a clear way. A cat that swims and platforms using an ink-swim mechanic akin to Splatoon seemed to fit our goals, and allowed us to be reductive to ensure scope didn’t balloon. As one of two primary programmers on the project, my goal was to get our character’s movement and environmental interactions working. I also took on the role of git management, ensuring our feature branches were updated and merged to avoid conflicts and performance hiccups.“Swimming” on all surfaces, any orientation.
3d character movement is a complex thing in itself, but being able to walk on all surfaces was quite the challenge to devise. Our key reference game of Splatoon actually avoids the issue entirely, making all climbable surfaces either top-facing or strictly vertical to avoid situations where their character is upside down. Games like The Amazing Spider-Man (2012) invert the camera to orient the controls to the player character even while upside down. Super Mario Galaxy varies its inputs situationally (and rather inconsistently), based on both the camera and the player’s forwards heading. Wanting to not disorient the player in our already flat-white environment, a different method would have to be used.For Kit ‘n’ Ink I devised a method hybrid to Galaxy and Splatoon and took the wall-based forwards direction to constantly be “up” whenever the surface faced the player camera. This meant that when riding over objects, the up direction on the analog stick would always correlate to motion forwards over objects in the environment. This also meant that when upside-down, up inputs would direct the player towards the camera, generally towards an edge that would allow them to take on the wall-logic and move their character literally upwards once more. In playtesting this seemed to be the iteration that most consistently led to players moving in the direction they intended with their inputs, and so is what we maintained throughout level playtests.Left and Right input was also tricky, but the simplest solution was to make it relative to the surface the player was on. We initially tried also making it camera based, but it was more disorienting to playtesters having multiple possible angles rather than simply having a right-wards input make you go exactly horizontally right. This input would still be camera based, as having the player on a surface facing away from the camera will invert the directions, allowing players to go towards their input direction instead of wherever the cat’s relative left/right would be.The ink system
This was the major bugbear for this project. Our prototype started out with a vertex-painting colour data reading system using an environment model's vector data to store and display the ink through a vertex shader. It was functional and pretty, but we found out quickly that this was both inconsistent to read from and write to due to requiring all terrain models to use a consistent vertex spacing and necessitating the ink shader only reveal where vertices were painted properly.My programming partner James then spent ages on a texture shader based system in which we could read/write from a texture that simply held whether a pixel was painted or not. All of our textures would be loaded on level load, causing a major lag spike but allowing us to avoid the consistent lag that initializing textures every time a new object was painted would cause. This system required our character to acquire the texture’s uv position related to world space, through a raycast that would constantly fire during swim-state.This caused several problems which needed to be solved quickly, as it was the primary feature of our game.UVs were a painful thing for us, as brand new game devs. Our programming skills were inadequate to achieve a backend system that could efficiently work with tiling textures and UV maps, so our artists were forced to work with the idea that all of our models had to have their UVs mapped on the 0-1 scale so they would be readable by the character reading the UV position from the game world. For a city environment in which you would normally use large amounts of tiling textures, this was painful and we sincerely apologised to our artists for this extra workload. We ended up using several iterations of the same shader which drew from the same texture at different scales/tilings (still mapped to the same 0-1 ink texture) to ensure our gameworld had a consistent texture scale.Another thing we didn’t know at the time is that reading textures off the gpu and sending them to cpu would cause stuttering and delays as it takes a significant amount of time to send data between them every frame a program runs. The solution should have been an asynchronous method of acquiring data from the gpu at irregular intervals, calling for new data as soon as the last call had finished. We didn’t do this. A little counter that ticks every frame to reduce gpu calls was implemented as a stop gap, and it held up enough to get us through our production time frame. I had done a lot of research on how to do that asynchronous callback loop, but with time crunching down and other polishing tasks on necessity it never got implemented.Code & Repository management
Having never truly programmed before this program (I knew bits of css, java, python) it was quite the task trying to ensure that every system we created worked together well. I spent lots of time ensuring my code was heavily notated to make sure that anybody on the team who went in to implement a feature (vfx, audio, etc) would have the simplest time understanding where to put their code. Making sure my code was hard to break also meant that my teammates’ code could be mutually independent and less likely to cause bugs.Our team used Fork to manage our Git repository, and thanks to our classmate Xav we had a little guidebook that taught us how to quickly create, update, and merge feature branches. Being deep in the code on this project I was well positioned to understand what features were developed where, so I tended to act as quality control making sure features would be pushed through to completion without causing issues. We of course, still had bugs and conflicts and this meant we got very familiar with Unity’s debugging tool set as a means of identifying and clearing said issues.Play Kit 'n' Ink on Itch.io

• Return to main page

John Robot Programmed For Vengeance taught me how to scope appropriately and manage time effectively

Leading a project for the first time taught me how important it is to manage scope and team capability to ensure ideas get realized.The initial concept was "simple", make an isometric twin-stick shooter in which you play as a robot taking vengeance on enemies John Wick style. What we didn't realize at the time was how complicated it would be to setup the systems that we had proposed for ourselves. We also wanted to relax, as students doing a first project we understood we had school priorities that needed to be accounted for.Not prioritizing the project in our time allocation was a major mistake. Our prototype and art production staged far behind our peers who had properly tasked out their time to ensure features were done as soon as possible. Despite having a concept document of our game loop and progression, we didn't have a wholistic view of all the systems involved and the scale of productivity we would need to employ.As a team we felt low, and as Project Manager I realized that I needed to take far more accountability for the time we allocated towards the project. With several long meetings we scoped down our project, decided on our Minimum Viable Product, and got straight to work with intention.Weekly work hours were planned out with S.M.A.R.T. goals set in place to meet each milestone date. The excel sheet with our Kanban development plan was checked regularly and communication between team members was made more consistent to ensure everyone understood what was being done. Feedback requests were baked into our daily check-ins, to ensure that features were developed on time.It's still not the prettiest game, but I'm proud of myself and my team for what we achieved and the lessons it taught us about scope and task management.Play John Robot Programmed for Vengeance on Itch.io