Nebuchadnezzar News

Hello and welcome to our first true dev diary post. Today we’d like to inform you about developments from the last two and a half months. Particularly, the beta testing phase of Nebuchadnezzar’s first fully playable version and the results from the testing.

The first of our big milestones was to have a version of Nebuchadnezzar containing the first five missions—including all the features, graphics, UI screens and tutorials. It was important for us to have all these elements in place because we wanted our beta testers to get the game in a state that was close to the final release, so the feedback could be maximally relevant.



By the middle of March everything was ready. As you may know from our social media, the beta testing was limited. Mainly for our friends and colleagues from the game industry—including some experienced testers. We didn’t want them to fill out any forms, but rather to write down as much feedback—the good and the bad—as possible.

In following weeks we will introduce to you what we had changed and implemented based on the feedback. Today we will show you how we dealt with Nebuchadnezzar’s tutorial.

[h3]Tutorial[/h3]
The tutorial is one of the elements of the game that drew many different opinions. In Nebuchadnezzar, we decided to implement a form that’s both a tutorial and in-game help. All the game mechanics are divided into about 20 topics. In each of the first five missions, several topics are unlocked and the player is notified by a graphical UI element. Unlocked topics always explain a feature appearing for the first time.

Most of our testers appreciated the fact that the tutorial is not scripted and that the player is not locked down to any specific gameplay or layout sequence. The player can even completely ignore the whole tutorial…but, of course, we strongly discourage that ;)



An aspect of the game that was heavily criticized was the fact that the first mission introduces an excessive amount of mechanics—which can overwhelm the player. Unfortunately, due to the nature of the game’s rules, even the first mission (although very simple) must explain a lot of how the game operates.

But still, we felt we could do something about it. We felt the tutorial’s form was the right choice, so we didn’t want to change it. Instead, we decided that some topics won’t be unlocked right away, but rather they’d be revealed after certain “triggers”: like building a specific building.

That’s all for today. Next time we will show you many other changes which we have implemented based on the feedback. See you soon!

And as always, you can also read and discuss this blog post on our websites, forum or reddit.

Hi and welcome to our next blog post. Like the last one, this post will focus on graphics. We’ll show you the evolution of one of our in-game menus: the Warehouse menu. It’s an example of the game making process that’s not straightforward. Rather, it goes two steps forward and one step back. It’s constantly re-evaluated and reworked.

In the first picture you can see part of a “prehistoric” version of our Warehouse menu. Except for the goods icons, it was not yet touched up by our graphics department. We’ll breakdown the menu here now, so we can focus on graphics later in the post.

The first column represents warehouse storage—specifically, the current number of goods in the warehouse and it’s maximal storage capacity.

The second column features two arrows for each of the goods. These arrows alter the duties of the transport units (the delivery people) within the game. The first and second arrows activate/deactivate the ability to carry goods either to the warehouse or from it.

The last column contains a 3-state button that determines the activity of caravans. Caravans may export goods, import goods or do nothing with the goods in the warehouse. What exactly are transport units or caravans is not important for the following text.



The second image shows the first design of this functional prototype. The last column’s buttons changed from single, 3-state buttons (none) to three 2-state buttons with exclusive states. So now there’s the ability to change the activity of caravans in a single click. We also added triangle-shaped buttons to alter the maximum storage capacity of current goods, and we replaced the basic arrows with triangle-shaped buttons. We added small dots to improve button indication. We also added a stripe on the top of the menu with descriptions and icons for all the columns. Additionally, we added decorative elements throughout the menu for more aesthetic appeal.



The next picture shows some minor tweaks of the background graphics to improve readability. We also added more goods to the right side of the menu to give an impression what we’ll have when we further develop the menu. You’ll notice some of the goods icons on the right side are just copied to the left: they serve as placeholders for now, as we’re working on developing the rest of the icons.



Minor tweaks of the background in attempt to lighten the whole menu a bit.



…the next tweak was to reduce big contrast gaps between background stripes to let the players focus more on the information layer instead of the background graphics.



…which worked well, but the end result was too flat and boring.

The next iteration was quite big. We replaced the triangle storage capacity buttons with plus/minus buttons to better represent their function. We also added an arrow button to remove all assigned goods. Background graphic decorations were replaced along with the icons for the transport units and caravans.

On the bottom part of the window we added buttons for the easy setup of all transport units and caravans. And on the very bottom, we placed a “shield” icon to represent the warehouse building (using a picture of the bakery as a placeholder). We also removed some of the redundant indication dots.



We also tweaked the plus/minus buttons, which we found too small.



We added a background stripe behind the rows of each of the goods: the stripe disappears for goods with zero storage. The shield was removed—we decided to use it for production building menus only.



Caravan buttons proved too small for comfortable clicking and reading, so we replaced them with a single 3-state button. Essentially, we returned to the original system in the first version!



In the latest iteration, we changed the function of the disappearing background stripe. We really liked the idea of highlighting important goods for specific warehouses, but the capacity of current storage was not the right indicator. Now the stripe disappears when its goods have deactivated both transport units and caravans. This means that there can’t be any interaction with these goods in the warehouse, so the player doesn’t have to bother with them.



During development we also added features to let players change the number of columns. It helps for having a better layout considering the varying number of goods during the campaign, varying screen resolutions and, of course, future mods.



Here at the end, we’d like to mention this it the final stage of this menu. At least for now. But there can be a revision at any time, based on our or some player’s experience. If it’s necessary, we’ll make the fix.

This topic is an example of the development process for a partial feature of the game. The point being that you can consider the whole game as a sum of partial features like this one. So maybe now you can imagine that development of a game isn’t always straightforward: from the idea to the final product. There’s usually a lot of hidden work and from time to time…dead ends.

We hope you liked this post. Wish us a minimum of dead ends and stay tuned!

And as always, you can also read and discuss this blog post on our websites, forum or reddit.

Hi and welcome to our next blog post - How to create game content so it conforms to the player’s point of view within the game screen. This one is less about programming and more about graphics – so it’s written by the best artist in our graphic department (…who also happens to be the only artist in our graphic department).

Many grid - based world games use axonometric projection. Axonometric projection is a type of orthographic projection used for creating a pictorial drawing of an object, where the lines of sight are perpendicular to the plane of projection, and the object is rotated around one or more of its axes to reveal multiple sides. One of subtypes of axonometric projection is called isometric projection. You might already be familiar with isometric projection because it was used in many well-known older games E.g. Fallout 1&2, Baldurs Gate 1&2, Sim City 2000, Age of Empires, Pharaoh etc. And now it’s making a comeback in many indie games.

But here we have to confess that we mispoke to you a little bit in the previous paragraph. Often, many games that claim to be isometric are not really isometric. This word is frequently used but typically it only means that a game used axonometric projection. There is another subtype of axonometric projection called dimetric which is more commonly used. And that’s the case with Nebuchadnezzar, too. We also use dimetric projection.

So, how does dimetric projection work? Imagine a grid-based game with a top down camera. The grid and two buildings placed on it would look like this:



Everything is well-arranged but most players would like to see more than the roofs of buildings. Let’s see how it looks if we used dimetric projection:



See the difference? We can clearly identify both buildings, which is usually crucial for strategy games. And on a visual level, to see the whole of a building is nicer than just the roof. So what exactly does dimetric projection do? In dimetric projection, vertical distances on a grid are halved.



This is important if we create game content in some 3d package (software). Because we need to find a proper position for the camera according to the grid in order to render a tile exactly in dimetric projection.

So how do we achieve this? Less programming doesn't necessarily mean no math. Even creating a game’s graphics requires some elementary knowledge of math. So we will calculate it as you can see in the next image. To get the halved vertical grid on the rendered image, we need to set up the camera angle to 30 degrees (fig. B) compared to the top down view (fig. A) where the angle is 90 degrees (for 90 degrees the grid is rendered as is).



Now we knows the correct angle so we can setup the render camera to get our buildings in dimetric projection. But when we do that, we usually get something like this:



As you can see, it’s not what we wanted. The grid lines go towards the vanishing points that are placed somewhere out of the image. So what does this mean? It means that the camera is in perspective mode. To get proper dimetric projection we need to switch the camera to orthographic mode. And the result is:



So that’s the trick to get a desired diametric picture. In a future blog post, we will return to this topic from the perspective of guidelines for creating content for mods.

So stay tuned and thanks for your support and sharing!

And as always, you can also read and discuss this blog post on our websites, forum or reddit.

Hi there. Today we have an example of a mission screen for you. In each of these screens, you will find mission objectives in the upper part and some historical context in the rest. It will cover both the historical period and the city where the mission takes place.



Share your thoughts on our forum, twitter, facebook or reddit and help us to make perfect game.

Hello and welcome to part two of our blog post about map coordinates in Nebuchadnezzar. Today we’ll go over the difference between screen space and world space, as well as how they’re converted into each other.

Last post we discussed the map-tile coordinate system—but the coordinates described only represented an internal arrangement and didn’t show outward appearance. So the user can’t tell if the game is using the Staggered or Diamond coordinate system—or a completely different one.

However, what we want from the game is for the player to see where all the tiles should be. Before we can show how it’s done, we have to explain a few concepts.

[h2]Screen space[/h2]
The screen space is the area where the player can see what’s on screen. Object positions in this space are in relation to the screen. Typically, this space has a screen resolution size and its units are pixels.

The origin (zero) lies in the upper left corner. [x] coordinates move to the right. [y] coordinates move to the bottom. This differs from the typical space in mathematics, where the origin tends to be at the bottom left corner and [y] coordinates moves upwards.



[h2]World space[/h2]
World space is the space of all objects in a game that describes their position in the world of a game. From the player’s point of view, it’s irrelevant where this space starts and what coordinate system it uses.

An example would be the position of the place where the main character is standing.

However, whether the player sees the hero depends on the positioning and setting of the world-sensing camera. That’s because the camera determines how the world’s objects are displayed on screen. This transfer between the world and the screen is called projection.



If we have an isometric game where each object is always on a specific tile or group of tiles, and it’s fixed to this position—the coordinate system of the tiles described in the previous blog post would sufficiently represent the whole game.

But this is not an example of a typical isometric game. Nor is it typical in Nebuchadnezzar. An example being: the movement of walkers moving smoothly from one tile to another. This requires walkers to sometimes be in the middle of a tile and sometimes to be between two tiles.

Therefore in Nebuchadnezzar, as a world space, we must consider not only the individual tiles, but also the absolute position of each object. Yet the space of isometric tiles provides many advantages—above all, legibility and clarity for players.

Because Nebuchadnezzar is a 2D isometric game, the transformation between screen space and world space is relatively simple. The only transformations our camera applies are translations (the world will move around on the player’s screen) and scale (the world is rendered larger or smaller on the player’s screen). What’s a little more complex is figuring out which tiles belong to a given position in the world space.

Of course, Nebuchadnezzar supports rotation, too, but it’s not done at the camera level (as is common in 3D games)—but rather by rotating the entire world space and its coordinates. We’ll have more on this in another blog post.



[h2]Screen to world[/h2]
Here’s an example of a situation where we need to convert from screen space to a specific map tile: The player wants to make a building and clicks on a specific location on screen. The game must first determine the cursor’s position in the world coordinates. And so it applies inverted transformations (opposite to those used in rendering) to the cursor’s position in the screen.

This will give us a position in the world space and from here we will then calculate a specific tile of the map. Again, the calculation is more complicated in the Staggered system than in the Diamond system. Now we have a specific tile and we can build the required building on it—but only if all the conditions for construction are met, of course.



[h2]World to screen[/h2]
The conversion from world space to screen space is mostly applied in rendering the game, because for the player we need to depict the world as “seen” by the current camera.

We hope you enjoyed the post. Feel free to share any thoughts, ideas or questions.

Below you will again find some samples from our source code related to the operations described. Feel free to try them out in your projects.

And as always, you can also read and discuss this blog post on our websites, forum or reddit.

/**
 * @brief Get tile coordinates from world space coordinates.
 *
 * @param pos Coordinates in word space.
 */
N_Point Tile_Scene::pos2tile(const N_Point pos)
{
  const int base_x = pos.x / TILE_WIDTH;
  const int base_y = (pos.y / TILE_HEIGHT) - (pos.y < 0);
  const int off_x = pos.x - ((base_x * TILE_WIDTH) + TILE_HALF_WIDTH);
  const int off_y = pos.y - ((base_y * TILE_HEIGHT) + TILE_HALF_HEIGHT);

  const bool inside = (std::abs(off_y) != TILE_HALF_HEIGHT) && ((std::abs(off_x) / (TILE_HALF_HEIGHT - std::abs(off_y))) < 2);

  if (inside) {
    return {base_x, base_y * 2};
  }
  else {
    return {base_x - (off_x < 0), (2 * base_y) - 2 * (off_y < 0) + 1};
  }
}

/**
 * @brief Get world space coordinates from screen space coordinates.
 *
 * @param pos Coordinates in screen space.
 */
inline N_Point screen2scene(const N_Point pos) const {
  return {
    (pos.x / scene_zoom_factor_inverted_) + scene_offset_.x, 
    (pos.y / scene_zoom_factor_inverted_) + scene_offset_.y};
}

/**
 * @brief Get screen space coordinates from world space coordinates.
 *
 * @param pos Coordinates in world space.
 */
inline N_Point scene2screen(const N_Point pos) const {
  return {
    (pos.x - scene_offset_.x) * scene_zoom_factor_inverted_, 
    (pos.y - scene_offset_.y) * scene_zoom_factor_inverted_};
}