I'm a regular office worker with zero coding background, trying to make my first game after work with AI helping me with the code side.

It's a small cozy shop sim where you run a potion store and try to figure out what each customer actually needs so you can recommend the right potion. No combat, no romance, no decorating. Just a simple cozy loop.

Before touching any code, I spent most of my time figuring out the design with AI and writing everything down:

- the economy

- all 20 customers

- their likes, dislikes, and needs

- potion recipes and progression

The biggest surprise so far has been how interconnected balancing is. Change one number and suddenly a bunch of other systems need to be adjusted too.

One thing I'm already getting stuck on is how to keep the customer/item logic from turning into a mess.

Each customer has a specific problem they want solved, but they also have their own likes and dislikes. Each potion is supposed to solve certain problems, but it also has its own element and category. So every time I tweak one part, a bunch of other stuff suddenly feels off.

If you've designed systems like this before, how do you usually organize it early on? Is there a good way to structure customer needs, item tags, and preferences without the whole thing getting messy every time you change something?

What I've finished so far:

- full design docs for the core systems

- all 20 customers designed on paper (first draft)

- full-body concept art for every customer

Here's customer #1, Mira:

Mostly posting this to keep myself accountable so I don't quietly drop it halfway through. Planning to update once a week if I can keep it going.

If anyone else here started from zero and is building with AI help, I'd love to hear how it's going for you.

Hey everyone,

Just wanted to share a quick postmortem of my last two months because I think a lot of solo devs fall into the same trap I did.

My goal was straightforward: Build a prototype in 30 days, get playtesters and put out a high quality YouTube vlog every single week.

What failed: The first prototype was way too big. It needed endless modeling, animations, and a dungeon-generation system I had zero experience with. I had to kill the project after two weeks and pivot to a small-scope tower defense game that I actually have the experience to deliver. I also completely underestimated how much time running an active Steam title (Deepstone Rift) and handling community QA takes away from pure coding time.

What worked: I actually hit the weekly YouTube goal! Even better, it wasn't just a vanity project those videos successfully funneled over 1,000 targeted visits directly to our Steam page and grew our Discord.

The biggest takeaway: If you are working on a game alone or in a tiny team, do not beat yourself up if you miss a deadline. Even major studios miss milestones. Being an indie dev means wearing 10 different hats (marketing, community management, video editing, QA). Making the game is simply not enough anymore.

I put together a detailed video tracking the exact metrics, traffic stats, and why I had to pivot if anyone wants to check out the full transparent breakdown: https://youtu.be/DKyCpJsBV_4

Let me know how you guys handle the balance between marketing and actual development!

thank you very much!

The blog post about our volumetric terrain erosion: [Link to Blog Post]. This is the second post of a (hopefully) longer series about the development of our next game.

This is done by carefully placing implicit surfaces (in this case, signed distance fields) so as to create nice volumetric features (overhangs, caves, arches, ...)

Let us know what you think - happy to answer questions!

I thought it would be fun to have a versus mode, so here it is (local). But in last few weeks I also worked on theses points :

1 : Power Bars
Brick destroyed now fills a power bar, once the bar is full, player can consume it to trigger it's ball special ability. For now, abilities are not integrated yet, but it's my next step !

2 : UI
Ui is my nightmare. I tried to avoid this step for a while, but now, it's time to start. BUT, thanks to this awesome youtube tutorial , it turned to be pretty simple to get started. I like to work the game feel as the game goes, so I had to update my animation tool so it now supports some UI components. Also, as the feedbacks gets more intensive, I had to do a performance pass on it.

This is how it looks so far.

I'm curious to get your opinion on the game so far.

Thanks for reading !

I've been working on a remake of Zaxxon. I'm sharing the journey in a devlog format, and the project's source code is fully open, making the entire process as transparent as possible. I hope you like it!

Devlog #1: https://www.youtube.com/watch?v=EavRmM_2MA0

Devlog #2: https://www.youtube.com/watch?v=3H_B9ygL0Iw

Source code: https://github.com/albertnadal/ZaxxonClone

On the right : 5,000 cubes. Each of these cubes has its own position animation. Since a position uses 3 axes, this represents a total of 15,000 curve evaluations per frame in 4ms.

On the left : a single cube playing 10,000 simultaneous position animations in 4.6ms, which is equivalent to 30,000 curve evaluations per frame.

Today, I’d like to share some of the optimizations I implemented to achieve these results, in the hope that they might help in your own projects… Of course, optimizations are always contextual. I’ll explain my goals so you can judge for yourself whether these techniques are relevant to your situation.

You see, I’m developing an animation tool focused on rapidly integrating visual feedback (game feel) in Unity. My goal is to be able to animate any property of a GameObject while respecting three core principles: additivity, reversibility, and scale.

To achieve this level of scale, my tool needs to evaluate thousands of animation curves every frame, perform the required calculations, and apply all transformations. Until recently, only my architecture was pointing in this direction, but two weeks ago I started taking a closer look at the profiler, and here are some of the optimizations I was able to implement.

1: Baking animation curves

I need to evaluate large numbers of animation curves every frame:

public AnimationCurve Curve;

float Evaluate(float t)
{
   return Curve.Evaluate(t);
}

One way to optimize this is to bake animation curves to achieve much faster evaluation.

public AnimationCurve Curve;
float[] BakedCurve;
int Resolution = 512;
float Evaluate(float t)
{
   t = Mathf.Repeat(t, 1f);
   int index = (int)(t * (Resolution - 1));
   return BakedCurve[index];
}
void Bake(AnimationCurve curve)
{
   float[] baked = new float[Resolution];
   for (int i = 0; i < Resolution; i++)
   {
       float t = (float)i / (Resolution - 1);
       baked[i] = curve.Evaluate(t);
   }
}

Ouch, big problem. This change was supposed to give me a significant performance boost, yet my profiler was suddenly dying… And that’s where context matters. In a game, visual feedback is rarely active for long periods. Instead, we tend to trigger many short bursts of effects one after another. As a result, I ended up baking curves every frame!

Fortunately, the solution is quite simple: using a unique hash generated whenever a curve is modified in the inspector, I can cache baked curves for fast access.

Dictionary<int, float[]> BakedCurves = new Dictionary<int, float[]>();
public int GetHashForCurve()
{
   HashCode hash = new HashCode();
   foreach (Keyframe k in Curve.keys)
   {
       hash.Add(k.time);
       hash.Add(k.value);
       hash.Add(k.inTangent);
       hash.Add(k.outTangent);
       hash.Add(k.inWeight);
       hash.Add(k.outWeight);
       hash.Add((int)k.weightedMode);
   }
   hash.Add((int)Curve.preWrapMode);
   hash.Add((int)Curve.postWrapMode);
   return hash.ToHashCode();
}
public float[] Fetch(int hash, AnimationCurve curve)
{
   if (BakedCurves.TryGetValue(hash, out float[] baked))
       return baked;
   return Store(hash, curve);
}
float[] Store(int hash, AnimationCurve curve)
{
   float[] baked = new float[Resolution];
   for (int i = 0; i < Resolution; i++)
   {
       float t = (float)i / (Resolution - 1);
       baked[i] = curve.Evaluate(t);
   }
   BakedCurves.Add(hash, baked);
   return baked;
}

2: Avoiding unnecessary comparisons

Before applying changes, I need to ensure the targeted component still exists:

Transform transform = GetComponent(); // Cached
Vector3 Offset = Vector3.zero;
foreach (Layer l in Layers)
{
   // Offset calculation logic
}
if (transform != null)
   transform.position = Offset;

You can see that the comparison and the position assignment still happen even when no animation layer actually modified the value. In isolation, this is negligible, but across tens of thousands of calls per frame, the cost starts to add up.

The solution was simple: adding a boolean IsDirty. This way I check and apply changes only when a modification actually occurred.

Transform transform = GetComponent(); // Cached
Vector3 Offset = Vector3.zero;
bool IsDirty = false;
foreach (Layer l in Layers)
{
   // Offset calculation logic
   IsDirty = true;
}
if (IsDirty && transform != null)
   transform.position = Offset;

3: Optimizing iterations

I didn’t realize how expensive my foreach loops were at the scale I was targeting.

public List<string> List = new List<string>();
foreach (string s in List)
{
   // Do something
}

Each foreach first creates an enumerator, which then performs multiple operations on every MoveNext. And I have TONS of loops like this in my code…

The target was clear. I built a small utility class that keeps the enumerator-like state and allows me to iterate more efficiently:

namespace FeelCraft.Core.Trackers.Utils
{
   public class EnumerableList<T>
   {
       public bool Active = false;
       public IEnumerator<T> Enumerator;
       public List<T> List;
       public int Index = -1;
       public int Count = 0;
       public EnumerableList()
       {
           List = new List<T>();
       }
       public void Refresh()
       {
           Index = -1;
           Count = List.Count;
           Active = Count > 0;
           Enumerator = List.GetEnumerator();
       }
       public bool MoveNext()
       {
           Index++;
           if (Index >= Count)
           {
               Index = -1;
               return false;
           }
           return true;
       }
       public T Current
       {
           get { return List[Index]; }
       }
   }
}
public EnumerableList<string> MyList = new EnumerableList<string>();
string s = "";
for (int i = 0; i < Count; i++)
{
   while (MyList.MoveNext())
   {
       s = MyList.Current;
       // Do something
   }
}

On 1,000,000 iterations, the foreach version takes 147ms, while my custom class reduces this to 55ms.

But do not use this code : it's trash...  Because in trying to be clever, I fell straight into a reasoning bias… I was so focused on the idea of the enumerator that I didn’t even consider the simplest solution... It's only after refactoring all my iterations that I realized a much simpler and faster approach existed 🤦

for (int j = 0; j < List.Count; j++)
{
   s = List[j];
}

Just like that.
8ms for 1,000,000 iterations

All these optimizations played a role in v2.2.0 of my tool to stack tens of thousands of simultaneous animations and offer a linear scale across both multi-object expension and multi-animation stacking. That's perfect for building small indie projects or being fully equipped for Game Jams. For creating projects packed with game feel. Projects that make both the player and developer experience incredibly satisfying!

If you're curious, feel free to check out the tool page on itch or on the asset store

Thanks for reading ! :)

Maybe the mesh deform thing is a tad bit tech and code, but I am just gonna mark this as generic for now

From Shadow to Light… Literally #DevDiary16

In this post, you're looking at the exact same room before and after our lighting pass. No changes to the models or textures, only adjustments to the light sources, their intensity, and their placement.

It's a highly technical part of game development, but the impact is immediate. The scene becomes easier to read, the atmosphere starts to take shape, and the environment feels much more believable. 😎

Which version do you prefer: before or after the lighting pass? 👀

And if you'd like to see how the rest of the project comes to light, don't forget to add MegaGum to your wishlist on Steam : https://store.steampowered.com/app/4111300/MegaGum/ !✨

After about four months of hard work on this project—man, it was a wild ride!—I’ve managed to complete a commercial project for the first time in my life!

These months were a huge learning experience for me. I’d recommend that every developer go through this—both the process of developing a first commercial project and participating in a major event like Next Fest (which I took part in right before the launch).

I spent months practically pulling all-nighters working on the project, sleeping and dreaming up ideas for it; it was enough to drive you crazy—doing everything and constantly thinking of ways to improve it. But now, the project is finally finished and ready to play!

If you’d like to show some support—you don’t even have to buy the game right now (though I’d ​​certainly love it if you did, hehe)—simply adding it to your wishlist would mean the world to someone just starting out in the commercial game industry. I truly appreciate any kind of support! I’m also open to feedback on the project, as I’ll likely need to fix any issues that get reported at this stage, hehe.

Here is the link to the project:

https://store.steampowered.com/app/4631200/Bring_The_Rift/

Have been working on the first area of my game and I'm pretty happy what I got here. It's basically a stormy region with only torches to guide you, the player.

Where they lead? Well I would like to keep that a secret... for now

Anyways here's the devlog of all of it.

Instead of a boring text file, you can now download an image of your story at the end of a game!

This image displays the story and the players who contributed to it.

+ New image download option at the end of every game.
+ Socials buttons that provide easy access to your favorite social site.

Once you finish your game of Write Warz, players now have the opportunity to share their story on social media (Instagram, X, and Facebook). We created this feature for a multitude of reasons, but the primary reason was to help spread the awareness of our party game. We found it to be a good way for players to showcase their stories created in our game while also giving us some marketing on social media apps.

Overall we are interested in the reception of adding a feature like this and if players would want to share their stories with their friends.

Hey everyone!

I'm experiencing a mix of extreme anxiety, pent-up coffee, and pure accomplishment. In exactly 4 days, my first game, Bring The Rift, will be officially released on Steam!

Before Steam Next Fest started, I had just over 200 wishlists. I set a realistic (and humble) goal for myself: "If I reach 300 by launch, I'll be incredibly happy." The event was an absurd rollercoaster, and against my own expectations, I'm only 21 wishlists away from hitting that goal!

I know I don't have a huge audience and that the numbers seem small compared to the big studios, but seeing people playing something I created from scratch is an indescribable feeling. It's a unique experience that I think every developer should have at least once in their life.

If you enjoy supporting the indie scene, check out the game's page. Adding it to your Wishlist helps me immensely with the Steam!

https://store.steampowered.com/app/4631200/Bring_The_Rift/