Home
Artists
Search
Recent
Random
Posts
DMs
Tags
Random
Importer
Import
FAQ
Account
Register
Favorites
Login
A week with a Paralives dev (Patreon)
Content
Hello there!
As some of you may already know, our programmer Anna shared a glimpse of her day-to-day work on her Twitter account last week. In her thread called ✨A week with a Paralives dev!✨, she revealed some of the tasks and challenges she encounters on a daily basis implementing a solid animation system for Paralives.
Today, we are sharing with you the transcripts of her tweets. We recommend that you view this post on a computer in order to easily access the GIFs. Also, this post is public so feel free to share it with anyone that could be interested!
DISCLAIMERS:
Everything in this post is work-in-progress and tests, nothing is final yet!
Monday morning: planning 🗓️
Hello! ☕ Today is Monday, which means it's the beginning of your new favorite sitcom
✨ A week with a Paralives dev ✨
<insert upbeat soundtrack here>
After a week-end well spent in dreadly spirals of Youtube videos, naps, and the usual existential self-reassessment crisis of Sunday evenings, here we are! Like me, Unity, our game engine, takes some time to wake his wonderful self up, so I'll let him crash four or five times…
While Unity’s getting his... mess together, I like to spend my Monday morning planning the rest of my week. This morning, I’ll start by revising my current to-do list and add new tasks for the next two weeks.
Planning is essential in a big project like Paralives! We have team organization tools like Slack and Trello, but in my mind, nothing can beat a good ol’ whiteboard 🤓
Good morning from my lil’ work-from-home corner:
This week, while other devs are improving our character creator and build mode, I am part of the lucky ones who get to work on the roots of our simulation mode! 🤸 I mainly focus on implementing our animation system and starting to think about the interaction system so I'm not working on the "gameplay features" just yet (like personalities, skills, careers...). :sad PL fan noise:
However, even if it may not be related to the gameplay features you're (we're) all waiting for, these things are a biiig part in a lifesim game like Paralives. Right now, we’re in a preliminary test phase concerning the animation system. We can’t just make a whole lot of animations, implement every feature in the meantime, and plug the animations at the end.
We need to work in a cycle of designing, implementing, testing and improving, that’s called an iterative process 🔁 This is the reason why the animations I’m working with are mostly “drafts” for now. If they were too polished from the start, it would be longer to correct them or redo them if we realize it’s not working. I’m also working in a separate Unity project as a first step, so that I can focus on separate features of the animation system before putting everything together.
Let's be honest, there are many things that don't go as planned in game dev, as in life (yes, I’m looking at you, 2020). This afternoon, we'll dig more closely into animations and what I mean about the "animation system"! (there will be burgers too 🍔)
Monday afternoon: simple animations 🍔
I'm back from my lunch break! 🍝 Now we can start the fun things! As you may already know, I'm not doing the animations by myself, as we are blessed enough to have a dedicated animator : Alice! 🏇
She is the one who brings our base model to life, using Blender. What Alice integrates into our Unity project after the Blender shenanigans are keyframed animation. These files are used to describe the movement for every part of the character’s body. There are usually more files than there are actions to do in the game! The reason for that is that we have to play the animations in an interactive way, instead of a fixed way like in movies. Here is today's example: eating animations.
(⚠️These GIFs are low FPS which gives a laggy feeling, it will be better in game!)
As a player, when you click on a burger and choose the "Eat" action, your character finds his way to the burger, takes the delicious food and processes it until there's no bite left. In the background, here's what the code has to do:
This diagram could have been different: we could have a dedicated animation for the pivoting action instead of pivoting the character only by script, or maybe we could get rid of the “pull chair” animation if we don’t have enough time to make it (the chair would move on its own). Hence the first very important step in our thinking process, even before animating or adding fancy effects: choosing what "chunks" of actions are going to be played in what order.
Animating for game dev requires to think about modularity 🧩 as it has to be interactive! If Alice had to do a 5min long eating scene in a movie, she would spend days on making a 5min long realistic eating animation that is very smooth and feels very natural, plug it into the whole movie at the desired spot and time, call it a day, and move on to the next scene. (I'm not saying here that working in movies is a simpler job!!)
It just doesn't work like that in game dev: the same animation has to be adapted to the position your character is in, the character itself, its state, the props that it’s interacting with… It also can be interrupted or restarted at any moment if the player chooses so. All of that, with the most seamless transitions possible so the player doesn’t notice the cut between clips 🎮
For this reason (+optimization), we want the least amount of lengthy animations for each action, but instead, a lot of small chunks to use, reuse and adapt when needed. In the end, a big amount of time has to be dedicated to the design process and the logic of the whole system.
It's especially important in a sandbox lifesim game, where you can do plenty of different actions in different combinations: you can eat while standing, sitting at a table, sitting on a couch, laying in bed, in a bath (don’t judge me) and we don’t want to do a different animation for every case!
Instead, we combine simple animations chunks to create the different complex situations 🧪 Here is the test scene I made for today:
There’s a total of 5 animations in this video: eat (2.3s), sit (2.2s), get up (2.2s), sitting (2.5s) and standing (2s). The eating animation is played as a layer on top of the base character states, so it affects only some parts of the body. It’s a very simple case, as there’s no table in between, and I’m not working much on the “action” part of the system today.
There’s already room for improvement that I take from this little test: transitions between starting and stopping eating could be better, for example. I’ll be working on that for the rest of the day, along with adding some yummy props to the animation.
With this concludes the explanation for what I’m doing today: test the combination of our existing states (standing and sitting) with these newly added animations. Hope you liked the first log! See you tomorrow for day 2! 👋
Tuesday: meeting day & non-programming tasks 🎙
Hello world! 🌞
Tuesday is meeting day for the Paralives team!
What’s sad is that some of us never actually met in real life, due to the Current World Events. We all hope that the situation will eventually allow us to see each other’s faces in 3D, but in the meantime, we meet up on Discord!
Even if they last less than two hours, these Tuesday meetings are really important. Every other week, we’re dedicating it to sprint planning, while the other Tuesday is Brainstorm time!
🗓️ Sprint planning:
These are meetings where we talk about all the tasks that we’ll do for the next two weeks (sprint). That way, everyone knows what the state of the game is in even if we’re not working on the same parts. We’ll also review together the priority of each task and potential other meetings that we’ll need. We need to make sure we’re all on the same page and nobody is blocked!
🧠 Brainstorming meetings:
this is where we discuss about game design. As there’s no full-time game designer on the team, we all do our part to add something to the table. My specialty is to read some psychology or other research papers, while some prefer to take game features from other genres as an inspiration, or provide more theoretical game design insights. As you may already know, Christine’s specialty is to read and present the ideas and suggestions from the community, especially since our latest community brainstorming sessions, which led to deep and insightful discussions on our Discord and social media! We also document and train ourselves on general aspects of game dev on a regular basis, with GDC (Game Developer Conference) talks! This channel is full of useful advice on various subjects from other talented devs in the industry.
💡So, brainstorming is a first rough step where we talk about the vision we want for the different parts of gameplay, however no final decision is made yet. Gameplay features for the simulation mode will have to be implemented and thoroughly tested to make sure that the whole thing is actually fun to play. This is why there’s plenty of features that we cannot fully confirm yet, even if we know what we want to do or not. Some things are cool in theory but have to be proved in practice.
In both meetings, there are some special subjects that we sometimes bring to the table: new potential candidates to hire, a special event (like the making of a video!) or some more businessy top secret decisions. We also talk about Patreon post ideas! As Patreon is our one and only funding source, it’s important that we update our wonderful patrons regularly on what we’ve been up to, or ask them for their opinion in patrons-exclusive polls. Honestly, it can be hard to think about something new & exciting to say every week, as the days fly by so quickly! However, the discussions in the comments are always really interesting and supporting. It’s also super helpful for us to have a first feedback before official releases or updates!
Thank you patrons and supporters for being so patient and lovely ❤️
Gonna go ahead with my plan and do all my non-programming tasks today. I’ll be on a second meeting this afternoon + working on some secret things 🕵️🎹 so there won’t be anymore tweets today. I’ll see you tomorrow for more animation tweets! 👋
Wednesday morning: procedural animations I 🪑
Hi! I’m back today for serious animation talk 💪
Remember on monday, we talked a bit about how crucial the logic is in our animation system, and how trivial actions need plenty of thinking. Well, it was only the start... Today I’m talking a bit about procedural animations ✨ Beware: “procedural animations” is a very generic term to describe an animation that is generated in real-time instead of being pre-recorded. It can encompass a lot of things, like ragdoll physics, fluid or hair simulation… But we’re not talking about that today. In our case, we use procedural animations not to replace a whole technique, but as a complementary method: we still start from the standard keyframed animations I showed you on Monday. Alice’s animations can be attached to a character and be played as it is thanks to a simple script, however it cannot adapt to different surroundings by itself. You may start to see where I’m going with this…
In Paralives, we want both characters and environments to be as customizable as possible, which brings us to a whole new level of adaptation of the animations. Let’s take my current struggle as an example: sitting! A simple, non-procedural way of looking at this would be to always constraint the furniture to be the same height so that the same animation can be reused as it is:
However, our goal is to allow for a lot of customization options without removing any gameplay possibilities. We want furniture of various heights and widths! We want an extended mod support! We want to sit everywhere! We want a height slider! (cries in programmer)
A first “secure” step for all of this is for Alice to create a minimal amount of different animations: one for sitting on the floor, one on a medium high chair or platform, and one on a higher platform. It doesn’t have anything to do with procedural animations, but it’s a necessary base to which we’ll add the fancy adaption. The animations are attached to our base 3D model and with standard sized props. Here are they:
We still use different base animations because there are limits to what we can do with procedural animations. As Alice is here, it’s better if she can do most of the movement herself, so that it’s the smoothest possible! That doesn’t solve our main problem yet: it can adapt to three different heights, but what about everything in between? To have a more visual understanding of what the problems are, let’s import these animations into Unity and check what it looks like on different chairs:
Did you spot the problems?
Our character is clipping through the red chair (a little bit higher than the reference), while the green and blue ones (lower) makes it looks like they're sitting in the air. After this very quick test, I typically document it and sketch out some ideas to solve it. Here, I’m thinking about keeping the same animations (SitOnChair and SittingOnChair), but adapting the hips positions, like this:
I'll show you if it worked this afternoon, see you there!
Wednesday afternoon: procedural animations II 🪑🪑🪑
Hello again, let's put our hands into procedural animations for real!!
One of my first tests to solve the sitting problem, was to take procedural control over the hips of the character. Here is a first draft at a procedural target (the little red box), that the hips will eventually be able to reach:
Welp, it surely proves that hips can be adapted to different chairs, but the feets now clip through the floor! The reason for this is that body parts in a character are described as a hierarchy, which is called a skeleton (in blue). The hips are the very top part of this hierarchy, meaning that everything else is moved along with it, including the feet. As I’d like my feet to stay planted into the floor, I’m adding two other procedural targets on the feet to make them stay still:
(In the GIFs above, you can see me moving around targets on my Unity test scene, but ultimately a script will do it while the sit animation is playing.)
You can see that another problem remains, which I didn’t anticipate: the arms. Poor characters see their arms clip into their own thighs (...that must hurt) or just stay in the air. I’m not against a good arm workout, but it doesn’t feel really natural. One solution could be to also adapt the arms and make them always join their thighs through a body target... However, that only solves the main idle sitting position. What will happen if the character is sitting with their knees very close and try to read, eat, or whatever animation that could be played while sitting? It would probably require other adaptations that are specific to each animation.
We have to think about a generic solution that can adapt to more cases. It’s better if we have less things to adapt; it saves time and resources but it also prevents us from forgetting about a specific case that could break the system and that we haven’t anticipated. As procedural animation is used to complement a real "hand-made" animation, it’s also better if we’re not trying to work too much "against" it. That’s the main challenge with this process: how to balance the smoothness of Alice’s animations and the robotic procedural adaptation?
Back to our problem: the main issue is clearly the angle of the legs with the rest of the body when the chair is lower than standard. If we keep it at 90°, we wouldn’t have to think about adapting the upper animations..
As I don’t feel like putting the feet in front of the chairs are a really good solution, I asked Alice if she could come up with an alternative sitting pose that follow this constraint so that it looks more natural and takes less space. Let’s see if my idea is possible:
This alternative looks way more practical than the other, as the hands don’t look like they need a lot of adaptation. It still needs lots of polishing though! My next step this afternoon will be to test these adaptations during the “Sit” animation, instead of tweaking the “Sitting” idle pose only.
So that's all for today!
With today's threads, I hope that you got a first glimpse at what cases of procedural animations we’re dealing with. It’s a wonderful tool to use but it still needs some thinking!
See you tomorrow for new procedural shenanigans ✨
Thursday morning: procedural animations III 🤝
Hi geeks! Today I’m going to show you another (simpler) case of procedural animation that doesn’t depend on the environment this time, but more of the height of the characters.
⚠️Warning: the gifs you’re about to see in this thread are recorded in a covid-free virtual environment, please don’t high five someone without washing your hands and follow the public health guidance for social distancing! 😷
With that said, let me show you the very first instance of a social interaction in Paralives:
… Well, you know, they tried. That doesn’t mean they aren’t friends.
Our problem is quite straightforward this time, hands have to meet somewhere between the two characters! To solve this, we need to take a bit of control over the hand, just like we did yesterday with the feet and the hips. By the way, the specific technique that we use for arms and legs targets is called “inverse kinematics”. It allows a hand to reach a target procedurally, while the rest of the arm has somewhat of a credible movement. I’m not gonna annoy you with the details here, but I figured it was a widely used term so maybe you’ll be interested in seeing what it is:
Procedural thingies are added on top of the existing animation, so you should see the idle animation playing here. Only the arm is being taken over. Alright, let’s high five procedurally now!
As I said previously, the main problem is making hands meet in the middle. We could also think about adapting the head and the eyes so that both characters face each other, but it’s not my priority right now.
Today, I’ll try to include these procedural targets to the animation in itself, rather than test it with a single pose. I want the target to have an incremental effect during the animation and to be reached completely when both hands should meet. The meeting target will be computed only once, before the animation. Its position won’t change during the animation, I’ll only change its "weight", which is like a "percentage" of reaching the target (0% = no adaptation, 100% = exact target met). Here is what it looks like when I’m trying to play with this weight:
We don’t want the target to be met during the whole movement, as characters have to start with both arms along their bodies. This is why I’ll only change the weight of this target during the animation and I want them to reach a perfect match when the hands clap. After I added a bit of code to change the weight automatically during the animation, here is what it looks like:
This test animation was a quick draft, it’s definitely not finished yet and far from perfect, but the procedural part is encouraging! As I said previously, it’s better to work with a draft animation or poses at first, so we can think about what to do procedurally without being lost in a complex movement. There are also still plenty of things for us to think about, like: if a very small kid tries to high five a very tall adult, what should happen? Should there be a jumping and high five animation on the kid’s side, or would the adult crouch to adapt? These last examples would require new base animations and states, like crouching or jumping, that could be reused for plenty of other kids to adults interactions.
I'm going to document these thoughts this morning to keep track of our tests. That will be all for this morning! After lunch, I’ll talk a bit about modding!
Thursday afternoon: modding tools ⚙️
Now that I showed a big part of my current tests and work for the animation system, let me tell you about another level of complexity that Paralives demands: the modding tools ✨ (sorry no wip gifs this time as the modding UI isn’t showable yet)
As Paralives is a community-centered game, we want it to be easily moddable. To do so, we’re implementing the mod tools at the same time as the gameplay features themselves. Our game is actually a mod itself! This allows our own artists to integrate their assets into the game using the in-game modding interface (that should ultimately be available to players!) instead of going through Unity. Animations are no exceptions to this process!
A mod tool that I’m in the process of making these days is about linking new animations to actions or chunks of actions in the game. That’s not as not as simple as it looks like, as it has to do with a whole other system that I haven’t talked about: the action system! What I mean by that in a few words: add interactions to objects or characters, link them each to a list of animations, tell which actions can be combined (eating + sitting = yes, swimming + eating = no), tell the order in which they should be played and the props they’re using…
For now we have a very dumb pathfinding and action system, but as it’s very closely linked to the animation, I’m slowly improving that too 💪
Another thing I have to think about integrating to the mod tools is the whole procedural animation magic. Every red box that you saw on my previous tweets will be controlled by the code in real time, rather than the animator (Alice, or maybe future you as a modder???). It means that it’s not enough to just plug your custom animation clip in, you’ll probably have to deal with some procedural shenanigans yourself 🔮
Don’t worry, animators who want to integrate their custom clips aren’t required to know how to code to deal with that!! We’re aiming for a very user-friendly interface allowing you to integrate and test the animations that you made in your favorite software (Maya, Blender, etc). I’m always keeping the mod tools in mind when I’m testing (procedural) animations and actions. We have to think in the most generic way so that every case can be covered, and that (hopefully) no script is needed to mod a new animation in. Because of that, mod tools are definitely not easy to implement, but it will ultimately save us (devs) a lot of time in the future as everyone in the team will be able to do asset integration on their own. We’ll also be able to add, remove or modify gameplay features and settings in a quicker way during playtests!
That ends my technical threads of the week. I hope this week of day-to-day tasks brought to light why something can stay in the background for a loooong time before being revealed in a public video. Our videos are really just the tip of the development iceberg! On the contrary to the latter production phases, when we’ll know better how many assets we need to make or how many bugs we’ll need to fix before release, this background research and design phase is not easy to predict. A lot of things could go wrong, needing us to rethink the system; it’s why we have an iterative process, making draft poses and testing the hell out of them before polishing and showing anything. A lot of things could go well too, but we can’t know before testing! 👩🔧
Friday: community day and Q&A 💕
Hello hello! Today, it’s community day! We’re having a one hour chat every Friday over Discord, for some of our high tier Patrons. Christine always releases a part of our chat in our Reddit and Discord a bit after they were held, so you can take a look!
Thank you so much for bearing with me during these long threads!! 💕
I’m glad so many of you liked it, I’d personally love to do that again sometime! Here comes this week's FAQ:
Q: Will there be different ways of sitting or eating depending on traits, mood, age or furniture types?
A: It should be, yes! It’s definitely planned for the future, but we don’t know the details yet, as it has to do with gameplay. Right now, we're focusing on a first simulation "prototype" in which all of our generic animations and actions are working. When we’ll reach this (big) milestone and when the simulation design will be more fleshed out, we'll be able to add some gameplay into it and know a little more about what specific variations are going to be needed. We can't make different animation variations right now if we end up not using them in the final game! There's also a lot of generic animations to do and polish already. (That's the iterative process again!)
Q: If procedural animation works in the game, would that mean that the para's feet wont clip on sloped terrains?
A: Not necessarily! If we make procedural animations work, it doesn't mean that we're going to use it for everything. As an indie team, we have limited resources to work with (devs, but also time) and everything we add to the game has to be thought carefully: we could spend days to find solutions to avoid any clipping, but is it really worth it? Our game could already be cool and ship without correcting the feet orientation on slopes, whereas it would feel really weird to have major issues like what I showed you this week (character sitting or high fiving in the air). I'm not saying here that we won't use it to correct feet orientation for sure, but it's not on our priority list right now. We also have to make sure there aren’t too many computations at once for optimization reasons!
Q: I'd love to make animations but I don't know where to start?
A: That's cool! I don't know anything about it so I asked Alice to answer for me:
"If you plan to actually study animation, there is a lot of great web schools for that: Animschool, Animation Mentor, AnimSquad… You can follow their YouTube pages, they often share some cool tips on animation but also review other animators' work which is super helpful. If you don't have any 3D modeling knowledge, I would advise to start getting familiar with that first! There's plenty of good content out there to learn all of that. Maya is a really good software, but it's not free, even for students. Blender is free and it's getting better and better. There are also a lot of tutorials and videos about it! It's definitely possible to learn by yourself, but you should consider following a course if that's what you're passionate about, as it can get quite technical… Here is also a well-known book that covers the most important things: The Animator's Survival Kit, by Richard Williams"
Alice doesn't have a public Twitter account, but you can reach out to her by e-mail if you want more references or if you have specific questions about going into animation: aliceparalives@gmail.com
Q: What it's like to be a game dev working in a team and how do you synchronize your work together with others?
A: As we're a small team, it depends a lot of what the current tasks are! For example, right now I'm the only programmer working on animations together with Alice. We have to synchronize ourselves so she can produce animations that I will be able to test out soon, and I can provide feedback to her when her animations are imported into the game. We also think about the animation system together before adding anything, so there's a lot of communication going on on this side. On the programming side, every programmer has to do frequent code reviews, when another programmer... reviews their code and features 🤓 So I'm not alone either on that side!
See you soon! 👋