Voxel game project: Rituals of the old

User Code & Projects
64

Happy birthday Rituals of the old!

Rituals of the old has now been one year in the making. It’s been a wonderful experience so far. We’ve had our ups and downs along the way. We’ve had many newcomers some of which have stayed and a lot of people going away after realizing that game development is actually hard.

728×90

Let me talk this time a little bit about what I do in the project.

As a game designer and project leader of a small indie team much of my time is spent between organizing the group, researching background information for features, finding good references for artists, trying to build up a presence in social media, maintaining the blogs, websites and public relations – and among all that, creating the design documents for Rituals of the old which define what the game should be like.

When it comes to the game design - and if I have a choice - I work mostly at the tasks I feel inspired to do that day. Sometimes that means constructing parameters for character creation or designing how the survival system and respawning works. Sometimes I just look for movies, stories or other games for passive inspiration – gathering experiences and reflecting upon what really moved me and how it could be used in the project.

640×555

themiddleman working on particle effect

The thing is - you can’t force inspiration. Sometimes you only get about 10 minutes of good work per day – and you will know ”that’s it”, that’s all you’re going to be able to do today. I have a very active mind and imagination and I’ve never ran out of ideas so far, but the creation process is like a journey and every now and then there’s a bend in the road and you don’t see what’s coming around the corner until you get there.

So that’s the creative part. It’s usually very simple. You just write down a couple of words and that’s it, that’s the beginning of something great.

The rest of the work is just expanding upon those few words - and that is the hard, the non-inspired, part of the work which takes a lot of time and preparations and it bogs down and depresses most people by the sheer magnitude of it.

788×900

Moo!

For example, when I’ve been creating an artificial language for the game it sometimes takes two or three days to come up with a translation for a particularly tricky word. But usually it’s much faster than that - we’re talking about 20-50 words per day. But that one abstract word which has no real connection to anything might need a lot of research into it’s etymology and it’s various meanings, connotations and synonyms in other natural languages to get to that feeling, epiphany, or realization what the words really means and how to best express it in the constructed artificial language.

The work is 1% inspiration and 99% back breaking hard work.

I usually start my working day at around 10 am and keep working on various things on and off until 1 am of the next day.

The first thing I do when I wake up is catch up with what’s been going on during the night when I slept – when you have people working on the project on several different time zones it’s important to respond to any issues as fast as possible. Otherwise small delays in the coordination might easily be stretched into days or weeks of lost work time.

1042×919

Working on Root language on our internal wiki

After catching up I usually do my best and most creative work. A fresh mind can solve an abundance of problems in the morning that a person worn down by days work and activities is unable to resolve at night.

After some time it becomes impossible to continue doing any inspired work and I switch to repetitive and tedious tasks which don’t require as much thought and focus.

Eventually even the repetitive and tedious tasks overpower the mind. That’s when the actual work is done for the day and it is time to switch to research – to search for new ideas and concepts that might be useful and interesting. This is mostly watching movies that are somehow related to the subject of our game or playing games revolving around the same matter.

In between research and mundane tasks I coordinate the efforts of the other group members and keep up with forums and social media.

Finally late in the night there’s another chance to do some creative work when everything quiets down – but it’s not the actual inspired work, as that is best done in the mornings. It’s rather the work which expands upon the earlier inspired ideas.

I’ve been working hard at building and expanding our internal wiki now for bit over a year or so and there’s still a lot of work to do in the game design.


Sometimes moving forward feels like going backwards - ans sometimes you’re actually doing that.

The work load is simply staggering for a one person. Fortunately everything else is always lagging behind what I do and usually I have plenty of time to get the initial designs done before coders and modeler are ready to pick up more work.

We’ve also recently obtained a new member, AnotherDoor, whose job is solely to focus on the game design. He has been a big help in that department.

Our lead coder, Bensku, has been hard at work for several months on the next version of our in house mesher, Terra, and it’s getting ready sooner than later. After hooking it up with networking and solving the remaining multithreading and i/o issues we will implement a simple terrain generator to get some testing done. You can expect this in the next few months or so.

Getting proper world generation, biomes and physics done is going to take longer. Don’t hold your breath for that yet. We’re still knee deep in the initial building and designing phase.

1023×763

Bensku working on our mesher, Terra

You might remember seeing some early screenshots of the account registration and login systems. We’re currently in the process of revamping it and moving it to the web. It was previously embedded in the launcher but since we’re going to need a web based account handling anyway we thought it prudent and useful in the long run to tear it out of the launcher and start moving it to the web. In the future when you click ”register” in the launcher it will open a web browser and you will be directed to a secure web page which handles the account creation, multiplayer keys, etc – your account.

The future

After we’ve broken through the resistance of these low level tasks we’re in a really good position to start building support in the code base to prepare us for the implementation of the higher - more abstract - functions. This will include but is not limited to things like Entity Component System, primitive building support, physics and support for player interactions with the world and entities and so on. In other words things that will eventually serve as a foundation allowing us to start building the actual game.

We’re still far away from that, but we’re a bit closer to a very interesting prototyping phase where things will start to form up in a tangible way.

  • Pilvinen out!

728×90

Web pages: https://www.ritualsoftheold.com
Forum: Redirecting to new forums
Discord chat: https://discord.gg/jCQW4uC

5 Likes
65

I wrote down some of my thoughts about UIs in gaming:

Audiovisual Feedback Based Simulation

and the death of the classical UI paradigm in gaming

The premise

This paper deals with UIs from the perspective of the gaming industry. We set out to describe the common classical UI paradigm as we see it. We also deal with the function of UIs in games - the problems they propose to resolve and the problems they represent to immersion in gaming.

What is an UI?

UI – or User Interface – is an abstract metaphor which tries to convey a two-way communication between the human experience and a machine through the use of symbolic representations and audiovisual cues.

Why do we need UIs?

To understand the solution we must first understand the problem. Games - and computers in general - have a very narrow band through which they can communicate with us. If we ignore the fringe cases we are left only with the audio and the visual. Of these two we will mostly concentrate on the visual since the audio is mostly on par with reality and has very little symbolic representations which concern us.
So why do we need UIs? Games cannot convey things like feelings, thoughts, thirst, hunger, desires or the sensation of touch directly. With only the visual experience to aid us it comes naturally to us to resort to symbolism.
The thirst and hunger become bars on the UI. Feelings and thoughts become words or facial expressions. Desires become text elements or icons on the UI. Touch – damage – becomes a red haze on the screen.
Sometimes this is absolutely necessary as there are no other ways to represent these things in a medium restricted only to audio and visual bands.

The classical UI paradigm in gaming

When I refer to the classical UI paradigm I refer to a very specific phenomena and approach to user interfaces which has become a common industry practice. More than anything this approach is the result of the natural evolution of hardware, software and gaming industries and continues to be supported as a standard practice in games - mostly by convenience.
We shall approach this paradigm through the use of five of the more obvious examples.
Example 1 – Making items
In many games making items has been abstracted away and reperesented as an UI element which portrays the process of manufacturing. Usually you open up an UI which is often a graphical box of some sort with a grid or list. You choose the item which you wish to make by a selection method the game offers, most often represented by a list of names sometimes accompanied by images. And you most often pay either with time or materials or both for the item. Sometimes making items requires special skills.
Example 2 – Numeric representations of condition
Item/player/structure condition is often represented by numbers. Either a fixed or sliding scale portrays how good or bad, how healthy or sick or how valuable something is. Sometimes these numbers are represented visually by a status bar or a color.
Example 3 – Inventories
Inventories of characters or storage containers are often represented by a list of names sometimes accompanied by images. The UI allows you to select and handle these items by selecting the item and applying the appropriate UI function for the task required.
Example 4 – Numeric representations of abundance
Abundance in games is sometimes represented by numbers next to the item. A character might have an apple in his inventory represented either by text or graphics – or both – and if the character has several of those apples this will often be displayed by a number in addition to the other symbols. Unit troop strength might as well be portrayed by a graphical representation of a unit with the addition of a number representing the number of individual troops in that unit.
Example 5 – Excessive information
Sometimes games offer excessive information about items, characters, skills or places which doesn’t have a direct equivalent in real world. This can include but is not limited to UI element with map information, skill points, attribute points, statistics, symbols showing active effects, etc.

The problems with the classical UI paradigm

I have shown you above in the examples how games often represent things symbolically. Depending on the nature of the game and the specific situation these UI metaphors can be useful and many of them are very easy and cheap to implement giving the developers the possibility to spend the time and money saved working on other game content.
However, selecting the classical UI paradigm for every use case can lead to excess gamification of things which could - in fact - have a direct visual equivalent in the game world. Unnecessary UI metaphors run the risk of alienating the players from an immersive gaming experience.
With careful case by case consideration it is possible to make the most use of the classical UI paradigm in situations where no other method is possible due to the limitations of the medium.
When an abstraction is not required to represent reality the classical UI paradigm stops making sense.

Audiovisual Feedback Based Simulation

AFBS stands for simplicity and immersion. Giving audiovisual feedback to the player to simulate things happening in the game as opposed to using excessive menu abstractions to achieve the same goal. AFBS design philosophy calls for:
Representing the reality as it is
One of the most important concepts of AFBS is representing the reality as it is - when ever possible. It’s all about game immersion and getting rid of the unnecessary UI metaphors. The game itself can be as unrealistic as it needs to be but when something can be represented without a metaphor it should be.
Example: If you can represent the act of carving a wooden spike with a knife as an animation – then don’t abstract it away as a menu and a button.
Avoiding unnecessary UI elements
If you don’t need an UI menu for something you should probably avoid having one and go for the more visually appealing immersive option.
For example: Context sensitive interactions can drastically reduce the need for graphical UI elements.
Avoiding the display of excess information
Excess displaying of numerical and other data easily distracts the players from the game immersion. Human beings are wired in such a way that we experience progress as rewarding. Unless your game is all about numbers and stats the rewards should be self evident in other more fulfilling ways. If you display numbers to the players the players will spend a considerable amount of time comparing the numbers to get the best possible advantage instead just enjoying the game.
Using the nearest possible UI metaphor
Things which don’t have a direct equivalent in audiovisuals should use the nearest possible UI metaphor which makes sense.
For example: We can’t sense when the player character is hungry so it needs to be represented somehow. The usual UI metaphor is to add a bar on the onscreen display which shows how far the character is from starvation. However the same goal can also be achieved by adding a simple audio cue of the character’s stomach growling plus some occasional monologue about being hungry and adding effects from the starvation - such as slowing down, etc.

4 Likes
66

This is interesting, do you think you’ll produce any demo that implements this feature?

2 Likes
67

It’s still very early at this stage but yes, we hope to. The work load is going to be huge but I think it would be worth it. If we take crafting as an example, my approach is that:

  1. Make generic animation as a place holder that can be used with everything.
  2. Make specific animations for each individual thing.
  3. Add in the crafting minigames one by one.

Example:

Pottery. Minigame where you take visually controlled amount clay and mix it with water amount that feels right. This defines the viscosity of the clay. You can then proceed to the pottery wheel (or hand techniques) to form the pot by controlling your arms with the mouse while using the keyboard to keep the pottery wheel spinning at a constant pace. Then when you feel you have your pots ready you can leave them to dry for ~one day before firing them up in a furnace (or open fire). The furnace needs to be kept at a constant and proper temperature for a proper length of time with only visual aids to help you.

And of course server owners will be able to disable the crafting minigames if they wish to run a server where crafting is speedier. It’s basically a no-brainer to add a lot of config options since it’s not going to require much extra code - we need the crafting animations for the observers anyway. It’s not a big step top skip the minigames and add in some more skill based randomization.

Aside from crafting I personally have never really cared for bloated UIs so it’s definitely something I hope to work on.

Menu based stuff can be a good place holder but it’s not very inspiring in a finished product.

4 Likes
68

You’re totally right, however there’s a reason behind “abstracting” actions into UI and that’s this is really easier than creating clear animations for every action in the game. What you’re looking for can be really good-looking in a final product but can also require an huge amount of work. However i hope you’ll succeed realizing what you’re projecting :slight_smile:

3 Likes
69

Yes, exactly. That’s why I was talking about using the place holders. Currently we have only one animator and the animation pace is approximately one animation per week - which is a pretty decent pace.

But depending on the final amount of animations (ie. how much we can generalize them over several tasks) … if we assume for instance, out of the blue, 100 animations and we would be able to keep the current pace it would take our single animator approximately 2 years to finish the animations.

So the initial goals are not that high because it’s just too much work and it would be unrealistic to assume we could do that - we have also a lot of other animations we need. Fortunately humanoid animations can be re-used across the NPC spectrum, which helps a bit.

But around 2020 if there are no unexpected delays and our crowd funding campaign succeeds and the game is a commercial success we should be able to hire more people.

2 Likes
70

You might do a google search for “diegetic user interface” if you haven’t already.

4 Likes
71

Thanks @pspeed I was not familiar with that term before.

I did some digging and read through an interesting Gamasutra article on the subject. Nothing really new there that I hadn’t thought of myself (it’s not exactly rocket science) - and it did fail to study the essentials of why a traditional, or “non-diegetic”, UI is needed. The article had the naive approach of focusing mostly on “what players like” which I don’t personally put above functionality and the goals of what the game wants to represent. Of course that is debatable it and might end up being essentially the same thing.

Overall it was a good fresh perspective to UI design and I’d like to see more games in the market that go for the immersive interfaces. Personally I prefer them over traditional ones.

2 Likes
72

https://pbs.twimg.com/media/DErzCIaXUAAkvdV.jpg

When working on Rituals of the old I sometimes forget what year it is. Yes. That is my bike.

10 Likes
73

So, have you guys got any gameplay done in the, uh, past year?

2 Likes
74

I know, right? No proper gameplay yet, just engine tests. It’s sometimes a bit frustrating, I know. Personally I would already like to get to the good stuff.

But we have only two coders and there’s a lot of behind the scenes stuff that needs to be done before we can get to gameplay. For the past 4 months we’ve been working on v2 of Terra, our mesher, and fixing bugs, working on models and animations, game design, particle effects, revamping the verification server for multiplayer, etc.

I mean, we could have thrown something together a long time ago but we’ve had huge problems with importing rigged and animated FBX to Jmonkey - and it still isn’t resolved. It’s unfortunately blocking everything visually interesting. I’m sometimes regretting the decision that we chose Jmonkey instead of Unity. I could not anticipate that an industry standard format (FBX) could have such a bad support. If we had used only Blender we would not have these problems, but most of the animators and a lot of the modelers out there use Maya or some other Autodesk product which, you guesses it, don’t play nice with Jmonkey.

But of course that is not the only reason why we don’t have gameplay yet. You have to keep in mind that we’re working on a multiplayer voxel game and we are building our own voxel game engine from ground up. It’s by no means a simple or a small task.

Using the standard scenegraph it would be trivial to put together some game mechanics but that doesn’t help to solve the actually hard problems. We prefer to work on those first and add the gameplay later.

5 months ago we were already at this stage:

What you’re looking at is fully working multiplayer happening on a game server + launcher, verification server for multiplayer accounts, etc.

But you know, it’s not a game.yet.

All things considered we’re still on schedule. Things are going well. First beta tests for the bare bones version of our game are scheduled somewhere around 2020. Before that there’s still a lot of work to do.

4 Likes
75

Decided to take a break from game design and work on some graphics instead.

1388×801

It’s a keyboard.

7 Likes
76

747×227

Hello people. We are currently looking for a couple of extra volunteers to speed things up:

  • 3D Animator/Modeler.
  • Java coder, familiarity with JME considered a plus (obviously).

Looking for something interesting to do? Do you enjoy multiplayer sandbox voxel games?

We currently have 7 active developers in the project. Two coders, two modelers, one animator, one game designer and one project leader, me. The project has been in constant and active development for ~14 months (424 days today).

Rituals of the old does not have any income at this point. We’re going forward on a hobby basis, for now, so we can’t pay you. Money is not the most important thing for us but we do aim for a commercial release eventually with the hopes to employ the dev team full/part time on success.

Feel free to ask me anything either here in this thread or send me a PM, visit our Discord chat or contact us through email (info at starandserpent dot com).

Our job post at Indiedb:

Project website:
https://www.ritualsoftheold.com/

Cheers!

3 Likes
77

A big thank you to everyone who applied! The animator and modeler positions are now filled and we have three new members.

We can still squeeze in one coder if any of you Jmonkey people are looking for a challenging multiplayer voxel sandbox RPG building survival (and so on) project to join in. Above average Java skills and intimate knowledge of JmonkeyEngine are required.

Send all applications by email to: info at starandserpent dot com

:+1:

https://www.ritualsoftheold.com/

3 Likes
78

He’s certainly having a bad day. Presenting - the modular character design.

5 Likes
79

Jack the village butcher (with a bad eye infection):
Hey, stand still! You have a big spider on your back.

Jill:
Eek! Get it off, get it off!

Playing around with the new models.

2 Likes
80

https://www.ritualsoftheold.com/images/sketches/renders/moose_walk.gif

Moose walk cycle wip

6 Likes
81

Nice. I want the hips and neck to wiggle a bit, too.

2 Likes
82

Man, it looks great and I would hate to criticize… but I think you need to swap the back leg animation maybe.

As it stands, this moose would fall over during large parts of his gate as both right legs are off the ground and then both left legs. It feels very unnatural.

1 Like
83

No, I love feedback. And that moose step sequence is a bit chaotic and tricky - it’s hard to capture just right. I’ll forward your feedback to our animator and we’ll put out another revision.

1 Like