Five game design flaws of Quidditch and how to fix them
I am re-reading Harry Potter for the n-th time. Even it Rowling if trying hard to make me hate it, Harry Potter heptology still have a special place in my hearth. However, there is something I have always hated: Quidditch. It never made sense to me and I always found reading the Quidditch parts very boring. It looks like a game invented by someone who does not know a lot about sports and games.
Reading those parts for the n-th times made me realize that Quidditch may be a good way to showcase common rookie mistakes done by people approaching game-design for the first time (and it also provide meaning for my struggle). So, that’s what we will do today!
Game Design: Gathering Quests Sucks
Some years ago I was playing one of those big AAA games, an epic RPG saga, a staple of single player games. While I was leading my army against the forces of evil, in one of the first outposts I meet a guy with a quest. What an epic quest it will ever be? What dangerous task requires the intervention of an epic hero?
“Collect 10 herbs.”
Small introduction to Random Walking
Random Walking is a handy technique to have in your gamdev toolbelt and - despite the name - it is most useful for everything but actual walking. With random walking, we define the output of a process that can be described sequence of random steps. The main difference with a random sequence is that each new value will be statistically near the previous one. Imagine a gold price chart and assume that the current cost is 10€ for 1g of gold. We cannot guess what will be the price in one hour but we can be sure that it will be around 10€ per gram, maybe 9.5€, maybe 10.5€. What is certain, is that a sudden drop to 1€ per gram would be deeply unlikely.
In this article, we will talk briefly about random walking and its ability to simulate many real-world processes such as resources prices, temperature, floating objects position over time, and much more.
Quick Look at F# in Unity
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.
Game Design: Taxonomy of Fishing Mini-games
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.
The State of Game Development in Rust
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.
But this is the future. What about now?
Choosing between Behavior Tree and GOAP (Planning)
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 Goal Oriented Action Planning (GOAP) or Simple Hierarchical Ordered Planner (SHOP). First consideration: this is not a technical problem The first thing to know is that writing game AI is not a race for the best technology.
GameDesign Math: RPG Level-based Progression
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 entirely possible to provide progression feeling without levels and experience points, level-based progression is natural, direct, and linear, and it fits well in many (too many?) game genres.
Procedural Calendar Generation & Lunar Phases
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. Why lunar phases Lunar phases are incredibly important in a calendar. So important, that many of the early humanity calendars are, in fact, lunar calendars or lunisolar calendars.
Seasons Generation from Orbital Parameters
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.