This is my first post in what I hope to be a series of tutorials about Unity3D. It’s theme was a request of many people and in the end it also helped me understand many things while I was searching about.

So this tutorials will contain what I have found, my personal opinions and some of the discussion I had with some friends, so feel free to contact me if you think something is amiss.

This tutorial also expects you to have some kind of programming experience.

What is Object-Oriented Programming?

OOP is a programming paradigm, which I didn’t really know what it meant at the time, I always thought it was just a way to write code.
Turns out it’s actually a classification of programming languages, or from what I understood an property that is intrinsic to the programming language.

What does that means? Well for one it implies if you are using C# you are already programming with OOP! Well, you could be badly programming in OOP but you still are! So this tutorial will also try to teach some good code practices which will greatly improve your code.

For other, I also founds things like “component oriented programming” and “interface oriented programming” are not paradigms, because they can be done with current programming languages and are not a classification of them, they are just software designs.

How do I OOP?

So OOP languages are based on the fact that you write objects who hold datas and procedures. If you don’t come from a procedural language this just means an object contains information (fields, properties) and also ways to process information (methods).

What is an Object?

In C# this would be instances of your classes, when writing code you will open it with a class declaration like:

This mean you are declaring a class called TinyObject, that extends MonoBehaviour (this is an Unity3D class, do not worry if you do not know it), it contains the data favoriteNumber which is an integer and a method called WhatIsMyFavoriteNumber that returns the favoriteNumber when called.

While the class is called TinyObject, the class itself is not an object, it is some kind of template for creating new objects with it, which are called instances.

So to better understand it let me give some functional examples. Let’s say you want to have containers on your game that are able to hold items inside.

We will start with a generic container class that gives functionality to hold items.

This class would allow you in Unity3D to create things in your game that can store items inside of it.

The public keyword means anything can access this data, in Unity3D it will also automatically serialize the field. (You can learn about serialization later!)
The protected keyword means instances of this class and also classes extending from it can access this data.
The virtual keyword means this method can be overwritten in an extended class.
Anything without an access keyword is private by default, meaning only instances of the same class can access it. (In this case, only another Container)

The AwakeInit method is a workaround you have to do in Unity3D due to the magic method Awake() not being possible to overwrite, this mean that if we did any code inside an Awake() method we would have to copy and paste it inside any class extending from our Container if we wanted to keep it’s functionality.

But what if you want to have an wardrobe, a kind of container able to store a few items and also clothes, in a way that misc items can’t be stored in clothes places?

This declares our Wardrobe class, it is very similar to our Container class but you can see some differences in types.

Since our Wardrobe extends from Container, it does everything a container do, so it already have an Item array and a PutItemInside method!

Since it already have our Awake() method, we don’t need to write it again, this is an important good practice: reuse code!

We overwrite our AwakeInit method and inside it we make a call to our base AwakeInit() (the method that we are overwriting) on the Container class, this makes sure that everything the Container is doing inside that method is also applied to our Wardrobe without we having to copy and paste the code, another good practice: avoid duplicate code!

Now we have a class that is able to both store items and also articles of clothing in different spaces!

We could keep extending it to have all kinds of different containers, some examples:

And you can keep extending from them, maybe extend from Refrigerator to make a Fridge? Or from a bookshelf to make one that automatically organizes your books!

In my opinion OOP is a very nice neat thing they came up with, you can even add some designs on top of it to fit your needs like MVC or Component!

In a Nutshell!

– In OOP you create classes, which will be used to create instances of it, those instances are your Objects.
– You can extend from classes to create other classes with similar functionality.
– Instances are individual, you can have two objects of the same class with different values on them.

Hi there! Saishy here again, today I will be talking about our work on procedural generation for TinyAttack.

If you played the prototype available for patrons you might have noticed the map is always the same, initially I decided that maps would be hand-made as to allow them to be aesthetic pleasing and interesting. While only randomizing location for chests, goals, start point etc.

What I would find later is that I’m actually horrible at level design… And TinyBird Games don’t make enough to be able to hire one.
The map ended up being too big and empty, nothing interesting, people would walk to one corner and away and forget where they were. The empty feeling would make them complain about the slow moving speed. It was a train wreck.

So, being a horrible level designer, a barely passable artist… The only thing left being a programmer I decided to finally go ProcGen!

So first was researching, I’ve received great help from Eniko (Creator of MidBoss, another RogueLike), and the following links:

Reading tons of articles and tutorials was a key point in choosing and implementing an algorithm.
And after pondering for a while I decided to go with the Cellular Automata for the first level, the GrassLands.

The initial attempts weren’t going well tho:

Considering blue is non-walkable area and green is the walkable one, you can see that those are not playable maps.

That was a result of somewhat confusing tutorials and me not really understanding what was going on. A few tweaks to the Cellular Automata algorithm and we get:

… It does look better tho! I mean, it’s actually playable, I think.

Reducing a little the map size and increasing the number of iterations done on the Cellular Automata eventually left me with those results:

I think those are the first good results I got, but I still thought it was too big for TinyAttack. Besides you can see it still generates isolated islands, which I will explain later how I dealt with them.

A little more tweaking on the size and iterations got me to the second batch of results:

Those looks much better! But I still think they were a tad too big and a lot of big open spaces with nothing ended up appearing.

For third batch I didn’t reduce the map size, but I did make it generate the horizontal and vertical sizes apart, adding a little of variety:

I think that really helped with the variety and interesting shapes, but it was still too random, a square map with big open areas would still be generated with a high chance.

To fix that was basically just playing around with map size and number of walls generated at the start of the Cellular Automata. It might still not be perfect but I think it’s good enough.

Then the next thing I wanted was to make some portion of the map into water, because the Grasslands map is a grassy area that ends into a portion of water.
For that I tried making a sphere and checking if a non-walkable tile was inside it, if it is turn it into water and Flood Fill the area (Flood Fill is another algorithm very useful for procedural generated stuff).

Also this is when blue starts to actually represent water:

So, the problem is obvious here, the Flood Fill is not working! But why?

Fixing it was very easy, let’s get this over already:

So now I got my attention into fixing the isolated islands problem.
Remember the Flood Fill thing? This is it now, feel old yet? I basically just got the first portion of walkable area nearest to the center of the map, once I got it I applied the flood fill to a full non-walkable map, changing the non-walkable tiles into walkable ones.

And done! Since the flood fill only traversed in the X and Y axis that means the result was assured to be fully connected, never having non connected areas.

Of course that is not perfect, and I found a fairly low chance of it generating extremely small maps due to the initial tile being actually inside an isolated place or the map having too many isolated places to begin with.
To fix that I just got the percentage of non-walkable tiles and if it passed a threshold I dropped the map and regenerated it. Remember that at this point the map is just a bunch of 0 and 1 on an array, not too heavy to regenerate again and again.

Here one resulting image for your entertainment:

It generated a duck: So that means it’s perfect already.

I wish! The next problem is that the walls of TinyAttack are composed of two vertical tiles together, but putting them in some places would actually block the player path!

Oops, so how do we solve that? My first idea was a way to check if putting a wall in that area would actually block the path. That was fast dismissed by Eniko on grounds of being too difficult, which I agreed after thinking a little.

Next idea was something I thought it was ingenious, clear the 3 tiles bellow a wall so the path is always walkable!

I’m a frigging genius! Is what I would like to say… Again reality shows that there are no easy ways out:

Damn, there is no way for it to known when digging is not necessary! So a single curve for either side can eat into it’s own area…

How the hell do I solve that now?

A lot more thinking, and I end up with the conclusion that I shouldn’t solve that, I shouldn’t even use that at all.
I’m already wasting too much time on this, let’s just brute force the solution!

So what I came up with is that all non-walkable areas will be extruded two tiles down, and those two tiles will be converted to walls later on.
Since at this part the Flood Fill check and percentage of walls check would still run after, I was guaranteed to get a playable map!

Dirty? Yes. Functional? Heck yes:

So now we put everything we did together and what we get?

Yeah that is starting to look like an actual playable map!

The next steps are mostly aesthetic ones, putting the borders on the high areas, putting the walls on the water areas, putting decorations etc…
Then selecting areas for the starting point, chests, shrines, portal, but those are much more game specific.

I hope you have liked following into what happens behind TinyAttack.
Please come back for the next article, and maybe support us on Patreon too!

In those posts I will try to talk about anything related to game development, of course those will probably be our own experiences and I hope this will be interesting for you.

Today’s post is about how we make our tileset, mostly about the tools and workflow I use.
First I would like to thank castpixel again for teaching me pixel art, you can find her patreon here: https://www.patreon.com/castpixel

I use both Aseprite and Pyxel Editor for doing the tilesets, those tools mostly cover everything that I ever need.

Aseprite is used for more complex tiles, as an example I will use the tree of the grassland area of TinyAttack:

All the work start by searching for references, in this case I downloaded a lot of screenshots of other games with a similar camera and ended up choosing to use the tree from Pokemon HG/SS as reference:

(Don’t mind the glitches~)

After that I make a vague shape of what I’m wanting to do, I’m using red for shading because I’m bad with colors so I left that for last, and I find red an easy color to work with.

After that is done, I start making out the details (still in red) of how I want the tree to be, after I choose the colors I substitute them on the image and work out any detail left.

After that I will transfer the image to Pyxel Editor to create the tiles, doing that is basically counting the number of tiles (16×16 in this case) the image will need, creating the number of tiles in Pyxel and putting them on the tilemap, and finally, copying and pasting the image on top!

Once that is done the tree is basically ready to be exported with the other tiles as a tilemap.
But I also needed another thing, a way to pack the trees closely, what I mean is that if I just try to put trees near the other, this would happen:

To solve that I basically need to create new tiles which contain parts of more than one tree, so I can put them between to create a forest. This is all done in Pyxel and is basically copy and paste.

With this we have everything ready to make a gorgeous forest that will not allow anything to move inside.