OnTheFly Creations

After a year and a half of working on my mobile game, I am taking a much needed break and I’m using my newfound coding knowledge on a new project.

I am challenging myself to build an app from scratch and publish it on the App Store within 7 days. This is the polar opposite of my current situation being 16 months into development on a game, and I am hoping I will learn a lot from it. This is all inspired by a video from Your Average Tech Bro where he talked about shipping apps as fast as possible. His philosophy revolves around failing fast and iterating. You don’t need to build something original, or perfect, or even good. You just need to build and ship something and it can be improved later.

So I am now 48 hours into my new project “AutoTalk”, an app designed to be a conversational AI purpose built for helping brainstorm and organize thoughts while driving.

Every morning I open ChatGPT before my commute and use the speech to text feature to talk to myself and have AI make sense of my thoughts and ramblings. The issue is that I have to press 6 different buttons that are all extremely open a chat, start/stop recording, send the message, wait for the response, then press and hold, and finally tap ‘Read Aloud’ on the response. Most of the time I have to wait until a stop light because the buttons are so tiny.

I will acknowledge that ChatGPT has a conversational AI feature, but it is very painful to use. It is not built to listen for long periods of time, in fact if you are silent for more than a second or two it will cut you off before you finish what you were saying. It is a very frustrating experience.

The app I am building is designed to be used in the car. From opening the app to getting a verbal response it is 2 buttons that are large enough to tap without even looking at your phone. It leverages OpenAI API for the responses and text to speech, though I will explore other TTS options post launch to reduce cost.

Day 1 I completed a proof of concept on the client side building the base UI, making calls to ChatGPT and generating TTS audio that is read aloud. I was also very proud of the waveform showing the input volume (thanks ChatGPT for that code).

Day 2 I moved all of the API calls for ChatGPT and TTS to a server side application. I set up a database with Supabase for the first time as well so I could track users and how many credits they have. I implemented the API handlers on the client side and got it all hooked up. End of day 2 I can record input, send it to the server for processing, deduct credits based on input/output character count, and return the TTS audio back to the client.

Day 3 and beyond I’ll move into building the in app purchase system for adding credits, implement conversation history, and refine the UI.

Below is a screenshot after day 2.

Over the next few months I’m going to provide updates more frequently as we get closer to the tentative release date of October 1st.

These past two weeks I’ve focused on building a solid foundation for combat by adding a number of new effects. I also sprinkled in some UI work to make combat feel better, though I have some more plans to further improve it.

I’ve also recorded the first gameplay video showing off some of these combat effects as well as the inventory and ability systems here:

Combat Effects:

• Damage
  • Standard damage that reduces the targets HP
• Heal
  • Standard heal that increases the targets HP
• Poison
  • Deals a set damage amount repeating over a number of turns
• Execute Damage
  • Deals damage that is increased by the amount of missing health
• Lifesteal
  • Deals damage to the target and heals the caster
• Stun
  • Prevents the target from using abilities for a set number of turns
• Shield
  • Absorbs incoming damage
• Damage Reflect
  • When attacked a portion of damage dealt is reflected back
• Cleanse
  • Reduces the duration of negative effects
• Bleed
  • Reduces the effectiveness of healing on the target
• Level Changes
  • Any of the 6 skills can be increased/decreased by an effect

I have plans for more combat effects later on. I’ve built a solid framework for these effects so it will not be very difficult to add in new ones when I come around to it. For now though, I’m happy with the effects listed above and I’m eager to get back to working on the dungeon mechanics

Combat UI Improvements:

On top of the combat effects I made some tweaks to the way the combat events display.

• There is a longer delay between the player executed and mob executed events, so it’s easier to distinguish where the effects are coming from
• Damage is no longer always red – poison damage is purple, damage reflect damage is orange, etc. This makes it easier to identify the source of the damage

What’s Next:

My primary goal now is to complete the core dungeon gameplay loop. There are a couple milestones I need to reach for that to happen:

1. Add at least 3 new types of dungeon rooms (treasure room, trap room, restoration room, possibly others)
2. Add an end of dungeon chest that contains loot
3. Add combat XP gained from mob battles
4. Modify equipment to to have ATK and DEF stats for each skill
5. Implement equipment bonuses into combat effect calculations

This is an ambitious list that will likely take 4+ weeks to get through. I’m going to give myself 2 weeks for the dungeon rooms and take things from there. With any luck I’ll knock of the dungeon chest too.

Last post I wrote that I expected it to take 6 weeks to complete the core gameplay loop. After the first 72 hours and several hyper-focused coding sessions I managed to complete it. Rather than publishing a new dev blog 3 days after the last, I took the next 5 weeks to improve the UI with the goal of finally showing some of the gameplay. I’m happy to have finally reached that point, and I also spent some time improving combat which you’ll see below.

Dungeons

My initial goal as I outlined in the last post was to create the concept of Dungeons. This is where the core gameplay takes place, each dungeon consists of 3+ floors, each floor has several rooms that the player progresses through. Rooms primarily lead to enemies to defeat, with the occasional trap, treasure, restoration point, and possibly other things later on.

Currently I’ve implemented two types of rooms:

• Standard mob rooms
  • The player will need to defeat 1-3 mobs to continue on
• Floor Boss rooms
  • Floor Boss mobs are more difficult and allow the player to descend to the next floor

After each room is complete the player will be able to select which path they’d like to take. Visual indicators will give players an idea of what lies ahead – such as a red glow on floor/dungeon boss rooms.

Combat

Previously combat was limited to a single enemy. Once the enemy was defeated, the player was taken to the loot screen where they could see the XP gained and loot from the enemy. That has been changed and now the player will face between 1 and 3 mobs before the loot screen appears. This allows more time for combat, while still breaking it up periodically to view the progress and items gained.

Cooldowns have also been added to abilities for both the player and the mobs. This was a bit more complicated than I expected, mostly due to handling when all abilities are on cooldown. This causes the player or mob who has no available abilities to ‘wait’ until an ability becomes available while the other can continue to attack.

This led me down the path of implementing ability selection for the mobs as well. They now have their own pool of 5 abilities to choose from. Right now their ability selection is random but I will eventually add some intelligence to it to ensure their actions make sense (ie: don’t heal when you have full HP).

Finally for combat, I implemented the Shield effect type. This allows the player or mob to gain a shield equal to a percent of the max HP for a set amount of turns. Shield will not stack to prevent any crazy infinite shielding. You can see an example of a shield ability used in the image.

UI Improvements

After spending so much time on the back end work implementing dungeons and combat systems I wanted to have something to visually show for it. I decided to spend a good amount of time selecting a color palette and creating some decent looking UI/UX for the major screens I’ve been building.

As I began to update the UI I realized that hardcoding frame sizes wouldn’t scale with different screen sizes for iPhone Max, iPad, etc. I spent some time to rework all the UI elements to not only look better, but also scale based on screen width/height instead of a fixed value.

For colors I went with two palettes: the first is lighter, with a focus on brown/tan/white tones, the second is darker with a focus on black and gray (grey?) colors. I want to convey a happier feeling when you’re outside of the dungeons visiting the shops, checking on quest progress, etc. When you enter the dungeon I want players to feel a more serious, almost dangerous tone. I may change how the inventory and ability selection screens appear to have a ‘dark’ version when the player is in the dungeon.

What’s next

I’m going to continue working on the combat systems over the next few weeks. There are several combat effects I want to add including life steal, stun, healing reduction, execute damage/heal, and damage reflection. I want to make the combat as engaging as possible early on so I can build the game around it.

Once the combat effects are completed I’ll move onto adding in additional dungeon rooms. Treasure, traps, and restoration points are the main three I have in mind. I’d also like to implement an end of dungeon treasure chest that has some exclusive loot to really incentivize completing the dungeons. I have ideas for other rooms – things like hidden areas with mysterious enemies, NPC interactions that provide exclusive quests or trade rare items. For now I’ll focus in on combat effects, hopefully in another 4 weeks those will be completed and I’ll be able to start those dungeon rooms.

We’re 4 weeks past the last dev blog and progress has been steady, I’ve completed the inventory system along with a few bonus items.

Inventory

Player inventories consist of 28 slots, plus 8 equipment slots:

• Weapon
• Shield
• Amulet
• Ring
• Head
• Chest
• Leg
• Boot

Items can be equipped and removed. Inventory items can be destroyed, and stackable items like coins will stack. For better inventory management you can drag and drop items to new slots.

I haven’t decided if there will be extra storage like a player ‘bank’ for extra inventory slots. That can always be added later on if needed.

Lastly, when a mob dies it will show the loot dropped and you can add it directly to the inventory.

Abilities

As I wrote in the last post there will be 6 player skills, and every ability will belong to one of the 6 skills.

I’ve implemented a new tab to view the currently usable abilities, and equip/remove them. The abilities are grouped by skill in separate collapsible sections. I didn’t implement drag/drop swapping for the 5 ability slots, but I may get to it later on.

Art

The art style is something I have been debating since this project began. I am nowhere near artistic, so my initial plan was to use AI to generate images to represent the monsters and items. That kind of worked, but the images took a while to get right, and often looked too realistic – see the image in dev blog #2 as an example.

The past few weeks I’ve instead been looking into buying art and have found the perfect fit. An art studio named A-ravlik creates amazing 2d game assets, and I’ve just purchased 300 of their characters for use in the game. Here’s a couple examples:

What’s Next

The next stage in development is to implement the dungeons, which will act as the core gameplay loop. I’ve decided on a linear progression, where players will need to complete a dungeon before moving onto the next.

Each dungeon will have several floors, each consisting of different room types. Most rooms will involve combat, but the others will consist of traps, treasure, NPC interaction, restoration rooms, and possibly hidden areas. Each floor will have a boss, with a final dungeon boss at the end.

Combat is being slightly changed to support multiple enemies in a single encounter. Right now it will be sequential – defeat the first to fight the second – but I may change it so they swap in/out during combat.

This is a large chunk of the project and will require lots of backend changes to support the different room types and encounters. I’m hoping to have 3 room types and the combat rework completed in 6 weeks time. With any luck, I’ll be posting here sooner.

Since I wrote the last blog post 10 weeks ago I’ve made massive progress on the game. To start, I built the foundation of the combat system in the app with 4 ‘effects’: damage, heal, ongoing damage/heal, and level buffs/debuffs. I also settled on 6 skill levels that will be trained through combat and will determine combat ability effectiveness. Those are Health, Strength, Magic, Dexterity, Defense, and Faith. I’d like to consider non-combat skills at some point, but I haven’t worked out how to implement them into the game, so for now I’m shelving the idea. The chart below outlines the combat actions and how they align to the skills, a solid outline means it is already implemented.

You’ll also notice abilities can be learned permanently once you acquire and consume an ability codex. Equipment can also provide abilities, but you can only use those when are wearing the equipment. Generally equipment’s primary function is to provide stat boosts.

After designing and implementing this whole system at the app level, I realized I would need a different approach if I ever wanted to support multiplayer. That led me down a very deep rabbit hole of learning about server side swift (thank you Kodeco for your ebook), database management, and secure APIs.

To start, I built a whole server side application to receive API requests from the app. Then I added Apple ID authentication to create, store, and load user profiles in the database. Finally, I rebuilt the entire combat system on the server side which took the longest by far. This process was an uphill battle in unknown territory, almost every day I was learning new concepts as I waded through error after error in my code.

Now that I’ve finished implementing the battle system, I’m moving into managing the mob drops and user inventory on the server side. With any luck this won’t take more than 4 weeks and I can get back to designing the UI.

It’s been about 3 weeks since my first blog and I’m happy to report that there has been a ton of progress made on the project. The game has taken a slightly different direction that I initially planned, and I think the gameplay will be much more enjoyable this way.

As I began this project I found and downloaded many different text-based RPGs – Eldrum, BurniedBornes, and a few others that have seen success. I decided to ditch the grid-based combat in favor of a 1v1 turned based system (think Pokemon) that BuriedBornes pulls off very well. Additionally, I really like how BuriedBornes has a simple combat system – 1-5 abilities the player can use in battle with ability cooldowns to prevent spamming overpowered moves. I’ve pulled a lot of inspiration from the game design of BuriedBornes as you can tell.

However, BuriedBornes is a roguelike rpg where you crawl through the dungeons to see how deep you can get before you die. Death is permanent and nothing you acquire in the dungeon item-wise stays with you after death. I’d like my game (that I’ve still yet to name) to be more like a runescape MMO where you progress your skills, acquire items, grow more powerful, and fight in PvP arenas.

As a unique element, players will obtain abilities from the items they find and equip. You can choose 5 abilities from the full list that your equipment provides, and change them at any time outside of combat. Poisoned daggers will give poison abilities, fire tomes will allow you to cast fire spells, blessed tunics allow the player to use healing abilities. I think it’s a fun system and something that I haven’t seen before.

Outside of combat, the player will be able to explore regions – inside the regions will be one or more towns where they can shop for items, change abilities, and obtain jobs or quests (still figuring that out). Players can explore the region wilderness outside of the town to discover dungeons for good loot, or resource areas for non-combat skills.

I’ve spent a lot of time on UI work, just to understand what is possible on screen and get an MVP for the visual layout. I’m using a lot of AI generated artwork for mob images and ability icons. Over the next week or two I’ll be going the other direction and working on the underlying combat systems to get a working gameplay loop.

I think that sums up the progress so far. This has been a huge learning curve as I’m building this fully in SwiftUI and have never touched iOS development before. The more I learn the faster I can build, so I’m looking forward to the progress we’ll see on the next dev blog. Finally, here’s a screenshot of the current combat system:

I’m writing this blog while my girlfriend snores next to me to hold myself accountable to a new project. I’ve decided to create a mobile game, a modernized MUD-like multiplayer game to be more specific.

I’m no stranger to programming (though no expert either), I’ve sat through college courses on C#, python, Java, database structures, and so on. Nor am I unfamiliar with games, having played more than my fair share as well as hosting private runescape servers and attempting to follow youtube tutorials to make web based games.

Today I work as a product manager for a cyber security platform. I like to create and build things, but I’m cursed with a logical brain and lack any artistic ability. I think that’s why I’m so drawn to these text-based games. They have little to no imagery or visuals yet I still feel the dopamine release when I watch the stat or gold numbers climb higher. I find myself playing these games and thinking “I could build this”.

The true catalyst was last night, when I downloaded an iOS game called “Warriors and Adventure”. It’s an overly complex idle RPG that was clearly translated to English from somewhere in Asia. It’s P2W, contains 8+ in game currencies, microtransactions galore, and you find yourself clicking a “claim” button 10 times to accumulate prizes and gold every time you open the app.

I was initially excited by the game, the ad showed it as a simple text-based RPG. You had standard classes: Mage, Ranged, Warrior. Skills, gold, gear, all the staples of a fantasy RPG. The combat was a 6×6 grid-based system, where your character attacks any mobs that appear in the grid squares bordering its own. You move around to new locations (new 6×6 grids) by clicking the location name in the map, and there’s towns with shops and everything else you’d expect.

The core system was simple yet fun. A few flashy animations for attacks but the rest was text. Again I found myself thinking “I could build this.. I could design this better”. So I decided I would.

I have no game design document. I’m entirely winging this process with a loose idea of the core components I want to implement, but for now it feels like it’s enough. I’ve been caught in analysis paralysis before, overthinking projects and never completing them. This time I’ve taken the opposite approach. I dusted off my Macbook, spent a few hours googling SwiftUI, and mocked up an interface for the game.

There’s no functionality built, just the bare bones structure to something that will hopefully one day be a fun and interactive game. I’ll continue to post my progress and struggles designing this game, if nothing else to keep myself accountable to push forward. With all that said, here’s a picture of Day 1.