Last but not least came the time to publish Forgecore. I planned to release it on Gamejolt, Kongregate and Newgrounds but unfortunately Kongregate closed new game submissions just in the nick of time.

I had a surprisingly positive experience on Newgrounds, and not only because Forgecore was featured. I found out that it's one of the few websites that still actively promotes new submissions instead of just showcasing the most successful games. Overall the community is also very welcoming, I feel it still retains some sort of indie idealism that is very rare to find nowadays.

During the time that Forgecore was featured on Newgrounds, I've received lots of feedback. There are many aspects of the game that could have been done better, but the most important subjects are about the difficulty of the game.

Forgecore has a simple narrative aspect, but some people may find it entertaining and engaging nonetheless. Some of these people may not like the gameplay enough to enjoy tackling a demanding challenge, or they may just want to have a more relaxed experience in general. It happened to me too a few times, in some games I played there were moments in which the gameplay difficulty felt like an annoying obstacle to keep the story going.

For some reason, I completely overlooked this aspect and when I released Forgecore there was no difficulty level selection. When some reviews pointed out that the level of challenge wasn't enjoyable for everyone, I've slapped together an easy mode and updated the game. It's not the most elegant solution, but it was the only one doable in a short time.

From the reviews it emerged that the biggest issue was the mountain level. I never thought it would be so hard.

The problem was that the most intuitive strategy to beat the level wasn't the one that I had in mind, because I was biased by my knowledge of the game mechanics. As a result, the margin to make it through the level using the strategy that most people attempted was extremely tight and it wasn't meant to be so. Sometimes it's hard to put myself in the shoes of a new player.

Adding an easy mode solved also this problem in a way, I didn't want to make the mountain easier because it would be unfair towards who already got through it at the original difficulty level.

All in all it was a wild, emotional and satisfying learning experience. I'm grateful to Newgrounds and to all the players that shared their thoughts, if my next games will be better it will be because of them.

My initial plan was that Forgecore would feature randomized level layouts. I gave up on that idea eventually because I realized that memorizing the level layout was a big part of what made a run successful. In facts Forgecore levels are procedurally generated using a fixed seed, so that they are the same for every game.

Also all of the graphical elements are procedurally generated, in some cases with a degree of randomness.

While developing Forgecore, I've found that it's better to ask myself a couple of questions before of shamelessly jamming some randomness into the mix.

The first question is: "Is that really random or it actually has an underlying scheme?"

I've spent some time trying to figure out how to distribute trees on a mountain for a certain ending sequence. I've tried randomizing it in various and implausible ways, but it was looking good just one time out of ten. I was overlooking a fact: trees don't grow randomly.

Trees need light and space to grow. I've ended up placing the trees in a perfect brick layout and applying some randomness just to create some noise and don't let it look too perfect.

Which brings me to the second question: "Even if there's no underlying scheme, is that really random or it's better if it's equally distributed?"

Let's continue with trees, but considering a single one. Let's leave aside the look and let's focus on the structure of branches. The algorithm I used is pretty simple: the tree has an amount of "age" or "energy" and every time it branches the amount is split between the branches. It goes on recursively until it eventually gets a branch with just 1 energy.

I wanted to have both branches that split into 2 other branches and branches that split into 3 other branches. On my first approach I've tried to randomize it, but many times I would get too many consecutive split into 2 or consecutive split into 3 and it was looking fairly bad. So I realized that in that case I didn't want to have it really random but distributed equally. I completely gave up randomness and I've opted for a fixed 3 - 2 - 2 sequence. It works quite well because it is applied breadth first and the repeating pattern doesn't stand out.

I can say that my idea on the use of randomness in game development has changed a lot. I'm a long-time fan of classic turn-based roguelikes and I used to think that procedural generation was all about randomness, but now I feel that it has be used with a great deal of care and with a clear purpose. Nobody likes a bunch of pointless noise.

At a certain point I had a lot of free time on my hands and I decided to develop my own toolkit. I wanted my games to be exactly the way I wanted. I also have to admit that I have an interest in understanding the technical aspects of making video games and that I mostly learn by doing. I know, it's not a very designer-like attitude, but with time I've learned that sometimes it's better to just let me be me.

The whole thing begun with "The Clock & The Chaos": I simply wrote a piece of code to draw images and spritesheets using HTML5 canvas. Then came "The Cursed Mirror": I went deeper and I implemented skeletal animation, so that I could procedurally animate the characters. At that point my geeky side was too hooked to stop: I was creating something aesthetically pleasing solely by writing code.

But editing images like that was messy and extremely time-consuming, so I wrote an editor to draw images by writing code, assemble them into skeletons and create animations: SkeleTool.

But then I wanted something with better performances that could leverage WebGL. I also wanted to add more features, so I rewrote it using AngularJS for the editing interface and PixiJS to handle rendering.

But then I realized that wasn't easy to persuade game engines to import that stuff. I was never happy with particle effects implementations after all, better write my own engine based on PixiJS for the rendering and p2.js for the physics simulation.

But then... well, you got the picture. I went in full frenzied developer mode and I wrote an awful lot of code.

I ended up reinventing the wheel, the brakes, the engine and the whole truck. Plus my free time drastically decreased at a certain point, so it started to feel really daunting.

No need to be said that it's not the ideal approach if your plan is to be a game developer. The amount of time spent on strictly technical work overweights the amount of time spent on developing the actual game. In retrospect, I can say that it was an interesting trip. If I had known that at a certain point I couldn't spend all that time on game development, probably I wouldn't do it. I feel that in some way I've been hiding again in my problem-solving comfort zone.

But, yeah, it has been interesting and I've learned a lot. It's bitter-sweet, but let's focus on the sweet. There have been some unespected outcomes too. For example, I've implemented a function in SkeleTool and in my game engine to quickly generate animated gifs, which sparked an interest for creating looping animated gifs. Also, working on audio context was pivotal to understand how it can be leveraged to create visuals synchronized with music.

So, maybe Mr. Romero was right.

I've read it a thousand times, but maybe only now I can understand what it really means. I've been working as a programmer for 15 years, for most of the time I've been writing code just to solve a problem that someone wanted me to solve. I've used to think that there was no trace of the mysterious charm of the artist in a programmer.

But everything changes if you remove customers, requirements and money.

That's another of the reasons why I don't want to depend on game development as my main source of income.

Scrolling down my Twitter timeline, then scrolling it down again and again, I've found out that the first tweet featuring ideas about the game that now is published and is known as "Forgecore" was posted on June 19 2016. At the time I was referring to it as "the game I won't finish", but some of the core ideas (no pun intended!) were already there.

After a couple of months I stopped working at that idea, I wanted to try to do something I could actually finish.

After a couple of years I recovered the old project and I rewrote it using a completely different toolkit. I was thinking to make something simple out of it to participate to a game jam. Eventually I realized that it was not the case and I've decided to finally commit to the project.

Since then I've worked on "Forgecore" in my spare time. There have been pauses, even long ones. In the end the game took probably around 6 months of full-time work to be developed, diluted over the course of 2 years. I did only develop games for game jams before, which is the opposite approach. Working at a slow pace like that had some notable effects, positive and negative.

The good thing is that I had a lot of time to think about what I was making. I ended up having a clear idea and I aimed to do something simple and essential, trimming all the unfocused stuff that could drain my scarce development time.

The bad thing is that I really had a constant dread feeling that I'll never actually finish.

The weird thing is that I've managed to actually finish it. It makes me feel wise and patient, almost adult.

I had the inspiration for the story during a visit to Pompei. I've been living near Naples since 2009 and I've been learning a lot of local folklore and traditions since then. One thing that I find particularly striking is the consideration of Mount Vesuvius: most of the people living here aren't scared or worried at all, they see Mount Vesuvius as a symbol of being home, as a guardian even. Also, I feel that the real threat for humanity is its own darkest side, not nature.

The idea of having a construct as the protagonist was borrowed from another game I've made, "The Clock & The Chaos". I usually try to develop simple and focused games, where the protagonist has a single goal or a straightforward task, I see that as more suited for a machine that for a person. Also people seems to like unconventional, weird and somewhat cute protagonists. Someone empathize with them, even if they are machines. At a certain point I've let some friends of mine toy with an early prototype, when I've told them that I wasn't actively developing the game anymore, one of them told me "Poor thing. I'm imagining the glowing core slowly getting dim and ultimately going off!"

The flame propulsion was inspired by the extensive use of jetpacks in "Tribes: Ascend", a game I've enjoyed quite a lot back then. In the early versions of "Forgecore" you could also control the rolling direction of the protagonist with the keyboard, but in the end I was holding the "roll right" button all the time. So I came up with the idea of giving to the protagonist the stubborn and single-minded behaviour of always rolling right on its own.

I was also thinking to have the temperature as a limit to the use of the propulsion and some sort of classic health bar, but I liked the idea that you could sometimes benefit from what would normally kill you and the risk-reward gameplay that could spring from it, hence I came up with the idea of having the temperature as the only resource to manage and an environment that wants to freeze you.

It's needless to say that most of the design happened very early in the developement process. There was just that little detail missing, the implementation. I also may have overcomplicated it a bit, by the way. Let's say I wouldn't do it how I did it if I could go back, but in a way I had to give it a try, at least to understand how it really worked. It deserves its own dedicated post anyway.