July 23, 2017

Today's Special: Tips for Finding Success as an Indie Game Developer

Being an independent game developer is a great experience. As an indie, I'm investing in this game a lot of passion trying to exploit the best part of ME as a game designer.

Of course there is a schedule and a budget, but thankfully there is no game publisher behind me looking over my shoulders with a whip.

As a reward for reading this post, I want to share with you my personal and secret list of tips for warranted success:
  1. Have a great and unique idea for your game.
  2. If your idea sucks, go back to step 1.
  3. Write the best story.
  4. Design unique and incredible game mechanics.
  5. If you don't know what "game mechanic" means stop reading this post immediately.
  6. Eat, drink, rest. At least once a day.
  7. In case of diarrhea go as fast as possible to the bathroom.
  8. Make silence your best "kompristur palala kok".
  9. If you don't know what "kompristur palala kok" means it is okey since I just invented it.
  10. Code it.
  11. Test it.
  12. Publish it.
  13. Sell 100,000 (average price recommended $14.99)
  14. If you are ambitious repeat step 13 until you feel very comfortable.
  15. Be happy. Use your earnings wisely.
  16. Start a new game. Go to step 1.
- Diego

P.S.: Sharing this post will bring you luck. My sister did it. Three days later she discovered a chest containing $130 million worth of Nazi gold while diving near the coast of Norway.

July 6, 2017


I dedicated the past three weeks to work on the background story. This is also useful and necessary to support the next design phase and all the upcoming material, such as the teaser and the press kit.

Just in case this is the first time you are reading my blog, I'm developing an indie game; more precisely a pixel art action-adventure game.

The game engine and most of the required features are up and running. However, as it is obvious, I expect changes to the existing code and even more code to support new game mechanics that will probably appear as the development advances.

During the last few weeks ago, I put programming aside to focus on the story, the game mechanics, the game flow and the puzzles and this is going to take some time.

From my point of view this is the hardest part of the development. I still need to carefully layout all the puzzles and conflicts that will unwrap the story along the game. So I'm, still looking for consistency, harmony and the final heart of the game.

There is still a long way to go. Small moves at a time.

BTW, the above photo is faked! I suffer from Aquaphobia!

- Diego

June 5, 2017

State of the Game: Part III

It's time for another State of the Game post!

Currently, I've much of the technology stuff practically finished. The past weeks were mainly dedicated to the Pathfinding engine and the Save system. Both components are crucial for the development of the game. It took me a couple of weeks, but it was worth it.

In a nutshell, the pathfinding engine is based on the Dijkstras's algorithm. Walk areas are defined by polygons and obstacles are represented by blocking boxes that dynamically emit nodes/edges to be consumed by the pathfinding engine.

As I previously said, I was also working on the Save System. At this point, this component is crucial to speed up development and make testing easier.

The Save system is always a scary thing, mainly because you face the challenge of saving the state of a whole game session in a way that can be restored later. It is important to note that the game has no levels; it is a continuous world, much like an adventure game, so there is a lot of information flying around.

The complexity of a save system is directly proportional to the amount of information that you are willing to store. The trick is to store the minimum amount of information possible. In my case, I'm basically storing the state of each entity and the parent child relationship between them.


I have the game story outlined at a macro level. I still have a lot of loose ends that I need to connect and I still need to figure out many, many things.

The game has a great identity and personality. I'm really happy with it and I must admit that I never expected to achieve such a major goal.

Now, I'm starting to deepen inside the story and the gameplay and this moment represents the MOST CHALLENGING part of the project. The time for the real fight has come. This is when you have to draw your hammer and fight your fears, your inner monsters and your prejudices. I have to demolish barriers to be myself.

This is going to be really hard, but it is a great opportunity to be genuine and I will not waste it.

The first teaser, together with the official website will be available in a month or so. You will meet my brainchild soon.

- Diego

May 17, 2017

Today's Special: Design Philosophy + Some News

Since the beginning of this project, I have always known which is going to be the target audience for the game and the answer is: ME.

The expression might sound a bit egocentric, but trust me, it is not. Being an indie game developer is a privilege and I'm honoring it sticking my fingers where it is not allowed. I'm breaking the rules to be faithful to myself and to avoid falling into the dark side of businesses and capitalism.

Thus, this is going to be the game I'd like to play. None of my game design decisions have been based on marketing statistics or will be twisted based on commercial speculations just to attract more players or sell more copies. This is how this game is being crafted and it is not negotiable. 

"The innocence of children who have neither prejudices nor taboos nor fear of failure."

I'd be a liar if I told you that I don't want to sell one million copies, but such outcome must be a consequence instead of the primary objective. The title from this book written by Alejandro Casona synthesizes my spirit.

Trees die standing up.

Some News

The past two weeks were hard and crucial but the brainchild came out with all the things I was looking for and expecting: simplicity, strong personality with a bizarre style. All the pieces are well combined. It was hard, but it is done. For me, this is a green light for the first teaser! The video production will start soon. I expect to have it ready in 4-7 weeks together with game's website.

Currently, I'm doing the game design, story/plot, scripting, programming, character design and the whole set of animations. I'm also working with sound effects which proceed from professional and licensed sound libraries. 

However...there are three little things that I'm not able to do:

The first thing is music. Unfortunately. I'm not the one-man band. Just the one-man game. The good news is that the game is going to have its own original soundtrack! There is a great musician behind it. So, problem solved.

The second thing is the background. I tried to draw a few I swear, but due to my artistic limitations I wasn't very happy with the results, So, background art is being created by an artist who has strict orders of using just 0,23% of his talent to keep the homogeneity with my characters and animations.

And finally, the third thing is that I'm not able to tell third things. So, I don't know what the heck to write here.

That's all I can say. Curious about the game? Wait for the upcoming teaser!

- Diego

May 3, 2017

State of the Game: Part II

Hi everyone! The past weeks I was really busy doing a lot of research, mostly to explore the list of gameplay features that I'm going to include in the game. As it always happens, some will work and some won't. Let me tell you how things are going on:

Since I started the project on January 1, 2017, I dedicated the first months to the programming of the main components required to support the overall game architecture. I'm building the whole engine from the ground up and I must say that Monogame, Visual Studio 2017 and C# are all awesome and very solid!

The TinyEngine was augmented with a couple of new classes to better integrate sounds into the game.

Both the TinyAdventurer and the TinyScript frameworks are  up and running. New requirements or performance adjustments might come up in the future, but they shouldn't be a problem at all.

The time to use the scripting language has come.

Game Design
I'm still polishing the main plot/story. There are still a lot of loose ends that I still need to wire up to bring consistency. 

I'm a keen supporter of adventure games, ergo, I like stories and plots. But, I'm also a 46-year old creature who played almost all Atari games in my childhood, so I'm a great fan of permadeath too. As a result, I earned a free-pass ride into the "Dichotomy" roller coaster! 

Finding the right balance between narrative and permadeath.
The game is neither a roguelike nor a point & click adventure. So, I'm designing the game to have the most positive aspects of both genres.

A pre-teaser video and the official website will be available in a couple of months 8-)

- Diego

April 11, 2017

Item Hierarchy Unveiled

Hey! Not too much text...but a lot of classes today! Below is the tentative class hierarchy for the game items.

P.S. I'll be back.

April 5, 2017

Tiny Script: Part II

First of all, I could not think of a good idea about which photo to include in this post. So, I decided to use one of mine.

Continuing with my previous post, I'll show you a few more TinyScript features.

Let's start by dissecting the different types of scripts which are divided into two logical groups: Declaration and Execution.

Declaration scripts are used to initialize and declare the whole world. They are executed during the initialization phase which occurs when the game app starts. Once the initialization phase ends, all declaration scripts are automatically disposed from memory as they are no longer needed. There are three types of declaration scripts:
    • Global - Used to initialize global stuff such as sounds, music, atlases and all sort of global things you can think of.
    • Room - Used to declare rooms.
    • Thing - Used to declare things.
On the other side, execution scripts remain always in memory as they must be progressively executed while the game runs to support the game logic. There four types of scripts:
    • EnterRoom. Occurs when entering a room.
    • ExitRoom. Occurs when exiting a room.
    • Outcome. Occurs as a result of interacting with a 'thing' (e.g., when the avatar opens a door.)
    • Routine. A special type of script that can be called by any other script.
For example, consider the following code:

Room Bedroom

EnterRoom Bedroom
    start-routine FrogSound

ExitRoom BedRoom
    stop-routine FrogSound

Thing Bedroom-Door
    => DisplayName = "Door"
    place this into Bedroom at 100,100

Outcome Bedroom-Door
    play-soundcue OpenDoor
    anim this Open

Routine FrogSound
    play-soundcue Frog
    sleep 3000

So, what the heck does all this crappy code do?
First of all, it declares a room named 'Bedroom'. The EnterRoom script will start the  'FrogSound' routine as soon as the 'Bedroom' room becomes active. Thie 'FrogSound' routine will play the sound of a frog, then wait 3 seconds (3000 ms) and finally restarts all over again.

Funny TinyScript moment: the sleep duration can also be a random number. For example random-sleep 4000 10000 will result in a random number between 4000 and 10000. It is a bit annoying to hear a frog with the precision of a Swiss watch.

One of the cool features of TinyScript is that each script runs in it's own virtual process. As a result, the 'FrogSound' script will continue its execution -beyond the current room- until someone stops it by calling the 'stop-routine' command.

Static vs. Dynamic
The Bedroom and Bedroom-Door are static entities. This means that there will be one Bedroom room and one Bedroom-Door in the game universe as soon as the game starts. Once created, static entities cannot be removed from the world by any means. For example, I can declare a MainMenu room.

BUT, what happens when I need to have several instances of the same type of entity???????????????????????????????????????????????????????????????????
?????????????????????????????????????????? (and more ????)

Well, this is what dynamic entities are for. Although the game has many static rooms and things, it also have some kind of silly procedural room generation that requires the ability to create and destroy  rooms and things on the fly; the solution comes from an asterisk! This magnificent symbol has the power to convert a static entity declaration into a dynamic one as follows:

Thing Door*
    => DisplayName = "Dynamic Door"

Outcome Door*
    play-soundcue OpenDoor
    anim this Open

The above code is more like the Class & Object concept. A dynamic declaration is never removed from memory and it can be executed as many times as needed to create dynamic entities on the fly. Dynamic entities can be created with the create-entity command or they can also be created directly from C# code too.

There is much more to talk about but I'm tired. Out for an expresso!

- Diego