How to design an economy for your game? The answer to this question might require a series of lectures or articles. The fundamental difference in the approach is based, first of all, on monetization model: F2P or B2P. The second thing that defines the approach to developing an economy system is game genre. This article reviews the case of designing the game economy for a B2P (premium) game, which doesn’t involve earning on microtransactions.
One of the common tasks that both beginners and experienced game designers face is describing a large amount of content to pass its parameters to the engine. This is not an easy task, given that it is very difficult to find materials on the technical aspects of game design. Well, let’s figure out how to transfer data to the engine.
It takes a lot of time and effort to develop a game. Finding and fixing errors before the release is one of the most crucial stages of the whole process, and the bigger your project is, the more people are usually involved in testing. Even the most uncomplicated games require a proper and thorough examination by QAs. The processes are automated to provide high-level project maintenance by increasing testing speed and reducing the influence of the human factor.
Automated testing is done with the help of specific programs, like Selenoid and Appium (although such frameworks are rarely used in games).
However, the chances of successful automation depend primarily on the genre. Plus, it doesn’t cover all stages. For example, while the analytical issues can be automated, the visual aspect and gameplay are still tested manually (or are they really? We’ll get back to this later). We differentiate the two most popular types of auto testing:
Testing is one of the key processes in development. However, without analysis it is tough to say how effective testers really are. Innotech’s lead tester-engineer Pavel Petrov shared a number of metrics that are being used in project work.
After Epic released the UE5 technology demo at the beginning of 2021, the discussion about UE5 has never stopped. Related technical discussions mainly centered on two new features: global illumination technology Lumen and extremely high model detail technology Nanite. There have been some articles [1 ][2] analyzing Nanite technology in more detail. This article mainly starts from the RenderDoc analysis and source code of UE5, combined with some existing technical data, aims to provide an intuitive and overview understanding of Nanite, and clarify its algorithm principles and design ideas, without involving too many source code level Implementation details.
Lumen is UE5’s GI system, it is different from the traditional real-time GI which only includes the contribution of indirect diffuse reflection. It also includes indirect diffuse reflection and indirect highlight, providing a new set of complete indirect lighting. Lumen supports both hardware-based RTX and software-based Trace algorithms. The starting point of this article is that Lumen GI uses the process, algorithm, and data structure analysis of indirect diffuse reflection part based on software Trace to understand the basic principle and operation mechanism of Lumen from a macro perspective.
The core of Lumen includes the following parts:
Today, we will share some knowledge points related to resource memory leak. A memory leak is the most common issue that we continuously see and also are afraid of. What is the reason behind it? Because we can’t predict the extent of the leak before we locate the leak bottleneck, we had no idea whether it will burst out at a certain moment on the line. We have received feedback from developers that their players had no problem playing for half an hour, but they would get more and more stuck after 3 to 4 hours of playing, which they never expected before. How can it be solved? Today’s sharing will answer such questions.
UWA’s GOT Online-Assets report has a resource occupancy trend chart. If there is a rising trend like the one below, you must pay special attention.
Hey everyone! I represent a game studio without a name, and the project we’re working on goes by the technical name of "CGDrone". I started writing this article earlier today, having tortured myself for ages with sketches, colours, algorithms and correcting bugs in rotations based on quaternions (the last one just about finished me off). You can probably understand I needed a break.
I’ve often come across stories people have posted online about how they made their game, the difficulties they faced, and the result they achieved at the end. Likewise, our team has its own story, and I’d like to share a bit about it.
