Coehl Gleckner

Game Designer

Hello! I'm Coehl Gleckner, a 5th year at the Rochester Institute of Technology studying Game Design and Development as a part of the BS/MS program. I'm currently completing my Capstone project, a game called A Demon Killed my Babushka, as well as serving as a lead ambassador in my department and vice-president of a volunteer organization. Throughout my time in school I've had a large range of experiences, I’ve been the president of a club, run a game jam, worked at a government consulting firm, advocated for the global water crisis, became a Co-Captain of an ESports team, created a Virtual Emergency Scenario Trainer, met some of my closest friends, and more. Alot of my college experience can actually be summed up in one quote...

"If it's not fun, why bother."

It's something that I've tried to adhere by, in my academics, professional work, and personal life. To me, the quote means pursuing what you're passionate about, and it's something that I try to adhere to when making games. I want to create games that give people interesting experiences, whether that be through a new spin on a mechanic that's been almost done to death, coming up with an impactful narrative about personal experiences, or trying to craft something that's never been done before.

Capstone Showcase

Demo Reel

Previous Projects

Click on the project tiles to learn more about each project!

Virtual Emergency Scenario Trainer

Unity 3D - C# - VR Education

Work Experience

Role: Lead Designer/Developer

Skills Employed:

VR Design/Development, Level Design, Communication

Virtual Emergency Scenario Trainer (or VEST) was created with four other interns at Booz Allen Hamilton for the Summer Games internship. VEST is able to teach emergency preparedness techniques to not only everyday civilians, but also first responders through a virtual reality headset. Use of sensory alteration and a customizable environment allows the program to teach various methods to deal with a variety of different situations. I served as both lead developer and designer on the project, and worked with the other developer to create a minimal viable product capable of being used as a prototype to demo for prospective investors.

Focus

The focus of the project we were given was to create a VR experience that showed off the capabilities of virtual reality, and how useful it can be to develop for. I had the pleasure of discovering this cutting-edge technology with the Vive Pro, and got to create an experience that showed off a lot of the prowess that VR has to offer. I also designed most of the game with the intention that people who would be using it are first time VR users, so the controls are very simple to pick up, and most things you can think of to interact with are actually interactable.

VR Design/Development

I developed the primary movement mechanics and object interaction from scratch, taking inspirations from other VR games I had played in the past. I wanted to make sure that when you were playing the game, it was as interactive as possible to ensure that the player will be able to retain the techniques that we demonstrate to them, and make sure they have ample chances to practice these behaviors. This comes to fruition through the movement requiring the swinging of your arms, and the smoke requiring you to duck as you traverse the burning office space.

Level Design

One of the larger sections we wanted to ensure made it into our minimal viable product, was a mode where you able to construct your own office space for the user to escape from. This comes in the form of a small menu of pre-built pieces that you are able to snap together, which are all different rooms you would commonly find in an office. This includes meeting rooms, small offices, conference rooms, break rooms, and staircases, which all have different objects that you are able to interact with layed out in ways that you would commonly see in an office. This allows the user to mimic their own office space, or create a tailored experience for a specific user to teach them fire saftey procedures that they may not be as strong with.

Communication

One thing I didn't think I'd be taking away from the summer, is the knowledge of how important it is to be able to speak with people of all disciplines. At school, you can assume most everyone knows at least the basics of coding practices and common terms used in classes and amonst fellow students. That wasn't the case on our team, as there were only two developers working on the project, with the rest of my coworkers being devoted to different occupations, such as analytics, entrepreneurship and other forms of business. This led to multiple occasions where I would have to step back and think of how to explain topics that require technical knowledge without it. An example of this explained to me by a supervisor that really helped me get it was "Explain a Null Reference Exception to someone who has never coded before". At that point, it really clicked for me how important being able to talk with anyone and everyone about topics that are important to the project at hand, and its one of the primary reasons I've chosen to minor in Communication.

VEST Report

A report written by my coworkers that details much of VEST, as a solution to a problem and a marketable product.

SMB Levels

Super Meat Boy Level Editor

Schoolwork

Role: Level designer

Skills Employed:

Learning how to use a tool, Introductory level, Testing the player

SMB: Naija Levels

The two links above take you to my two videos created for the Level Design class, talking in depth about the mechanics of each level and their creation. If you'd like to play any of my 3 levels, you can go to the Super Meat Boy Online World in the game and search Naija. My three levels are titled "Naija Block", "Naija Long", and "Naija Float".

Learning how to use a new level editor

When first starting out creating my three levels, I really had no idea what I was doing. I knew I wanted to make a Super Meat Boy level, and had watched a few videos on how to work parts of the editor, but I had no inspiration to create a level until I started messing around in the editor. Creating a section, playtesting it, rinse and repeat. Eventually, I settled on using one of the side characters, Naija, because I hadn't ever seen her before, or at the very least didn't remember her. She played similarly to Super Meat Boy (or SMB for short), but replacing his sprint was a dash that could only be performed in the air. It also had some other interesting components to it, such as Naija floats as the player holds the sprint button in the air, and I decided that I would use these different parts of her kit to make a level based around them.

Creating an intro level for a new mechanic

After knowing what I wanted my level to feature in terms of mechanics, I needed to figure out a way to feature all of them. The image above shows what I initially came up with, and I mostly stuck to that plan. I edited a few things, as the picture I had drawn wasn't really to the scale of super meat boy, but other than that the level was pretty simple to create, and was named "Naija Block". It played very similarly to how I had imagined, and served as a good intro on how to work Naija, including sections that if you know what you're doing can go by much faster. This is especially seen in section 3, featuring pillars of falling blocks, as if you abuse the fact that you can reset your dash on the ceiling of the room, you can knock down each of the pillars without ever touching the floor. While it served as a nice introduction to how to play as Naija, I believe that it was all far too cramped in a small space. If I was to go back and improve the levels I made, this one would get an entire rehaul, making it much less cramped and focusing more on reinforcing each of the mechanics instead of just giving one section to each.

Designing a level for an under-utilized mechanic

After creating the first level, I ended up thinking of two more (seen above) that would work as good feats of strength for the player to overcome with their newfound knowledge of how to play as Naija. The "Naija Long" level, focusing on using the dash by itself, tests if you're able to understand how far the dash will take you, and when not to dash at all. The beginning immediately tells the player that they're going to be using the dash a lot in this level, as the very first obstacle requires one to get over it. The player must dash over, under and around the obstacles in their way to reach the goal, only stopping to reset their dash. The final level I created, "Naija Float", is by far the most difficult of the three. It uses the fact that Naija can float before dashing to create obstacles that are impossible to get through without floating carefully around them. The most obvious section of this, is a jump that requires the player to float through a maze of saws, carefully avoiding them before eventually dashing to a safe platform. Creating levels for this part of the game that didn't see much use in the main game was a really interesting experience, as a lot of what is commonly used in the main game plays much differently when you don't have the ability to sprint, and gives the player a lot more options to traverse the environments you create for them.

PS4 Galaga

Playstation - C++ - Arcade

Schoolwork/Personal Project

Role: Solo Developer

Skills Employed:

Applying algorithms, Porting, Refactoring older work

Porting OpenGL Galaga to PS4

Above you can find a link to the repository for my original OpenGL Galaga project, however the code for the PS4 Port of the project is gated Sony's student NDA, and cannot be viewed.

OpenGL Galaga was a project I started during my fifth semester at school, originally as something fun to do to learn OpenGL more. Over time, it grew into my final project for the course, and included much more than I ever thought it would when it started (it was originally just Pong, which you can also find in the repository). In my ninth semester however, I would return to the project to use it as a base for a Porting assignment in a Console Development course, specifically working with the PS4 architecture. It was a pretty hefty undertaking, and taught me alot about the Porting process (as well as how much you can improve at coding over the course of two years).

Applying algorithms

The reason I choose to port my OpenGL Galaga project was because I was pretty proud of the algorithm application within the project, and thought alot of the logic would be pretty easy to port to the PS4 architecture. This was sort of true (more on that later though), and thankfully I remembered the algorithms I had used to be able to transfer them to the PS4 quite easily, being narrow and broad phase collision detection, as well as binary spatial partioning. This was to improve the overall efficiency of the game, and to allow me to have a background that emulated the original game (but added my own flair). In the gif above, you can see what I was able to achieve. I had implemented A* in projects previously, but this was the first time implementing algorithms I learnt on my own accord. Overall, the project helped me to understand how to take concepts and implement them into my own work.

Porting to PS4

Now into the actual porting part, or rather talk about my overall experience with porting while carefully not talking about specifics. Porting was a far heftier job than I had originally thought, for a multitude of reasons. First and most obviously, was syntax differences between the OpenGL version of the project and how the PS4 architecture works. In loose terms, there was a good amount to change outside of the direct game logic. Secondly, was the fact of my work not being as scalable as I would have liked. Since it wasn't intended for the purpose of being ported to another API, alot of it was specific to OpenGL, and some of the tricks I had learned to make OpenGL bend to my will. The tricks I once had found useful, were now biting me in the bum, and had to be reinterpretated to be able to work on the PS4. There was also researching many of the different techniques I needed to be able to port all the aspects of the game over, such as the background, but the nice part of researching in documentation is once you find something, you don't usually forget where it is. So once I got over the first couple hurdles of getting started, alot of the project started to be ported VERY quickly.

Refactoring older work

So I'd say my biggest issue with porting the project was the fact that a lot of my implementations were... Not great. Having come quite far in my coding ability in the last few years, I've been able to learn a lot of new tricks and developed better coding habits. This led me to absolutely DESPISING my old code, and needing to change a lot of it to be more workable. It was pretty enjoyable to be able to update it all, and taught me alot about what techniques I used to think were efficient, and why they were NOT. I got pretty good at being able to tell when entire portions of code needed to be refactored, or when only a few lines had to. For instance, when working on the background, a lot of the logic just had to be adapted for a larger window, and upping the amount of stars scrolling down the screen. However, some other aspects of the stars had to be entirely refactored, due to the change in architecture.