The art of programming a dream: How do I program Caverns and Dryads

This is a post about the process followed to program a feature in Caverns and Dryads, my game on Steam.

When I program I follow a cyclical routine. I don't know if other programmers do the same, but it should be very similar. Maybe not, but for a solo developer this is the way that works best for me.

Some time ago I made this, The Circle of Programming:

It is quite simple to understand, but basically all starts on the top, thinking. I don't run to code, first I think of all the aspects of the feature that I want to add. This is a designing phase in which I decide what aspects will be playable, what does it need, and how to give shape to the new feature.
I may write, make diagrams or sketches.

You may find it curious that the next step is not coding but designing the interface.

Why do I do that? Because when I do this, I realize if there is something I missed in my idea.

For example, it may reveal if I need some extra feature, or expose some weak point in the idea.

I also do this because I am a very visual person, so it doesn't make sense for me to work in abstract.

Here below, this is a screen in the process of the remake of the cities. I do a rough UI, so I can think better. For example, doing this made me notice that the special places like the Silver Palace needed some method to load them in the boxes and I should modify the graphics and the paths if it belongs to the current city.

Then I make a plan, step by step, on how each part will work.

I make empty functions, the basics of each class (parts or objects that do something).

Then I create the flow between the methods that do things, leaving them empty for now.

Then I write comments inside, marking tasks to be done, and how it should work.

This is the moment when I actually start to code. As you see, I don't code until the UI is done, the methods are named, and the logic is mature. 

I think this saves me a lot of time. As in other arts, I proceed in layers. One layer does something, then I refine the results with layers of progressive work until it looks or works good. It's the way an oil painter works, but with everything.

After that, I do play and beta test, fix the bugs, and replay again and again. When all looks good, I may also optimize, and replay and test again. 

And that is the moment when I publish an update and share it with you on Steam! :)

Hope you liked this voyage to how I work. I will share more with you on this week about the different aspects. Tell or ask anything in comments!

Now, some QA about my programming phase:

QUESTIONS AND ANSWERS

Q- Do you use AI for programming? How?

A- I make my classes from scratch by thinking and coding. I make the plan, do the class (type of object or item) and the list of things it does, code its fields all by myself.

All the code of Caverns and Dryads is unique and made from scratch. Unity is used to create the interface, but I don't use the classes of Unity. I made it all.

To speed up things, I may ask Microsoft Copilot to make a template of some function for me, or ask about what kind of construct may be ideal for what I want to do. Then I develop that solution by hand.

Yes I mean Microsoft Copilot, not Copilot from github, or whatever. It's a general assistant, not a coding one. But it's trained ethically from their own resources, and respectful to everyone's rights. Not being a code assistant is good because I use it mostly for examples, documentation and bug prevention.

As the game has become more complex, I usually do this myself too. Because no AI can do any part of a game that is not conventional or typical. Making a Space Invaders may be possible, but making Caverns and Dryads without your own mental effort is impossible.

Usually the memory of those systems is limited, so you must have the full concept of your app in your  mind. They may give you chunks of code, but they don't work as they are. You have to adapt them. It's like what you find in web examples elsewhere, but saving the time to search.

I also have noticed that my use of this is lesser each time, because I learn and remember everything. On the months before, Copilot has worked for me as  a great source of documentation and examples to learn new techniques.

What I mostly use Copilo fort is bug fixing and bug prevention. It lets me think together in which weak points the feature may have, and test them. This way I prevent problems before they appear. 
The way I use it is usually this: program something, ask Copilot if something may generate a problem in my code, then prevent it from happening. Then I test and fix if something still happens.

For coding and typing bugs it works. But for logical bugs, you have to rely solely on yourself as a programmer, because otherwise, you may ruin your work. No assistant can grasp everything that happens in the real world and it may misunderstand your plan.

Q - Are you worried about AI taking the programmer's jobs?

A- Not at all because I believe these tools are not capable and never will be able to make something themselves. We use them, all of us modern programmers, as a tool to make things faster, prevent problems, bug fixing and quick access to documentation. So no. The debate is stupid and pointless for any person that actually programs something non-trivial.

Q - Why don't you use some external library for your work instead of making them yourself?

A- Simple: it is a pain for me to understand someone else's code. I progress much faster making mine from scratch. So the only external library I use in Ink for the narrative chapters. And I customized and made my own system myself that displays images and options, sounds and all of it, using Ink only as a tool to display the text.