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.

Period.

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:

Programming
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.

Pre-Teaser
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
    restart
}

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





March 30, 2017

TinyScript: Part I

TinyScript is my own -homemade- scripting language. It allows me to do powerful things with very little code. That's the idea behind a high-level language after all. 

Despite the fact that there are a lot of scripting languages out there, I decided to write my own demon from the ground up. Part as a whim, part as a challenge and part because is fun. 

TinyScript is very limited, as a matter of fact it is not able to do any calculations, has no local variables/functions/loop statements and lacks most of the things you would expect from a scripting language. As I said, it is very limited. Now, that I think about it, it's CRAP!

It is designed to be simple and extensible. It is easy to write, easy to maintain and performs pretty well for the kind of game I'm doing. It is mainly used to declare entities (mostly rooms and things) and for coding very specific parts of the game such as cutscenes and interactions. I also use it to define the whole game configuration which saves me from having to deploy and read a bunch of xml files.

In TinyScript, everything is a script. Each script is composed of statements. There are different kind of statements as you can see in the following class diagram:


Commands are by far the most consumed statements. Commands start with a name usually followed by a several keywords, clauses and optional arguments called flags.


The following code shows an example of what TinyScript is capable of. Let's try something with Steve Austin!

    move Steve to 145,30 #wait
    anim Steve ReachDown #wait
    pickup Steve GoldenCoin
    anim Steve ReachDown #direction:Reverse #wait
    say Steve "This coin belongs to Oscar Goldman!" #wait

The code above will move Steve to the coordinates 145,30. The #wait flag will pause the script execution until Steve reaches the expected destination. Then, he will grab something from the floor using the ReachDown animation. Once the ReachDown animation ends (because of the #wait flag) the Pickup command will put the GoldenCoin into Steve's inventory. Then, the ReachDown animation is played again, but this time in reverse direction. Finally, Steve says something about the coin.

This example gives you a good example of how TinyScript works and how useful is to make a lot of complex actions with just a few lines of tarzan-like code.

To save my time and health, I coded the TinyScript Editor. It supports syntax-highlighting and exports all scripts together into a single file.



BTW, it is about to rain around here.



- Diego



March 21, 2017

TinyEngine Done!

The TinyEngine Framework is now complete. Have a loot at the whole class diagram;

- Diego