Skip to main content

Bottle & Barter Postmortem

  This semester, I was the lead designer behind the game Bottle & Barter, a blend between potion crafting, customer interacting, and choose your own adventure-style stories. I learned so much from this project, and I was able to take it much farther than I ever thought I’d be able to!

B&B started as a simple idea: what if you were a potion seller, and one of your customers accidentally exploded upon drinking a potion you sold them? This concept of not knowing your potion’s effects, along with the anticipation and surprise of finding out what they actually do, was the foundation of what our game would eventually turn out to be. This idea would eventually make its way into our paper prototype, and prove to be an engaging experience for players. 

I believe that this solid foundation enabled us to develop our game confidently, cutting out features that didn’t serve this foundation and pouring our effort into areas of the design that did. For example, we originally planned on having players gather ingredients by assigning their pet familiars to different areas on a map, which would yield different resources. This was a fun idea, and I think could have made the process of ingredient gathering more engaging, but ultimately it didn’t directly serve our foundational idea as much as some other features would. We ended up cutting this system entirely, replacing it with a standard shop, so that we could focus on polishing the gameplay loop we already created and implement portraits for each customer.

A familiar face runs the humble ingredient shop!

Speaking of character artwork, that’s one area that I believe I overscoped as the person responsible for making it. Originally, I had planned on doing full-body drawings of each character in B&B. I was able to complete this for the Knight, but the process took far too long to repeat for the other characters. In the end, we had to make the call to scale back the character artwork. Instead of 128 by 128 full-body drawings, we would use 32 by 32 headshots of each character. Sadly, this meant that most of the Knight’s artwork isn’t shown anywhere in-game, but it did mean that we were able to have headshots for each character!

That ability to quickly identify pitfalls in our development and design process and steer away from them is another thing that I think went really well during our design process. One of these pitfalls that we were able to avoid was not adding unnecessary elements to our game for the sake of sticking close to our original genre. B&B had originally started out as an idle game, but later on in development and in playtests we realized that an idle game wasn’t what we wanted to make, nor was it what our players wanted from our game. Rather than try to shoehorn on the features necessary to call B&B a proper idle game, we decided to abandon the label entirely in favor of driving our gameplay loop forward in the direction we were already going. I believe that this led us to develop a game that offers a more unique, cohesive experience than we otherwise would have.

I think that this project really taught me the importance of having an idea that you’re confident in be the basis of your project. I believe that I got pretty lucky that my first attempt at a paper prototype proved to be pretty successful. I think that if that were not the case, it would have been better to revise the idea and try again on paper rather than move into production with an idea that hasn’t shown any promise yet.

Comments

Post a Comment

Popular posts from this blog

CAGD 373 Blog Post 4

This sprint I was assigned a modular set to create the basic interior rooms out of, with three different textures for the walls. (a Square Brick Texture, a Cement Texture, and a Metal Wall Texture) The actual modeling itself was as basic as it gets, I just made a few different shapes and sizes of wall along with a doorframe, with a couple floors and ceilings to complete the set. The interesting stuff this week was the textures, all of which I made in designer! The brick texture was probably the most complicated, and the one I’m most proud of. Starting with a brick generator, I used some gaussian spots to add some variance to the shape of bricks (using the spots to “cut out” chunks of the perfectly square bricks) and that worked pretty well! After that, I used a grainy looking noise map to fill in the black part of this mask to add in the noisy texture of mortar between bricks Next, to add some color variation to the bricks, I used a flood fill node, which was able to identify all the...
Post a Comment
Read more

Video Game Production Sprint 1

  After a long time spent away from Unreal Engine, I’m getting my hands dirty once again as a programmer for the Kill Everything in Sight team! KEIS is an endless action FPS roguelite where you play as a killer robot tasked with exterminating the remains of the human race. Despite your incredible movement and combat abilities, you are severely limited by a timer ticking down during the entirety of your run. Killing enemies will add precious grains of sand to your cruel hourglass, so the player must focus on speed just as much as precision! I was brought on the team as a programmer, and I started off very nervous since it's been a while since I last programmed in Unreal. On top of that, my first task was to create the foundation of our enemy AI, probably the most critical gameplay element after the player and level design, and I haven’t touched AI in Unreal outside the absolute basics! However, I was determined to make my team proud and confident in my ability to learn quickly...
Post a Comment
Read more

Idle WitchCraft Sprint 4

  This sprint, I started by implementing alternate success conditions for certain scenarios. This means that for some scenarios, there will be multiple different stat checks that can lead to different outcomes, and potentially different scenarios down the line. Two different outcomes of the scholar’s exam scenario. One for high intelligence, and one for high charm! This was an interesting programming challenge, as I had to figure out how to associate these alternate conditions with the data table that is currently holding all the scenario information. The interesting thing about these alternative outcomes is that they function as almost half a scenario. They have no intro dialogue, but they do have a unique stat check, outcome dialogue, and list of scenarios to unlock on success. Because of this, I decided that I would copy the current scenario into a new struct. That way, I could “swap out” certain pieces of data at runtime without having to fill my data table with duplicate inf...
Post a Comment
Read more