Cafe Amore

March 2023 - June 2023 | Godot 3.5| 3 developer team

Game designer, Programmer, Sound Designer, Composer

Description

Cafe Amore is a 2D isometric Cafe management game where you work as a barista to take customers' orders and make the items they request. As you work, you may find some frequent customers who use the space to chat with others or meet new people. Through working for multiple days, you can have a chance to listen in and see how those customers are changing over time.

Cafe Amore was made for my Game Design Experience class as UC Santa Cruz in the spring quarter of 2023. The game is available to be played here.

Difficulties with Perspective

When our group began production for Cafe Amore, we initially planned for the game to take place in a 2D perspective. We changed the game to utilize a 2D isometric viewpoint, however, as we felt it would be more visually appealing and give the game a more distinctive art style.

The problem that took a lot of effort to solve was figuring out how to implement an isometric viewpoint in Godot. At the time of developing the game, Godot 4 had been publicly released for a little over a month, so there were few resources to work off of. A lot of tutorials had been depreciated, and so much of the engine had changed that thorough documentation was sparce. The two main concerns of implementation were figuring out z-sorting and detecting where special tiles were on the tilemap.

Movement

For the movement of the game, we wanted to utilize tile-based movement and have the player character snap to squares on a grid as they move about the room. That led to many possibilities as to how to implement the movement.

Initially, I attempted to use a point-and-click method where clicking on the desired square would move the player using A* pathfinding. I struggled with this, as a lot of existing tools used to expedite the process of utilizing A* pathfinding were depreciated since the switch to Godot 4. Not only this, but our group was aiming to target inputs with the keyboard, so having to control the game with keyboard input and mouse input would have been disorienting for players.

The solution I implemented was movement using finite state machines. The character controller would naturally stay at an idle state and wait until the player makes an input. The controller is then set to the moving state where it linearly interpolates between the current position and the destination position. Upon reaching the destination, the player input is checked again, if the player is moving, repeat the moving state, if not, revert to the idle state. The result is a convincing form of tile-based movement.

* Flowchart for player movement state machine

* The player moves as a result of a finite state machine

Another challenging aspect involving movement was handing collision. It wasn't feasible to have the player collide with level boundaries while they move, as linearly interpolating the player's position doesn't consider physics collisions. I needed a way to know that a collision would happen before the player would be allowed to move.

To do this, I used raycasts that pointed to the nearest adjacent tiles around the player. Before the idle state would be allowed to transition into the moving state, it would check to see if the raycast would collide with any obstacles. If there were no obstacles, the player moves like normal, but if there were obstacles, the player stays in the idle state.

* The lines underneath the player show how raycasts detect possible collision

* The blue squares represent the obstacle collisions

Contributions and Lessons Learned

In this project, I was the lead programmer, lead sound designer, and lead for quality assurance. This was my first big project working with a team and there were many things I learned about the game design process. The biggest thing I learned is the importance of maintaining constant communication and giving more reverence to deadlines and timetables. Since I was not working by myself, I needed to stay in contact with my group to ensure this project was the culmination of every person's vision for the game. As such, we utilized a production schedule to keep everyone accountable and met after class times to discuss progress and other comments related to the game.

As the only programmer, this project has strengthened my ability to effectively read documentation and understand better programming practices better. It's easy to find tutorials for most topics, but working in an engine that was still relatively fresh caused me to rely more on the Godot documentation to know what's relevant for a particular issue and to use the information given to come to my own conclusion on how a given framework should work. Often as a computer scientist (especially when working with large, pre-existing codebases and API) we must parse through documentation or code, and I'd say my ability to conceptually understand how a system works without having a tutorial explicitly explain it has been strengthened by this experience.

This was my first project where I provided sound design and composition for a game. The hardest part of the experience for me was learning the best ways to create music to fit a scenario or to match a vibe. I ended up making several iterations of a song to tweak its instrumentation and style to find one that matched the best for the game. Once I found one, I mainly found inspiration for the soundtrack by finding chord progressions I thought sounded interesting and experimented with sounds I thought I'd like.

Most importantly, I learned the most about working in a group. Good communication is what makes or breaks a project, and this first foray was good exposure to understand how important that is. Having good pre-production saves so many exhausting hours of planning as you go, which is something our group learned the hard way. We initially weren't as communicative in the first quarter of the production cycle, and that became a problem later when a lot of logistical issues weren't hammered out before. As an example, we wanted to include a money mechanic to the game which would act as another layer of depth to the gameplay, but we never fully discussed how we would implement it, and we figured we would know how to after starting development. To the surprise of no one, that time to instinctively know how to figure it out never came, and it was too late into development to try to ideate a new mechanic that would've been an essential mechanic, so it was scrapped. Communication is definitely the strongest skill to have on any game development team.

Gallery

Page updated

Google Sites

Report abuse