Play Tio Omitli now!

This was the first game jam my sister (Susie) and I participated in together. This was her first completed game project, so congrats Susie! I worked on the usual: code, art, audio, game design, and dialogue/narrative design. Susie helped with around half of the narrative design. We used Unity with the Dialogue System by a friend of mine, Tony Li. I couldn’t have done this game without Tony’s hard work to build such a great system. If you’re a game developer, I strongly recommend using it for your Unity games, too.

Just Play Game Jam for Justice

The theme of this game jam was “justice” with additional sub-themes. I won’t list them all, but we approached the project with the following in mind: justice, narrative, community, social impact, spirituality, and post-colonial. The rules were fairly standard for game jams, the most common being to use new assets/works. Existing games were excluded from the main competition.

It got me excited to find out this jam was all about justice, narrative, and community. My primary project Over Many Waters (OMW) is mostly a seafaring RPG, but strong elements of community building will persist throughout the game. Approaching the game jam, I wanted to create a sort of spin-off to OMW so that I could recycle most or all of the assets created for Tio Omitli back into OMW.

You can read more about Tio Omitli’s intentions, gameplay, and design on the game’s Itch.io page.

Success Story

This was my best and favorite game jam project. I hope the world feels the same way. Regardless, I feel almost everything went according to plan. Using draw.io’s workflow diagram as a collab and idea board, we scoped out the project and followed a daily plan. With our Discord channel, we shared updates, files, wips, and ideas. We did have another member on the team when we started, but that individual became overwhelmed with previous commitments and dropped out. I was a little upset, since they participated in some of the meetings, but contributed zero.

I don’t have to drag this post on any longer, so I’ll end about here. The project went well. I’m happy with it. Everything you need to know about Tio Omitli and the game jam is right here on the itch page. Go check it out and let me know what you think. Thanks!

The post Tio Omitli -Game Jam Postmortem appeared first on MultiMediaVerse.

Your first game hint is to try playing the game again. It’s only going to take a minute or two if you’re playing as of January 2024 or we haven’t added any updates since then.

Last chance to try it on your own one more time…

Okay, I’ll spill the beans already.

While the game is all about bringing people together, you can easily make someone’s life more difficult on accident. The social impact you have on our game’s characters is moderately complex. There are secret endings that will only happen if you do not win the game. Some characters will inevitably die young despite your best efforts. In at least two scenarios, a random result may occur. We designed the game to demonstrate how complex social engagement are, especially when ideas like racism and social inequality are present. So don’t be discouraged if you can’t truly beat the game.

Since you’re still here looking for a clue, I’ll give you one. The most important Tio Omitli game hint is knowing when you’ve beat the game, for real. At the end, Aluxe will come close to breaking the fourth wall and hinting at the fact you’re “playing a game” and have won. That’s when you’ll get completionist level confirmation.

Impacting the People of Mexico City

It’s important to speak with all seven of the citizens: Eztli, Maria & Mateo, Santiago, Taltomi, Calantzi, and Itzacli. Notice Javier is excluded from this list? His happiness depends directly on the happiness of his friends, the citizens of Mexico City. To make Javier happy, you can avoid endangering the people, embolden them to sooth cultural differences, and generally steer them away from difficulties.

It’s not going to be easy, but remember it’s designed that way to reflect real life. There are even secret endings, so look out for them. You might get one of the characters to kill another or Javier could marry one of the other characters. Those two results are pretty rare, but they make for fun twists.

I do hope you enjoy the game. You should note your results and share them with me on Discord or Instagram. If you’d like this prototype to become a full game with quests, encounters, and all the other features, please let us know on the Itch page. Either way, we look forward to hearing your thoughts on the project. Thanks for playing!

The post Tio Omitli Game Hints appeared first on MultiMediaVerse.

Backstory

A week before Brackey’s Jam 23 I had no intentions of working a game jam, but a few pals were interested and that was enough to get me involved. Becoming entrenched in the week-long Brackey’s Jam 23 tested team determination, experience, cohesion, and strategies against our collective intentions behind the jam. We came together with the goal of completing a viable game loop with the jam theme “Diving Deeper”. During our initial design and feature meeting we devised a plan to build a game now titled “Ragnar’s Rock”, a game about an asteroid mining, space-dwarf wielding a throwable hammer. 

Half of the eight-person team joined a day prior to the jam. Everyone had met one another previously, either in person or virtually. Our collective skillsets included audio engineering, programming across multiple game engines, project management, game design, and art/animation. For privacy purposes, I will refer to member functions/roles only. 

Having determined as a group that we would start the project as a 2D Top-Down game, daringly using Unreal Engine 5 as a foundation, we were all in agreement on the initialization of the project. I know UE5 is a massive 3D engine, but we were agreeably open to the challenge and learning experience, which we will soon dive into more.

Our scope was quickly framed out by the team and road-mapped quite formidably by our lead project manager. A GIT repo had been established prior to the start of the project and merge strategies were discussed at that point as well. We had a solid foundation to start the project. As a team, we agreed to create a space-mining, 2D top-down, complete with 10 levels, a single common enemy, a boss battle, a simple GUI to display HP and the quantity of gold collected, a mining hammer, and a lite upgrade screen between levels. This hastily gathered team had immediate chemistry, outstanding communication, and a strong sense of unity on roles and scope. 

Results

Despite our best intentions and greatest effort we did not complete Ragnar’s Rock in time to submit a game for Brackey’s Jam 23. I spoiled the result of the jam early in this post to help you understand the context moving forward. Everyone worked really hard on this project and each member respectively produced outstanding work. So why did the project fall short of meeting the scoped-out, road-mapped features? I’ll explain all of that shortly. First, I want you to know that despite having missed our deadline, I would work with any one of these members again with sharper focus and stronger frameworks for success. More time would have helped too, but it’s a game jam. They’re intentionally short. Yet another spoiler, the good news is that we do intend to complete the game and publish it publicly on itch.io. 

What Went Right

I feel we went in the right direction on the game theme of Diving Deeper by having 10 mining levels. Where most developers would immediately go towards the obvious water diving parallel, early into ideation I had my fingers crossed that our team would not succumb to a water-based game theme direction. Members arrived at the decision to create a dwarven mining game with a vote of 5 for the miner game, 2 for a magic schoolbus-inspired game, and 1 no-vote due to absence. We established and agreed upon the theme and scope from the start, making the game development fun and motivating all team members to see it through. We were all constantly excited to see our character smash space rocks and defeat a nasty big bad. That synchronous spirit fueled cohesion and determination.

Out of our team of eight, several members had worked together before. From day one, we established the feature set for Ragnar’s Rock and quickly assigned roles. Some members had cross-roles, such as a programmer who would dual purpose as an artist. Moving into development, each member consented to their roles and tasks. There was no doubt about it.

The lead engineer on the team proved his experience in UE5 and was able to strategize building a 2D game in such a massive 3D engine. As the first member I recruited, it was his choice to use UE5 and thus his responsibility to live up to engineering the 2D world within. He quickly rangled together the powers of Paper2D and PaperZD in UE5 and with some of my old game art from another project, we had a defacto prototype. 

I served as an alternate engineer along with our lead and two other members. One of our four engineers had no significant Unreal Engine experience. It’s impressive how swiftly he picked up on UE5. The character artist did an amazing job at an eight-direction character animation. Tileset textures by the environment artist were second to none and he put together a terrifying boss enemy! I was happy that the same artist working on the environment was also working on the enemy because Ragnar’s Rock was all about a space miner trying to survive the domain of this creepy spider queen while trying to do his work as a miner. I also did level design, and character grunts for SFX, and I led the initiative on GIT version control. The audio works were impressive and just as spooky as you would hope for in a deep-space, bug-infested asteroid miner game. Props to the entire creative team for producing standout, original content for this short-term project. 

What Went Wrong

TL;DR Git version control! The stuff of nightmares!

The real story behind our shortcomings is all in the Git. I personally bear the responsibility of falling short of strong Git reinforcement. However, despite my best intentions and best efforts to encourage good practices, the hard truth is that every engineer defied those intentions. Sidenote to my team: I’m sorry boys, this is the hard truth of the matter. Forgive me in advance. This is what this reflection is all about, right? I truly wish we were tighter with version control. 

Stepping back just a bit, it’s fair to mention that I’m an asphalt contractor full-time and my hobby game dev projects are a lower priority than running a business to provide for my family. Unfortunately for Ragnar’s Rock, I simultaneously started a 10-day project last week. Initially, I beat myself up thinking the frontload of the project could have used my guidance and aid a bit more. Retrospectively, it’s only partially true. I could have spent more time directing the engineering team on Git repo best practices. Despite the strong start, team members discarded the initial branch strategies and feature ownership halfway through the project.

Engineering members were outspokenly determined to work on the same features, down to manipulating the same file on separate branches asynchronously. Reflecting on the fact that I am still a rookie, I approached two external sources to discuss whether or not our merge strategies were solid. So far, the standard practice appears to be as follows: Establish who owns each feature. Map out how each feature will interact with all other features and who needs access to those features’ scripts/code. Determine how the logic will connect through encapsulation so as not to be forced to manipulate the contents of files you do not own. If you need more functionality or cannot move on without some work done on a feature you do not own, reach out to the owner and discuss strategies. Finally, commit and merge often to ensure everyone is current and the project features play nice when merged. 

During development, we encountered several conflicts. I held meetings to remedy these conflicts, but the demand of attending to these issues and other acute matters weighed heavy on myself and the lead engineer. Eventually, the team outright rejected and abandoned the use of Git. If you know anything about Git and why you use it you may know what happened next. Sharing files over Google Drive on the last working day caused an inexplicable loss of my work and personally, I lost the motivation to continue. Feature creep was another leading factor in our demise.  

The only other hitch we had was in character art. Our character artist worked longer than expected on the main character and burned out, rendering himself unable to complete the enemies and boss. Our environment artist took up his torch and finished strong with a bone-chilling queen spider boss and fantastic title cover art. 

I can’t directly accuse communication failure of being a culprit in our shortcomings, but we could have used a tighter agreement on execution. Overall, members fulfilled their roles and responsibilities. If you asked anyone about our communication, they would confirm that we met regularly and discussed issues promptly via Discord. We simply lost too much time dealing with merge conflicts and feature creep. 

Takeaway

It’s safe to stick to your lane sometimes, but you have to push the boundaries to grow. We started this project in UE5 because some of the initial members had experience in the engine and we did a 2D game because all members had experience with 2D. However, I personally will not be working with 2D games in UE5 in the future. For 2D top-down games, I will continue in Unity. The next jam I do with Unreal will be exclusively with 3D assets, which I’m comfortable with creating and texturing. 

I will definitely be working with members of this team again. I don’t see any reason not to. Understandably, some of us got a little overambitious towards the end and Git got us pretty bad. Each member of Ragnar’s Rock rocked hard! Each member of my team had a skill set I would like to see in action again. Next time I take charge as a team lead or a project manager, I promise I’ll be a stronger leader. I hope each member felt supported by me during this jam. Even though I am still learning, I wanted to serve the team as a guiding light and a resource. See you all on the next one. 

The post Brackey’s Jam 23 Postmortem Reflection appeared first on MultiMediaVerse.

Better late than never, but here’s a defacto, mini-postmortem on my game development project called Super Nuclear Speed Racing (SNSR). You can play SNSR within minutes if you warp on over to the Google Play Store and download that sweet hyperdrive for a test run yourself.

Developing this little indie game was a blast! I challenged myself to pop out a game in less than 24 hours and try for a Google Play upload. It worked! I know I sound surprised, but hey it was my first attempt and when I found out it got accepted and approved, I flipped. Now, I’m more confident in my game development ability and I’m eager to go bigger. I believe I can go much, much bigger, to a new galaxy, not too far away. See Over Many Waters, the project I’m currently working on.

As for SNSR, I think I’m completely ok never updating the little guy again, but if I somehow find myself opening my front door to a press mob begging to find out when SNSR 2 will release, I’ll be a crowd-pleaser. I’m being cheeky of course, but I would continue development if at least a handful of folks wanted to see more from SNSR.

A Game of Intergalactic Dodgeball

A little backstory to this game: I scraped some code from an older, less fortunate game dev project I codenamed “Pexels”. That poor Tamagachi knockoff flopped horribly. It was one of my first Unity projects and I struggled to see it all the way through. The sheer amount of bugs to squash scared me off.

A mini-game I built within Pexels involved the player character dodging dodgeballs that fell from the sky. When you play SNSR you’ll see it. I just swapped the dodgeballs for asteroids and created a spaceship to track mobile touch feedback. Now I have my first completed game released on Google Play! Keep in touch with me for more updates and check out our stories and devlogs.

The post Super Nuclear Speed Racing – Game Devlog appeared first on MultiMediaVerse.