It has been some days since the latest post, thus now is the time for a small recap of what happened during this time. Overall, I’ve been mostly working on bits of things rather than huge systems, which is the primary reason of the lack of post over this period.
Here we go :
– I’ve improved the UI little by little when I needed some functionalities. I’ve notably added a progress/loading bar control which is now used to display in more visual way the life of an entity. The skillbar has been enchanced a little, and can now display a hotkey (placeholder art inside) :
– The only big task done was the rework of the animation system. The main reason for this rework was to add interpolation between animations, so that it stays fluid when starting/stopping to run, fighting, etc. Mission complete. I also took advantage of this rework to switch most of the internal rotation code to quaternions.
– Meshes displayed using instancing can now be animated with a wind effect, grass for example. No video at the moment, but it will come in due time.
– The base of the city system has been built. When the terrain in generated, it adapt itself so that the buildings above it fit properly :
– The player character model has been reworked. I added four new equipment slots. One for the helmet/hair, one that is used to show neck protections such as gorgets or scarfs, and the two others that are use the right and left pauldrons. The legs are bit bigger, too. I’m pretty satisfied with what it’s looking like now, with a heavy armor, but I have more tests to do with lighter armors. I’m keeping that for a future video, too.
Of course, that’s only the tip of the iceberg. There has been other minor subtasks, I’m continuously improving the game design of the game, sometimes reducing its scope, sometimes adding a small feature, etc. And at the time, I’m working on improving the battle system.
Amongst the various things that can take a lot of time when developping a video game, you can find the user interface, aka UI. In many games, it’s one of the major way used to interact with the game, when it’s not the only one. Thus, it’s *kind of* an important task to complete. It’s not usually a complicated one, but it requires a lot of time considering the amount of features it needs between the simple variety of controls needed, and the many game windows and popups to create.
Here is what it’s looking like at the moment :
On the left you can see an item detail panel. This one is a test, it’s not linked to real data, which is the reason why it’s still incomplete. It’s the control I’m working on at the time.
On the middle, there is a test inventory window. It can move freely within the bounds of the screen, contains a text button and a checkbox, both working the way one could expect. More interesting, the bottom part of the window is a “container”. If you’ve ever played to a RPG, especially online ones, you should know fairly well what it does : represent an inventory and the used/available storing space.
Items inside a container can be activated (e.g, : use a potion, a scroll, etc) or moved between different slots of the same container for reordering purpose.
If you look at the bottom and right of the screen, you can see two skillbars. Both contains a container. The difference between the inventory container and those of the skillbars is that the later only contains “shortcuts” to items (or skills). It’s possible to drag-and-drop an object from the inventory to a skillbar.
If you’re attentive, you might notice on the right skillbar an image button above it : it’s the rotation button, used to switch between horizontal and vertical display. The skillbars can be moved like any window.
I still have add tabs, radio buttons, tables, listboxes and comboboxes. The scalability is not complete at the time (only window and buttons works with it). More interesting – I guess – the UI is already fully skinnable. I use an external XML to describe the graphical elements.
In case you were wondering, the weapon icons and UI skins are tests. I won’t keep them as they are now.
After some time working on a very basic landscape… which is basically just a 3d heightmap, I’ve made a new step by adding the system that will handle everything related to scene details such as vegetation, rocks, buildings etc. It’s a good occasion to talk a bit about both technical and design aspect of these things :)
Very often, when it comes to voxel games, the default solution to display scene details is to merge their mesh with the terrain mesh. It’s indeed a very efficient and flexible solution, since it easily allows things such as unique trees, and does not cost much in terms of performances compared to the terrain alone. But it’s only true as long as you don’t want the the scene details to be too much detailed.
Put two detailed trees on a chunk, and you’ll have two detailed trees in memory. Every time you’ll add a tree, it will be a new tree in memory, too. When having a lot of details, it can quickly get out of hand. Luckily, there are a few alternative techniques to render numerous objects, and one of them is hardware instancing. Rather than just duplicating elements, we keep a single tree/house/whatever mesh representation in memory, and display it at defined positions. There’s still an overhead for each duplicata created – its position – but it’s ridiculous when compared to the cost of duplicating a whole mesh. Hardware instancing has a drawback compared to the previous option, though : a single shared mesh means no unique trees or rocks. Is it a problem in my case ? No. And even if it was, there are some tricky workarounds, anyway (such as generating part of the mesh on the GPU).
My take on scene details is not only that I don’t need uniqueness, but that I don’t want it, nor I want too much of them. I’ll explain : one of the thing that I really want Metaworld’s graphics to allow is for the player to be able to recognize things. To avoid to send too many graphical informations, while still being good looking. Do you remember the 2d tile-based games from the 80-90s ? It’s close to the kind of redundant visual richness that I’m looking for. The tilesets of those games were originally a way to minimize memory usage, but they created a graphical style and – in my opinion – self-explanatory signs, because interactive details could be recognized easily.
If you don’t know what the expression ‘signs and feedbacks’ refers to in game development, it’s basically all the graphical polish used by the game to indicate to the players that an action occured (feedback) and to guide them through possible actions (signs). Examples : when a button is disabled, it’s usually gray. This is a sign (the user can’t use it). When the button is enabled, it’s colored. Another sign (the user can use it). When a mouse cursor is put above an enabled button, and it changes its color, it’s a feedback (the user has put the mouse above the button). If the user clicks it and the button appears pressed, it’s another feedback (the user clicked it).
Another sign example in games : when a player can interact with an object, it’s really common in modern games to have it glowing in some way. Most of the time, this sign is here because the players can’t understand “naturally” by seeing the object that they can interact with it. The question is, why can’t they understand it ? Usually, it’s because there’s too much of everything everywhere, making nothing recognizable until after a long learning curve of what is interactive and what is not. It’s not really a problem as long as there are additional signs, but where tilesets were awesome, it’s that their redundancy implied a short learning curve, leading the players to be naturally curious and interested about anything new or unusual. They tried to interact with it.
I don’t want a mining rock to be all shiny because players can’t differentiate it from a normal rock. I want the players to be able to tell that it’s not the same rock that they know. For new players to wonder “why is this rock different ?”. Curiosity and action. This is the kind of spirit that I’d like to give to Metaworld. Even through something as basic as environmental details.
I’ll conclude with an interesting note : even when some details were not interactive, they are sometimes so weird that people believe that they must be interactive, and thus start to build theories extrapolating how to activate them. Before the advent of Internet, unusual details could even creates the so-called “rumours” and “secrets”. One of the most infamous probably being Pokémon Red/Blue’s truck :
If you look at some of the most popular voxel games, I’ll say – totally randomly – Minecraft or Cube World, you tend to notice quickly that their camera range view is not exceptionnal, unless you have a 4000$ battle computer with a lot of memory and great CPU/GPU. It’s something that has always bothered me a bit, since I like games to have huge landscapes to show to the player. It’s something that helps a lot to increase immersion or at least to keep a coherent and believable world. It’s something that I’ll try to accomplish with Metaworld.
There are a few ways to improve a game camera range without killing your computer, and one of these is to implement a level of details system (LOD). LOD systems are a common graphic optimization technique in video games which consists in reducing the amount of triangles of the meshes to display. It’s a technique implying some quality-loss, but it’s supposed to be primarily used on meshes that are so far away from the camera that their details can’t be precisely distinguished in the first place.
A chunk in Metaworld is currently 32 voxels wide. The most obvious solution to simplify the generated meshes is to divide the chunk precision by two to have a second detail level (16 voxels wide where 1 cube = 2 voxels), then two again (8 voxels wide where 1 cube = 4 voxels), etc, until the geometry is not detailed enough to be interesting to show.
Regarding the above issue of gaps between meshes – on which one I struggled a bit – I tried to simplify as must as possible the problem, since it’s often a good path toward a solution. One of the major simplification is that I only needed to care about the transition from a high detailed chunk to a lower detailed one. This is the typical LOD case, after all. When creating such a system, you want the chunks close to the camera to be detailed, and those far away to be less detailed. There are no common case where you should care about the transition from a low detail chunk to a high detail one, that would imply that the LOD is reversed.
In the end, it took me two days to have a LOD system satisfying enough, but the memory cost has been divided by 4. Worth it, I can now display farther than before :)
If there’s one thing that I should start to do with this blog, it’s to explain a bit more what is the game I’m working on.
My project is to create an online game with some of the usual RPG elements you find in MMOs : equipment, stats, classes, skills, PvE. Classical but well-rounded game mechanics. Contrary to most RPG, I don’t intend to add a story to the game, only a context and an ambience. This is the reason I’m only talking about “RPG elements”, and not a full fledged RPG, where role playing/story is normally a core part of the game. I’ll probably detail the reasons of this choice in a future post, but one of the main is that the core gameplay that I’m targetting is all about player interactions and player cities. Open world and PvP are parts of these interactions. Note that I’m trying to build the PvP in a somewhat “political” way so that the abuses usually seen in PvP games (chain kill, grey kill, spawn kill, etc) would be naturally detrimental to the PKs, and force them to choose between being able to have normal player interactions and poor behaviour (not that I’m fundementally considering such lacks of fair-play “bad”, it’s player freedom, but retaliation from the PKed players should be possible by some means, if not from fighting).
Regarding the game scale, the goal is to create a server able to handle between 1k and 2k concurrent users. I’ve already developped some months ago a game server that went to production and handled above 2k concurrent users. Thanks to this prior experience, I’m confident that I should be able to reach these numbers even with a more CPU-hungry game.
I’ll conclude this post with a project name : Metaworld. It’s not very specific, but its purpose is mainly to give the game I’m working on a name that can be used to designate it. That way, I can avoid to use “the game”, “the project”, etc. It’s way more practical!
If I have to pick a real name at some point, I’ll take the time required for it. Picking a definitive name is not exactly a priority at this time considering how much Metaworld can change.