News
Dev update #18: houses
Hi there.
The time has come to share the first images of the generated structures in Arcs of Magic. Today, we will start with the houses.
I spent some time doing research on desert architecture, both in video games and in real life. I really like the architectural style of Kenshi, which is also one of the inspirations for the Canyons biome in general. I also happen to have a book on Yemen, and, of course, a general search on the Internet also yielded a lot of interesting designs and styles to choose from.
I decided to use the technical constraints of the engine as one of the founding blocks of the adopted style. In particular, I rely heavily on the single and double-sloped terrain blocks the game features already.
I started by doing some drawings on paper, trying to imagine how a house in my Canyons biome should look like. These are those sketches.
In terms of materials, I finally made use of the wood material that has been hidden in the game for years. I used a light beige color for it to match the color of the trees that are naturally present in the game. Then, I decided to add a brand new stone material, which I called simply "whitestone". It is used for the four corners of the house and for its foundation, providing an original look and breaking the monotony of the wood material. In-game, it is supposed to serve as a robust frame for the house.
On the top of the house, I opted for a typical flat roof you can see in many desert buildings. I added the reinforced elevated corners, similar to what I saw in some Yemeni houses, and a couple of wooden handrails, for both functional and visual reasons.
I continued using the slopes and inner and outer angles inside the house, as well. I think that the wooden ceiling and corners look very nice. They really set the house design apart from its voxel origins.
The houses generate at random locations as long as the terrain is flat enough. I had to add some advanced generation code to make it adapt to the exact terrain configuration. For example, the house's supporting columns have different length depending on the terrain features. The number of steps leading to the doorway is also dynamic, ranging from 0 to 6 steps, and the stairs can go either to the left or to the right.
I took this opportunity to implement advanced "loot tables" that describe the probability of various items that spawn inside the structures, as well as their property distributions (e.g., what kind of spells or skills can be found in the scrolls or the books).
I hope you like the design! I am looking forward to publishing the V6 to make the houses available to all players. Cheers.
-- Alexandre
Dev update #17: the Canyons biome
Hi again.
From the very beginning of the project, the game world has always been a vast expanse of green grass. A flat plain, cubic-looking hills, voxels with slopes, all the way through adding the trees, the grass, bushes and stones, day and night... the landscape stayed green all this time.
No longer. When I wrote the updated 2024 roadmap, I have considered several possibilities for a starting biome. And after weighing the advantages and disadvantages of each choice, I settled on rocky desert canyons.
The canyons have multiple advantages for the gameplay, but also for the game development. The "desert" part, for instance, offers a lot of freedom for having both very hot and very cold temperatures, perfect for the survival mechanics I am planning. It also is quite sparse, and so it would go easy on the number of objects I have to simulate and to draw on screen. As for the rocks, they will allow me not to worry about implementing the footprints that would have been necessary in snow or sand environments.
As for the canyons, I hope it will prove to be a fertile ground for interesting and memorable terrain generation, fostering both the terraforming around your base and the exploration of hidden nooks and crannies. It will add a lot of verticality to the visuals and the gameplay. I plan to use this verticality heavily in the levitation and the climbing mechanics. The canyons should also help a little with the short viewing distance the game has for the moment.
Last, but not least, I think the canyons look gorgeous. The yellow and red tints look striking against the deep blue sky and the green vegetation. They are naturally vast and secluded, also a good match for the vibe I am going for. They feel unusual and full of adventure! At least, they do for me. Let me know what you think and what biome you would like to see next and why.
In this screenshot, you can see the new "packed sand" and "red stone" textures that are now used by default in the terrain generation. Compared to the previous biome, which I called "grasslands", the canyons have a totally different feel to them thanks to the reddish color palette.
This is it for now. Next week, finally, I will publish the screenshots of the upcoming house structures. I must say I am quite happy with how they ended up looking. See you in a week! Cheers.
-- Alexandre
Dev update #16: ultimate blocks
Hi.
Remember when back in March I spoke about massive reworks in the way the block definitions were being handled? And how that would save me time when trying to implement the full 3D symmetry of all block types?
Well, I decided that now was the time to get those block definitions finished and be done with this topic, once and for all. Indeed, when I started working on buildings, I quickly saw that it was difficult to move forward without vertical slabs and vertical slanted walls. Both of these building block types are important to my vision of how the buildings should look like in Arcs of Magic.
But instead of simply defining them manually, as I did in the past, I took this opportunity to automatically explore and define all possible block types that could be built from the existing block types by using rotations or mirror operations.
In a way, the new blocks should correspond to the same "surface blocks" I had previously defined for the terrain height, but "glued" to the vertical walls, in 4 possible orientations. The combinatorics of all those blocks became quite daunting, especially when I realized that the complements of each block type should also be considered as block types in their own right in order to avoid duplicates. So, I was quite happy that I was doing it in an automated way instead of by hand.
The following screenshots are the result of this work. I have expanded the existing 46 block types to an amazing total of 106 voxel block types, all of them different from one another! When considered with their complements, that gives 211 unique block forms. I never imagined that I would need so many block types when I started out with the simple idea of adding slopes, half-slopes and double slopes to the standard voxels.
I am still undecided about one extra block type: "stairs". But this type would actually be quite different from all the existing blocks, as it is not an extension of planes, single and double slopes. Also, I would need a whole bunch of internal and external corners that go with them. Maybe, I will add them later if I really need them for certain architectural choices, but for the moment, "just" 211 block shapes will have to do!
See you next week for the "grand reveal" of the first official biome: the canyons. Take care.
-- Alexandre
Dev update #15: procedurally generated rocks
Hi there.
The V6 development has been moving forward. As of this writing, over 77 days that elapsed from the last post, I worked for a total of 8141 minutes (almost 136 hours) across 42 work sessions (total coincidence, this one). The game progressed at a great pace, but still the V6 is not quite ready.
So, I have prepared a bunch of screenshots for you a little in advance, and will be posting some of them in the coming weeks, just to let you know what has been happening.
And here is the first screenshot I have prepared: rocks. Or stones? I don't know. A little bit of both, I guess, hence the subtitle of the V6.
Along with the trees, stones are not loaded from external 3D model files, but are procedurally generated. For some reason, I thought it would give better results and take less time than manually crafted rocks... I am not entirely convinced of that anymore.
Procedural generation, it turns out, is quite complex. Conceptually simple manipulations still require a lot of time to be implemented, and the visual result is difficult to nail down perfectly. Here, you can see 16 stones of different shapes and sizes I ended up with (for the moment). I started with tetrahedrons and proceeded to cutting their vertices by different amounts, in a sort of a bezel effect. It was supposed to generate all kinds of interesting rock-looking shapes, but despite hours I spent tweaking the parameters, they still somehow look very similar to each other... a little bit like stone slabs.
But, for the moment, it will do, I think. I will always be able to add more variety to the stone generator, now that the basics are in. Totally randomizing the stone orientation instead of generating them all "standing upright" should also help to break the monotony. For now, I had to move forward. I just added them randomly all over the world and started a new task.
See you next week for more V6 screenshots! Take care.
-- Alexandre
Dev update #14: chunk prefetch and ECS
Hi everyone!
I am pleased to report that I am back to working on the main features for the V6. But you may wonder what happened and what I have been up to in the last four months.
Well, I had been working on the structure generation, as planned. Actually, I was coming very close to the end of the "mechanical" part of it and already savouring the creative parts to come, such as defining what various ruins would look like, where to place them, and so on.
Then, virtually at the last commit to wrap everything up, I encountered a problem. The routine that was supposed to clear up the area for a generated structure (i.e., remove the previously generated trees and grass) encountered an assertion (a crash) from time to time. As I dived further into the investigation, I realized that the problem came from the inter-entity relationships ("links") the code was tracking, such as proximity or support relationships. The code needed to remove them; however, it was not possible to do it for the chunks that were outside of the simulation zone.
Further and further it went. I could not coerce the chunks to be generated only inside the simulation zone, as it contradicted the nice inter-chunk generation priority tree that was needed to guarantee dense, yet fully deterministic forest (as mentioned in the dev update #12). Instead, I decided to have two types of links: "online" links used during the simulation, and "offline" links used for the chunks moving outside of the simulation zone, or being offloaded to the save file.
It was complex enough by itself, yet, overtaken by some sort of madness, no doubt stemming from the huge delay the V6 development had already accumulated, I went on to creating a foundation of a home-made ECS (entity component system), followed by a full clean-up of the way the "active context" (i.e, the simulated chunks) is handled, including support for some future features such as teleporting and animal possession, and other reworks.
To crown everything, I added a way to prefetch (load or generate) the needed chunks in advance, in a separate thread, and completely rewrote the way the chunks were being marked for offloading.
In short, I spent four months reworking and refactoring systems that worked "perfectly fine" already. But... did they? Chunk prefetching now allows seamless crossing of the chunk boundaries. However complex the chunk generation, it is done in advance, in a parallel thread, and not during the one tick when the player crosses the border. ECS is in its infancy, but I have great hopes for it. In the future, it will allow cutting down the memory footprint and drastically increasing the amount of entities I am able to handle. And other reworks helped me solve a number of obscure bugs I had no idea how to even start fixing.
All in all, now that it is behind me, I am glad of the progress I made. Sadly, there is not so much to show for it. Fortunately, I have prepared one screenshot in advance. It shows dual-terrain hills, using the dual-terrain slanted blocks I have introduced in February. Here we go:
See you soon for some of the generated structures... at long last. Cheers,
-- Alexandre
Dev update #13: dual terrain
Hi there.
I am making good progress on the V6. It is now running very late indeed, but I am using this time to prepare better foundations for the next phase, including some features I have been delaying for a long time.
One of these features was expanding the block types to support dual terrain, i.e. blocks that have two terrain types in the unit volume. Since the beginning of Arcs of Magic, I wanted to create terrain that would be more realistic than traditional voxels, while, at the same time, keeping the precise geometry and block positioning I love in Minecraft. I settled on adding slopes, half-, and double slopes, and various 3D combinations thereof. This allowed me to create relatively smooth landscapes, and it has been quite sufficient for what I wanted to do until now.
For V6, I wanted to add a layer of rocks under the topmost layer of grass/dirt. This simple addition hit a major roadblock, though. I did not have support for dual-terrain blocks yet, and without it, I could only create full-cube blocks at the boundary between two solids.
Not anymore! After quite some work, I have added not only dual-terrain blocks, but also the corresponding "inverted" terrain blocks, i.e. the upward complements of the "ground-like" blocks. You can see both in the screenshots below.
As it is customary of late, these "simple" changes required massive reworks behind the scenes. Both inverted and dual-terrain blocks triggered sweeping changes in the collision routines, world generation, block breaking and placement, and more. As the number of different blocks grew, I had to switch to automatic texture wrapping as well as automatic calculation of the secondary block metrics such as height maps, occlusion masks, and volume. This dragged, in turn, the creation of a lot of development tools to support this.
The good news is that all this work will also allow me to easily extend the block types further, if needed. For example, later on, I plan to add support for the full 3D symmetry of all block types, i.e., as if the terrain surface were generated for vertical walls instead of a horizontal surface. But, in a desperate attempt to save a little bit of the development time, I scoped this additional improvement for later.
Next up, using the dual-terrain blocks to generate rock layers under the hills. Stay tuned! Cheers,
-- Alexandre
Dev update #12: extreme hills
Hi everyone, and Happy New Year 2025!
Yes, I am running a "little" late for the V6 release, initially planned for October, then December 2024. It is now perfectly clear that the V6 won't be released in January either, so I decided to dedicate a little bit of time to sharing recent progress with you.
In the last months, I reworked the terrain generation system from the ground up. Previously, a very low resolution height map was generated at the maximum "mipmap level", which in my case corresponds to 1024-meter chunks. The actual height map was then simply interpolated as the terrain generation detail level got finer and finer, all the way down to 1-meter blocks in 16 by 16 by 16 chunks. Clearly, such a system could only produce very smooth-looking hills. Steep slopes or cliffs that I wanted to create for the V6 were out of the question.
The new generation system defines "landmarks", such as peaks, hills, or mountains, and is able to generate steep slopes and even sheer drops at any spatial resolution. At the same time, the landmarks can be as large as I wish, covering the whole map if necessary (think mountain ranges or canyons), because they are defined in a parametric way, and only at the end generated at the required resolution.
I started by adding some peaks, low and high (up to 100 meters / 330 feet). You can see them in the screenshots below. They are so high and incongruous for the moment that they brought to my mind the "Extreme Hills" biome name from Minecraft.
As a matter of fact, the hills could be much higher still, up to 500 or even 1000 meters (1500 - 3000 feet), but since the visibility distance is still only 32 meters / blocks, I decided not to push it that far on this occasion. But as soon as the visibility distance is improved, it might be cool to post some base-jumping videos :).
I also spent quite a bit of time on changes that are, unfortunately, quite invisible. First, a modified chunk generation algorithm now guarantees the same result regardless of the direction the players come from to a given chunk. Before, when trees were generated, for example, I checked for collision with already existing trees and did not place a new tree if the analyzed position was already occupied. So, in dense forests, I could end up with different results depending on whether the player came to a given chunk from the left or from the right. The new algorithm, inspired by the four color theorem, establishes certain relative order and well-defined dependencies between generated chunks and solves this problem entirely. I can't fully explain why, but the determinism of the chunk generation felt important to me.
Another behind-the-scene improvement is related to a more precise entity positioning on steep slopes. As I started playing with more abrupt terrain transitions, the limitations of the previous algorithm became clear, as it positioned entities either too high in the air, or deeply buried in the ground. The improved algorithm performs better, but is still not perfect. For example, as grass objects were made for mostly flat ground, they are still buried too deeply on very steep slopes. I will have to revisit this later, though, as the time goes on and I need to focus on more visible features.
So, what's next? The roadmap did not change, so I am still pushing for the features listed in the V6 section. I will refrain from giving any updated V6 release date at this point, but let me assure you that I have been working on Arcs of Magic more than ever in the last months, so it is very much alive. But I will say that I will share additional V6 screenshots very soon! Cheers,
-- Alexandre
Release notes and new screenshots for V4 and V5.
Hi again.
I was so occupied by the actual development that I totally forgot to publish the release notes, both brief and detailed, for the most recent updates, V4 and V5. It is now done!
I would also like to take this opportunity to publish some recent screenshots.
For V4, the extended options menu now features the fullscreen support. You can select the resolution (the aspect ratio matching your screen is listed first and marked by an asterisk) and then, the frequency. Of course, you can still play in windowed mode as well.
The all-new health tab shows your general condition on the left and afflictions, if any, on the right. This tab is also present when examining other objects. As the "Magic" tab, it will show object's properties in this case.
In the following screenshots, you can see two types of bushes introduced in the V4: yew and white currant. Their berries are ready to be harvested!
Also note the updated grass models, now available in three sizes. I decided to start moving away from the heavily pixelated visual style I initially adopted.
In V5, you can consult the fourth tab, "Skills", to see the descriptions of various skills and disciplines. This tab also shows the current skill levels of the player (or those of an examined object).
The following two screenshots show a book on "Hearing I" lying on the ground, and the examination menu for a scroll containing the "Empty sphere" spell. The player can only view the spell, but can not learn or use it, as some skill requirements are not met.
Finally, the V5 introduced two gemstones with slightly different properties: rubies and sapphires. You can see the amount of energy stored in a gem when you are close enough to examine it.
I hope you liked it! Cheers.
-- Alexandre
V5 "Books and Scrolls" released!
Dear All!
The V5 "Books and Scrolls" is finally here and brings the first building blocks of the character progression into the game.
Various spell fragments are now unlocked by learning the corresponding magic skills from the books that are conveniently placed throughout the forest. Certain skills need to be learned in a particular order.
To give you ideas for your own enchantments, scrolls with interesting new spells can now be found, examined, and learned by heart. Of course, you need to master the corresponding skills first.
Last but not least, I have introduced gemstones: rubies and sapphires. The gems accumulate magic energy over time. A skilled wizard can store or retrieve this energy for their own needs. Different types of gems have different properties and uses, which will be further elaborated in the future updates.
This release comes more than a month late compared to the original date. I lost several weeks because of some personal issues; and the tasks, as always, stubbornly refused to be easier than anticipated. I updated the roadmap accordingly (no changes except the dates at this point).
If all goes according to plan, the next update, after years of work, will be finally announced to the public.
It will bring the largest visual update to the game world since the introduction of the day and night cycle: the revamped terrain generation with mountains and cliffs, and the building generation.
Can't wait to be there.
-- Alexandre
V4 "Berries and Weeds" released!
Dear All!
I am happy to announce the first major update to "Arcs of Magic" since the middle of the last year. The V4 "Berries and Weeds" is now available for download!
A completely reworked user interface with all new menu graphics, icons, and fonts makes spell editing more intuitive than ever.
Integration of the industry standard 3D editing format (GLTF) allowed me to introduce more complex 3D models for two types of bushes: yew bush and white currant bush. Both spawn with the corresponding berries that can be harvested and eaten, although eating one of them will cause poisoning, a new affliction added to the game. I have also reworked the grass models, and added "low" and "high" variants thereof.
Speaking of afflictions, you can now see detailed health information for your character in a new menu tab created for this purpose. The health tab joins the inventory and the magic tabs in the main menu. I also added some slight poisoning due to the uncooked meat and a possibility to die directly from poisoning and hunger.
Finally, in preparation for the initial public announcement, I have added full fullscreen support. Display resolution and frequency can now be selected from the existing options menu.
You are welcome, more than ever, to provide your feedback about the game. Thanks to the built-in feedback panel, you can now send me your thoughts directly from within the game in just a couple of clicks.
As you can see in the roadmap I updated earlier this year, I plan to release updates more frequently from now on, hopefully every three months. See you soon to introduce you to the first means of progression: magic books and scrolls!
-- Alexandre
Dev update #11: the feedback panel
Hi again!
A quick update to inform you that I have just added something I really wanted to be there for the public launch: the feedback panel. Now, the players can submit their impressions, thoughts, and bug reports directly from the game itself, at any time! As long as the game is connected to the Internet, the feedback will be immediately delivered to my inbox.
Simple on the surface, this feature requires a bunch of machinery behind the scenes. In the game, I integrated the libcurl library in order to send requests to my server. On the backend side, I set up a dedicated domain, a simple Node.js/Express server, a MySQL database, and a mail sending infrastructure based on Nodemailer and Exim. The last point proved particularly tricky because of the various modern anti-spam technologies making sending an email a more complex process than it once was.
That's it, now onto some other tasks. See you soon!
-- Alexandre
Dev update #10: 3D model import
Hi!
Before being able to fully focus on the development of the missing mechanics and content, I still had to add one last major missing component to the game engine. I am speaking about an ability to load 3D models from an external editor like Blender.
Until now, I had only a handful of models, and each model was as simple as one could possibly imagine. The most complex models (the wolves, for example) had only 6 cube-like shapes in them, for a total of 72 triangles. They were so simple that I created most of them by hand or with some help of a trivial built-in 3D model editor I created. The textures were drawn for each face separately in Microsoft Paint.
It had been obvious to me for a very long time that I would need a serious 3D model import feature in my game, whether I planned to use assets, to pay a contractor to create models for me, or to create the models myself. And now, it is finally done!
After some analysis of the existing 3D formats, I settled on using the GLB format, the binary form of glTF. Its documentation is freely available, there is a large selection of actively maintained loader libraries (I chose tinygltf), and it is supported natively in Blender via the official import/export plugin by the Khronos Group itself. Also, it supports animations, too. Even if I did not implement the animation import yet, I will certainly need it in the future. All in all, it looked like a perfect match for my needs.
And here we are! After some tinkering with the loader library (actually, a much larger effort went into adapting the game's internal data structures than into integrating the library, which was really straightforward), I was finally able to import... a cube! The cube looked no different from the cube I had previously, but now it was a real, professional 3D cube :-).
Since I never did anything in Blender before, I decided to spend some time learning it. I found a great YouTube tutorial by some guy who is very passionate about donuts. I followed it for a bit, but stopped just after the icing, as I wanted to do some low-poly models myself. Even so, seeing a high-poly model (13848 triangles in just one donut! vs. 72 in a wolf) inside the game for the first time was impressive.
Finally, I modelled and textured a small low-poly shrub from scratch. Trying to learn 3 new tools at once, I used Krita and a pen tablet for texturing (also for the first time). It was really fun, despite the fact that somehow I messed up the coloring in some places. I will definitely have to redo this model completely, yet somehow making my first 3D model felt like moving the game into another dimension.
That's it for now! I will be learning more about Blender and texturing, and adding new, less cubic, models into the game little by little.
-- Alexandre
The roadmap update (2024)
Dear All!
It has been over 18 months since I published the V1 of Arcs of Magic, accompanied by the first version of the public roadmap. Until now, I tried to stick to it as much as possible. I think it was really beneficial for my development process to have some sort of public commitment to keep the effort going in the right direction and to avoid changing the scope every now and again.
But even as I neared the completion of the V4, which was supposed to be pushed more proactively to the community, I realized that its scope was not sufficient for the first truly public demo. I would like to emphasize that this is not a case of "I need just a little bit more polish" or "just a couple more features". I have been learning a lot about the game design, be it by reading professional books, by watching video game reviews, or by reading the appropriate Reddit subs. And I learned that several vitally important things are missing in the game right now. Something that should have been there since day one, so to speak, but has not.
What is worse, some of those things were not even in the roadmap! And even though they were always implied, another thing I have learned since V1 is that if I want something to be in the game, it must be in the roadmap. Explicitly. Otherwise, I simply won't have time for it. Otherwise, as I look at the roadmap every couple of weeks to think about the upcoming tasks, I will focus on other things.
So, what are those mysterious things I totally forgot about in the first version of the roadmap? They are, in fact, obvious for any experienced game designer. Arcs of Magic is missing a reason to do things. I felt it, of course, but without a framework to guide me, I mistook it for missing mechanics or missing features; while in fact, I have been missing the core game loop. After some consideration, I boiled it down to the following list:
- Magic progression as the core loop. Every action should feel as taking one's character further, and not as simply repeating the same chores every day. Classic RPG skills (strength, survival skills, and so on) remain planned for later on, but I do want to include the magic related progression as soon as possible. For this, I plan to add some books or scrolls, progressively unlocking new spell fragments, as well as the gemstones, allowing more power accumulation. And of course, some grimoires should provide a steady supply of already written spells. That would provide useful utilities, while illustrating the spell-crafting mechanics at the same time. Newly discovered spells will require more power, which will be provided by the new gemstones, and both will require an ever-expanding exploration. I must say I am quite baffled by the fact that none of this was in the original roadmap at all.
- Exploration as a means of progression. It really is exceedingly boring to wander through the same-looking hills with only some slight variations of the tree density. This is why two major features must be added as soon as possible: a "strong" landscape generation (I am thinking of canyons now) and some sort of ruin generation. Both items were present in the previous roadmap, but either too far away, or as a feature among others, and not as one of the cornerstones of exploration. The ruins will, of course, contain rare tools and resources, and various magical items to support the magic progression.
- Danger. It is also essential to provide the player with stronger risks.
- With only two types of animals at my disposal right now, I must improve the animal AI, while making them faster, more aggressive, and more numerous. Their patrol routes must cover more area. Sleeping in the open should virtually guarantee an attack during the night. This will provide reasons to fortify or to magically protect your base or your camp, as well as to look for advanced offensive and defensive spells, weapons, and tools.
- I already have the temperature mechanics, so I should use it to create environmental threats as well. The nights must be colder, with a real risk of getting sick if you sleep in bad conditions. This should push the player to build campfires in order to stay warm and to build some sort of shelter to avoid sleeping on the ground. Adding a risk of food poisoning is also a great addition and an easy one to have.
- The wounds must be more dangerous and should not simply heal over a short period of time as they do now. This should prompt one to have a base where one can rest and keep a stock of food, or to learn some healing spells.
And this is what led me to making two decisions. First, to totally rework and to publish a new version of the development roadmap. I am publishing it at the same time as this post. And second, to push back the "public announcement" of the game (I will, of course, continue publishing the new versions on arcsofmagic.com). The second decision is particularly hard for me because it means that I also postpone the moment when I will be able to receive the first objective feedback from the community. Still, I am convinced that the latest changes will put the game on a much better track overall. If someone is reading this - let me know what you think!
Talk to you soon. Cheers.
-- Alexandre