Ellie’s Thesis Progress

For my thesis, I knew I wanted to make a game for a long time, so these last few week’s have been all about settling on a premise and doing some prototyping. It was honestly a pretty discouraging process at first, I had a lot of ideas, but not a lot of ideas I thought would be a good candidate for a project of this scope, and I was dealing with some pretty bad writer’s block. I spent the end of September brainstorming – I looked at the types of games I liked, mechanics and genres I wanted to explore, and took stock of the projects I’ve worked on during my time in IMM. After a few false starts I finally found a concept I wanted to explore. 

Concept and Inspiration

While brainstorming was pretty slow-going, it helped me reach a few conclusions. One was that I’m very interested in procedural generation – I’ve done a handful of personal projects with procedurally generated dungeons and terrains, and so many of my favorite games had procedurally generated content at their core. Another was that I had a certain fascination with hybrid 2D-3D games and retro art-styles. Finally, hand-in-hand with that first point, I realized how much I liked the roguelike genre. Roguelike games typically have procedurally generated levels, a focus on unpredictable systems, a high difficulty curve, and permadeath (alongside a spattering of other tropes). They had a bit of a spotlight in the indie scene all throughout the 2010s, and I’ve played a lot of them. I’ve also made a few small rouge-inspired dungeon crawlers on my own time. It was around this point that I started to develop a more concrete premise.

Right now, I’m calling my game Wicker (don’t ask why… it just has a nice ring to it). Wicker is a retro-Doom inspired FPS roguelike with a sort of New England gothic/Salem Witch Hunt flare. You play as the child of a witch and a monster hunter, fighting through procedurally generated levels with a combination of magic and steel. Along the way you explore, find loot, kill monsters, and more. I’m planning for a number of the usual roguelike trappings right now, mainly risk vs. reward mechanics, and collectable items that can wildly affect the way the game plays. 

Wicker is being made in Unity, since it’s a highly versatile game engine, and also what I’m already familiar with. The art-style is currently planned to be the sort of 2D-3D hybrid I talked about earlier, with pixel-sprites inhabiting low-poly 3D environments. I still need to decide what modelling software I’m using, but for my 2D art, I’m using Aseprite. 

Progress, Concerns, and Timeline

Once inspiration hit, it hit me pretty hard. I’m already pretty deep into the planning and prototyping phase. Since I want to make a decently-sized game (time permitting), I wanted to do things right and keep my work organized. For that, I’ve been writing out a formal-ish Game Design Document. Currently it details my premise and inspirations, as well as all of the core mechanics, systems, and gameplay loops I have right now. It’s sitting at about 15 pages, and it’s probably a little over halfway done. 

For organizing and tracking my work, I’ve been using a Trello board. I use Trello to write down what needs to be done, organize those tasks with tags, and also organize those tasks into categories like backlog/in-progress/current goals/complete, and so on. I have about 25 cards there right now for the prototyping phase, but that’s bound to balloon way up as I continued working.

 

While I’d say most of my time so far has been planning, I also have the beginnings of a prototype right now. I’m letting this process go a little slow, since if I rush my baseline code the project will be much, much more difficult to develop down the line – If I want my game to be scalable at all I want to do this early project architecture right. Currently I have a pretty flexible first-person controller system, the base of my system for displaying 2D sprites in 3D, and the start of a system for displaying and procedurally animating weapons. I’ve also done some concept sketches, and completed a few sprites to use for testing. Right now, my goal is to arrive at a sort of ‘Combat Prototype’ that allows me to make sure my core systems feel good before I go ahead with building content and fleshing things out. 

There are some small concerns. I’ve done work to make my plans pretty modular and scalable, so if I find that I have too much on my plate at any given time, I can cut back without sacrificing the whole project. The one area this doesn’t so much apply to is art, however. I’m not an artist to begin with, and the art style I’ve chosen can become very, very work intensive if I’m not smart about things. I’m using an ‘Imposter Sprite’ system for my 2D sprites. Essentially, a 2D object in the world has 8 sprites, and a different sprite is displayed depending on which angle the player sees said object from, which creates the illusion of dimensionality. It’s a cool effect, but assuming an enemy or entity with animation uses this system, the work of drawing and animating literally increases 8-fold for every single frame. There are smart ways around this though – avoiding animations where I can and using tweens, sounds, and particles to sell actions, keeping animations short, locking certain animations to be ‘one-sided’, and making certain objects flat instead of 8 sided. Combined with a smart workflow and economical reuse of assets, I think it’s doable. 

I need to make a more full timeline, but currently I’m planning to keep working on this project pretty steadily all the way through this semester and break. I want to finish my combat prototype first, then work on building out core systems that allow for the easy development of new content. If all goes as planned, this semester will be mostly about building out flexible systems and a good base for the game, and next semester will be about filling out content in those systems.