I am a functional-oriented developer. I have a bit of expertise in game development, especially in Unity 3D. It comes naturally that I am interested in the obvious link between the two: F#.

F# is a functional language of the ML family born in the Microsoft Research and now developed by the F# Software Foundation. Of course, F# run on the .NET framework, the same as C#, the language used by Unity3D. It is clear, then, that we could use F# in Unity. And, in fact, we can with moderate easiness.

Should we? How easy is that? answering these questions is the goal of this article.

Fishing is probably the most common mini-game in gaming history. Before I started working on this article, I never realized how many games include a fishing as mini-game. The list is huge. Fishing is everywhere. It seems that it is not possible to have a game without the possibility for character to have a relaxing time fishing in a pond.

Everybody loves fishing! At least in games. We can imagine a deep reason for that. There must be something that attract designers, gamers and human in general to the ancient art of fishing. However, for the time being, we are not interested in this question. Instead, we want to explore the huge design space of “fishing games”.

In fact, the action of fishing has been dissected for decades by game designer. It is fascinating to see how many implementations exist for the same real-life action. So, it is time to see what they produced, what are the possibilities and how we can do something new in this domain.

Game Development is one of the fields in which Rust can gain a lot of traction. As a modern compiled language with performances comparable to C++, Rust can finally free us from the tyranny of C++ bloated feature set, hard-to-link dependencies, and header/implementation file double-madness (I am obviously exaggerating, btw).

However, if this freedom arrive, it will be a very slow process. To make it slower, the feature of memory safety in videogames is not a huge priority compared to the ability to quickly prototype. The borrow-checker and the strict compiler are an obstacle in this regard. On the other hand, memory safety also means easier multi-threading. And this is sweet!

Fortunately, the annoyances of borrow-checker will get less in the way while people becomes more confident with the language, and while tooling gets better and better. I am confident we may see Rust carve out its space in this domain.

I would like to expand the answer I gave on /r/gamedesign some days ago. The main point of the question was: how can I decide if it “better” to implement the decision-making layer of our game AI with Behavior Trees (BTs) or with more advanced plan-based techniques such as the Goal Oriented Action Planning (GOAP) or SHOP.

Level-based progression is an extremely popular way of providing the player with the feeling of “getting stronger”. The system is born with Role-Playing Games (RPG), but it is nowadays embedded in practically every game; some more, some less. Even if it is perfectly possible to provide progression feeling without levels and experience points, level-based progression is easy, direct, linear and fits well in many (too many?) game genres.

But designing a good experience-level progression is important. Many games do that without much thinking. They just slap experience points and level and that’s it. The general idea is that the more your level is big, the more experience you need to advance. This is true, but it is just a small part of the design. Because in game design, you must keep in mind the effect of your gameplay element on the player and must be useful to convey the emotion you want to convey. Not the other way around.

I cannot give a full analysis of level-based progression system, but I can use simple math to explore the effects, limits and the design space of it.

Why using a level-based progression system?

Judging from the amount of games that have a level-based progression system in place, the real question is “why not?”. However, whenever we see something extremely successful we should ask ourselves why it is so popular.

The reason is: to give the player a sense of progression. Players want to see that they are getting stronger. And there is no better way than see “numbers getting bigger”: levels, damage, HPs. The player has spent hours playing to become powerful and these big numbers are here to prove it!

In many games, our skill is cannot be directly measured. Sure, we can feel this warm sense of progression in Super Mario Bros when we go back to the first level and we can go blazing fast. But this is nothing respect to the feeling of going back to the starting place and dealing ONE MILLION DAMAGE to that level 1 monster that gave us so many troubles.

But there is also another reason designers like to introduce levels in their game. They are a handy way for the designers to control the flow of the game. And they offer to the player a clear indicator of this too. Nothing stops a player from rushing through the game like slamming a monster several levels higher than the player on the player’s way. This kind of artificial difficulty can be done extremely badly and when it does games can be screwed by this. But if well-tuned, it is really effective.

Another question is: if we like big number, why use levels in the first place? Why we do not just use experience points and offer a “smooth” progression? Because it’s not satisfying!We want to see number get bigger, but we want to perceive the change. That’s the reward after the “work”.

It is just like eating a pizza. We can eat a pizza on the week-end after a week of strict diet, or we can have just a couple bites of pizza every day. At the end, we will probably eat the same amount of pizza, but I think one solution is definitely more satisfying than the other.

Understanding the progression mechanics

Now that we know why we use level-based progression, it is time to play with some number. Note that this is not necessary, but understanding the math behind gameplay elements is a pet peeve of mine, and I think is helpful to understand better what and how to change something to achieve a particular goal. Also, because if you don’t do the math, your player will do it for you.

At the basis of level-based progression there are experience points. Mathematically speaking, level progression is a function mapping a certain amount of experience to a certain level.

When designing the level progression, we are designing this function. How much experience (ad so time) players have to invest into the game to gain a level?

In practice, however, when designing a level-based progression, it is easier to find the inverse function: that is a function that, given a leve, tell use how much experience we need for this. This is usually called experience curve.

We can already have some intuition. If our experience curve is linear, then every level need the same extra amount of experience: 10 for Level 2, 20 for Level 3, 30 for Level 4 and so on. If our experience curve is exponential, we need always more experience, and therefore we level-up slower at the end game. If our experience curve is logarithmic instead we need always less experience and, therefore, we level-up faster the more we play. They are all valid experience curves, everything depends on what kind of game you want.

Here, we will explore the most famous experience curve, the exponential one. The exponential curve is constructed starting from a single concept. Suppose you have a first amount of experience at level 1: . In order to reach level 2 you want the player to double, triple, etc., your initial experience. So

That is, the experience at level 2 should be the starting experience plus times that. For level 3, we do the same, we wont to have times the increment at level 2.

In general, at level :

That is a geometric succession, that can be luckily be expressed in closed form.

See? A nice exponential experience curve. But this time you know why it is like this. You know the meaning of the parameters and how to tweak them in order to obtain what you want.

Given an experience curve, one of the importan properties we can infer is the level progression over time. How fast a player will travel along the level progression from the bottom to the top? How much time the player need to put into the game for leveling up from 10 to 11? And from 79 to 80? How can I tune the experience of a certain area?

These are all interesting question. We can find an answer by looking at the experience curve. First step is to invert the function to obtain the level progression function, that is, how level advances given the experience.

Who. That’s ugly. But there is just some parameter noise. For the sake of the discussion, we assume (that’s not unreasonable) and .

Much better. Now, we need to consider the experience a function of time. Obviously, we cannot know a real function for that, but we can general idea of “how much experience we expect the player to collect at each time”. Do we expect the player to get always the same experience over time? Do we expect to get always more experience? This is very common and implemented with high level monsters or quests giving more experience points.

Then, we can derive some kind of leveling speed function.

And here I stop for now. I like this stuff but, more than this is probably unnecessary. The important thing is that you try to model your progression in function of time by inverting the experience curve and plugging in some “experience function”. This will help you in having a rough estimate of the time and effort needed for leveling up in your game.

Real Case Examples

How are experience curves for real cases? Pretty much similar. I’ll give you the example of RuneScape.

That’s definitely a more complex formula. Why is done like this? No idea. However, we can identify that it is an exponential function, in the same spirit of the one discussed above.

World of Warcrat legacy formula instead is not analytic. Instead, we have a formula for the experience required to level up at a certain level.

Where if a difficulty factor, is the basic experience given by a monster of level and is a generic scaling factor. This formula start as a quadratic experience curve and then explode into exponential (thanks to the Diff formula). Giving us this strange shape (note that this is the derivate of the experience curve).

In Diablo 3, instead the formula is a nightmare (there is a typo in the formula, but I do not want to rewrite this in LaTeX on WordPress…).

Where is the and is . Why are this constants chosen in this way. I don’t know. Probably a fine tuning.

Conclusion

In the end, I hope you have fun with experience curves. There are thousands of different way to do them. Just remember that it is not just and always an exponential curve. Time and experience are linked together and modeling the experience curve can give you a lot of insight on how to avoid “grindy” parts in you game and keep the player in the flow.

Here we are again! This is Part 3 of a small series on how to randomly generate a physically accurate calendar starting from planet’s orbital parameters. You can find the general motivation here, part one here and part two here.

Said that, here we go with the next part: lunar phases.

Welcome back to part 3 of the Procedural Calendar Generation series. In the first part we looked on how to compute celestial body position in a simple two-body system. The second part, instead is crash course on ellipse geometry.

In this part, instead, we will tackle a fascinating consequence of the cosmic dance of our planet around its sun: seasons. Seasons are a strange beast because their behavior depends on a huge amount of factors. We are used to our four seasons with mild springs and autumns, hot summers and cold winters. But these four season are just the consequence of our planet ecosystem, atmosphere, the peculiar axial tilt, if the orbit is particularly eccentric, distance from the sun in different period of the year can be a strong modifier too! In multi-star system, we can have more than 4 seasons, in planets with strange mechanics we can not have seasons at all (or better, the “season” depends on where are you on the planet).

During the last few weeks, I’ve seen over and over people saying that Cuphead is hard. That it is brutal. That is the “dark souls of the side shooter”. For this reason, before this trend goes too far, it is time to make things clear: Cuphead is not hard.

Because I started a small series about astronomical algorithms and the magic of math in space, I think we need to cover an important prerequisite. In the series, I will talk a lot about ellipses (duh), I will move from the semi-axis majors, to the periapsis, to eccentricity, to ellipse’s center and ellipse’s foci. I am concerned that things can get more complicated than expected if the readers does not know many of the geometric properties of the ellipse. For this reason, I put here this vade mecum on the ellipse geometry. A summary with all the basic points and lengths. A place that I can link everywhere I need to refresh a definition.

This small article is born from a discussion I had with a friend of mine this week. He was writing a review on Playersunknown’s Battlegrounds (from now on, PUBG) and he ended up talking about the evolution of the genre and its triumph over every other competitor. The article was good but it did not enter in detail about, what I think, it is a greatly important and interesting question: Why PUBG? Why not any of the other dozens of battle royal games we were plagued in the last years?

PUBG is clearly a winner in this competition. It sold more than 8 million copies on Steam only, and I can see the trend going with the future release on consoles. The problem, in my opinion, is that, on paper, there is nothing in PUBG implementation that seems “right”. Nevertheless, it won.

Machiavelli once said that success is 50% luck. That’s definitely true for PUBG. But the other 50% must be researched in the PUBG qualities. Analyzing them, despite the massive “errors”, it is very important for any game designer.