Ahoy!

So yeah, last week was pretty morose. As you might have read in the blog, we suffered a few setbacks that prevented us from running the Kickstarter as soon as we wanted.

Well, good news! This week, we either fixed some of those problems, or are making excellent progress in fixing them. Here’s a few examples:

Sauropod has made a video!

We never thought making a video of ourselves would be so hard!

We decided to go for an “interview” format where some of our friends would as some unscripted questions and we would try to answer as well as we could. They would keep track of those answers so that once filming was done we would have footage of us explaining our concept, and why we needed a Kickstarter.

We also listened to your suggestions and made part of the interview in French, with subtitles. Some of those answers were not only better, they seemed more spontaneous and honest, which goes in the direction of what we want.

A friend of ours also took footage of us working so that we can scatter some authentic “Sauropod-at-work” footage. We have a few screenshots for you if you’re interested:

All of these pictures have been taken unaltered from our video footage so the quality is really good. This really is all thanks to our friend Mathieu Sauvé who is a professional photographer and agreed to help us out with the shoot.

Hurray!

Short and sweet again this week. See you next time!

Team Sauropod

This week’s blog will be shorter than usual. The current situation here at Sauropod is in a state that makes writing blogs a bit harder than wer’re used to. We have lots of tasks that are unrelated to the actual game development that occupy a good part of our time. Tasks such as incorporating (It’s done actually!), talking to accountants about legal matters, opening bank accounts, filming videos of ourselves, etc.

And other tasks that are directly related, but are either uninteresting or should remain secret. Tasks such as fixing bugs and tweaking gameplay mechanics, but also implementing really sensitive gameplay features that we want to keep as a surprise.

It’s true that there have been some unforeseen delays here and there. For example, we never expected that registering for an amazon payment account (required to host a Kickstarter) would be so long. These kinds of things are out of our control, but in the meantime, the game is getting prettier each day. I think everyone will benefit from this by the end.

Progress report

This week was pretty painful. It was time to test our game in a situation that would be considered as extreme: A really big world with pretty much every game mechanic present. Guess what… we broke it.

We pushed the game so far that it crashed. Repeatedly.

Thing is, we need to do this because we are already using those settings in the trailer. We’ve been trying to record some gameplay, and every attempt so far has revealed another game-breaking bug that ruined the shot. It’s coming along, no worries, but it’s certainly frustrating.

Here’s our milestone document. It has become so large that it’ll probably become sentient any time now. I’m watching it closely.

Sauropod is making a video ( again )

Yeah, so we filmed our video last weekend. And everything went well.

Except when we came back home and watched it, it was terrible…

It was so bad in fact that we just threw the footage in the recycling bin and called our friend to ask him if we could film again this weekend.

See, we’re not good at speaking in English. Writing is fine, but speaking… Uuugh.

Anyway. We’ll see what happens this time, but it simply can’t be as bad as what we filmed last weekend.

Anyway, that’s all we have for this week. See you next time!

Team Sauropod

So yesterday was François’s birthday. There was much rejoicing, and some incredibly talented friends of ours created one of the most awesome cake I’ve ever seen in person. Combine that with the birthday of François’ wife, Julie-Édith which was earlier this week, our workspace was filled with so many people that writing a simple blog post became pretty much impossible.

Progress report

This week was spent squashing dozens of bugs, and implementing a cinematic & event-driven engine. The goal here is to facilitate gameplay capture for an upcoming gameplay trailer. Basically, we build a simple scripting language that allows us to generate short scenarios by spawning characters in specific locations and giving them orders at precise times. The idea is to create an engine that can repeat hand built scenarios over and over again and allowing real-time modification of those scenarios. With this we can capture video of complex scenes that would be impossible to film if the player has to command the characters manually. The engine includes a camera animation import system that lets us create complex camera movements in 3d Studio Max, and importing them in the game engine.

In short, at a simple click of a button, groups of characters appear and act out precise actions. During that time, a hand-animated camera films the whole scene. With this we can create live cutscenes, which will help us creating a really nice looking gameplay trailer.

On the bug-fixing front, we stumbled upon a whole lot of them, and thankfully managed to fix most of them. We are still crippled with a few memory leaks, but hopefully we’ll fix them in the coming week.

Here’s a comparison of this week’s milestones document versus last week’s:

Sauropod is making a video

On the Kickstarter front, we’ve been working on two things:

This weekend, we are filming our frontpage video, in which for the first time, you’ll see us talking in front of a camera. Let’s say we’re not entirely comfortable doing this but we think that it will be a important part in convincing people to help us with the Kickstarter. Needless to say we are putting “Les bouchées double” (redoubling our efforts) in creating the best video possible.

Secondly, in order to host a Kickstarter, we’ve had to spend the week on the phone, talking to a wide array of people. We needed to open bank accounts, incorporate Sauropod studio, talk to lawyers and accountants, and basically ensure that IF any money ever comes our way, we wouldn’t get double-taxed or go to jail.

Anyway, we have to cut this week’s blog a bit short. We are incredibly busy with everything we’ve talked about above, 7 days per week simply isn’t enough sometimes.

Let’s just say that things are going incredibly well, and that I can already see the end of the tunnel. I can’t wait to show you what we’ve got!

See you next week!

Team Sauropod

So yeah, we we’re so busy working on the game this week that we did not realize it was friday and totally forgot to make the blog. You see, the Kickstarter is so close we can smell it. This means that we have to work really really hard to make things as good looking as possible.

There are too much things to list this week, so instead, we took a screenshot of our milestone document. Sorry we had to blur out the details so we don’t spoil some of the surprises we have for you in the Kickstarter video.

Some of those blurred tasks include bad guys, catapults, saving the levels with dynamic objects and the character ragdolls. Speaking of which, ragdolls are the subject of our blog this week!

But before this, we have a rather important event we want to celebrate:

Team Sauropod has 10,000 fans!

Tuesday, we had the joy of witnessing a rather important event. We were there, on facebook, refreshing every five minutes or so waiting for the number to go from 9999 to 10000. We had the opportunity to take a screenshot the minute we passed the five figure mark.

We’re still deciding what we will do about this, we’ll announce it shortly. Anyway, without further ado, here’s this week’s blog subject:

Ragdolls!

So, what the hell is a ragdoll, you ask?

Ragdolls are a way of simulating character joint physics in a game. Wikipedia has this to say about ragdoll physics:

In computer physics engines, ragdoll physics is a type of procedural animation that is often used as a replacement for traditional static death animations in video games and animated films.

So basically, we apply the same physics that we use on the castle bricks when they fall apart, on our game characters, often with hilarious results.

The main reason why we would implement ragdoll physics has to do with randomness. In a regular game using pre-animated (deterministic) death animation, once the player has seen an animation, he has seen it and can never un-see it. This creates a game environment in which player who has played for a while can hardly ever be surprised by the game anymore, because he has seen literally everything. Usually, the game developers can counter this effect by creating dozens if not hundreds of unique context specific hand-crafted animation, but in our case, with only one animator, we do not have that luxury. Ragdoll physics give us an unlimited amount of death animations for a very low cost in terms of work. Creating the character rig took me about the same time as creating a single keyframed animation.

The second reason has to do with emergent gameplay. In a game where creativity is one of the most important feature, it is important to create a sandbox where players can experiment in directions that the game designer has never thought about. Ragdoll are usefull in this case because of the ability to react to any other object that exists in the physics engine. For example, in older games, dead enemies would not react to other dead bodies laying in the same space. They would often phase through each other or even lay flat even though they’re resting on sloped ground. This breaks immersion, and gives away the fact that those bodies are no longer interactive entities. Programming behaviors that take these things into account, and reacting to large amounts of stimuli is incredibly complicated, so ragdoll physics is very profitable.

Finally ragdoll physics are just awesome. I can spend hours trying out every possible way I can cause a Bricktron to fall to his death. Here’s one example:

Unity3d makes it really easy to set up a joint rig with their ragdoll wizard. I’m not going to get into the details of how to set up joint limits and rigid body constraints, but try it out yourself, it’s really easy and pretty entertaining!

Cheers!

The Sauropod team

Our imaginary Kickstarter deadline is coming up inexorably, as we scramble to get everything done (we will announce it very soon). OMG sooo much things to do and not enough time! As for the game, we got lots of little things done this week. Nothing huge, but together they amount to large changes. Here’s a list:

Skyboxes, or how to fake big things with tiny ones

So, what is a skybox?

A skybox is something that we use to fill the background of our game. It is usually static and non-interactive. In other words, a skybox is where the player should never get to go, generally because it is too far. Since game developers have limited time and abilities (yes, we are not gods, we have to sleep like everyone else) we have to cut corners and put limits to the size of our world to prevent having to create infinitely large and detailed worlds.

Fortunately, we took the decision a long time ago to make our game happen on flying islands. This means that players will never be able to walk in one direction indefinitely. This is usually the bane of every first-person shooter since they have to create arbitrary kill-zones to prevent the players from wandering too far away from the combat zone. So in the case of Castle Story, what constitutes the skybox is pretty clear: The sky, the sun, the ocean and the clouds.

Thing is, those elements all have one thing in common. They are BIG. Like, really really big. It would be really inconvenient to create objects that big in the game universe (the aforementioned far-clip is one of the reasons). Normally, the game engine would have no problem rendering a static image in the background, but in our case, the skybox is dynamic, with day-night cycles, and 3-D clouds moving around. So our solution was to create a tiny skybox somewhere and render that in the background.

Now since the 3d skybox has a limited size, this means that unless the clouds are significantly smaller than the skybox, they will tend to clip through the edges. It’s hard to explain so I made a graph:

Anyway, that’s how we do it for the skybox. The sky color is pretty simple, a gradient shader applied to a sphere. We can change the colors of the gradient to simulate a blue daytime sky, or a darker grey for night sky.

And that’s about it.

Thanks for reading!

The Sauropod team

Another week has passed, and brings us ever closer to the Kickstarter. We can’t reveal the exact date, but rest assured that it will be soon, and that if you read this blog, you will know a week in advance. This said, this week has been very productive. Many important features and assets have been started and/or finished. Here’s a list:

Speaking of which, ballistics are the subject of our blog this week. To do this I will now give my keyboard to Benoît, the newest member of our team.

Ballistics, or how to hit things by throwing stuff.

Hi everybody,

Today’s lesson is about projectile ballistics. That’s right, we’re going to talk about archers and catapults!

For those of you who haven’t done their high school physics classes, I’ll try to be as simple as possible in my explanations and to assume very little background knowledge. However, the goal of this blog is also to give guidelines to other casual game programmers (or professional I suppose), so in that respect, I’ll be as thorough as possible with the underlying math.

You’ve been warned.

Basic, basic physics

I’m sure all of you are familiar with this formula:

Suppose you want to travel from city A to city B which are 320 km (200 miles) away from one another. Suppose you’re going at an average speed of 80 km per hour (50 mph). Then your trip will have lasted 4 hours. So, that’s pretty simple, right?

Well, believe it or not, this simple formula accounts for the whole package of projectile ballistics (ignoring air resistance).

Here we’re using x and y as the horizontal and vertical components of the projectile travelling through the 3-D world. We can treat the world as being 2-D once the target and the projectile are aligned together.

I have to say that I’ve played a little trick on you, though. My little formula uses v̅ ( read: v-bar ), which is the average speed. That means if you’ve stopped for some gas or for a meal on your way, your average speed decreases accordingly, so really, v̅ contains an awful lot of information.

Fortunately, in the world of projectiles, v̅ is pretty simple to predict. Your final speed is your initial speed plus all the downwards acceleration that you’ve accumulated through gravity (denoted by the symbol g). Now your average speed is your initial speed plus half that same downwards acceleration.

Now that we have v̅ in terms that are easy to measure, we can replace it in the original formulas for x and y, giving :

Arrows

In Castle Story, archers can fire arrows at various targets to inflict them damage or neutralize them. They can shoot at any angle they desire that would improve their chance of hitting their target. However, they’re limited by the robustness of their bows and by their own physical strength. We decided that the main mechanism behind bows and arrows would mainly have to do with choosing an appropriate angle for shooting rather than varying the tension in the string. That also allows us to make a simpler animation for said string if we know in advance how pulled it will be.

OK, back to formulas.

Suppose you’ve just fired an arrow and you’re looking at it flying. You can look at the x and y components of its velocity and describe its “orientation”. At the beginning, the arrow is pointing generally upwards, but as the gravity pulls its y speed down, the arrows starts pointing more and more towards the ground, all the while keeping its original x speed (read: horizontal speed).

The elevation angle at which an arrow is fired have a huge impact on the range it covers. Here are a few trajectories that an arrow could have:

Imagine you’re firing an arrow at an elevation angle of 30°. Let’s call that angle θ (read: theta). What does that mean in terms of x and y arrow velocity? Well, your arrow will have the same total speed regardless of where you fire it, so let’s say it has a starting speed of v. However, if you fire it at 30°, it will have the better part of its speed invested in its horizontal velocity and it will take very little time before the arrow starts pointing downwards. On the other hand, if you fire it at, say, 60°, the opposite will happen: the arrow will still start with speed v, but it fly for a longer time before hitting the ground, yet it will also have travelled at a much lower horizontal velocity. Now that sounds very vague and general. Using trigonometric formulas, our original equations become the following:

So, what is the best angle to hit a given target? As a general rule, 45° is the angle that reaches the farthest, although that’s not exactly true for terrain that’s not entirely flat. But how can we hit a precise target if it’s closer to us than that farthest point? Is there a way to predict where to aim specifically?

By looking at the last two formulas, we see that we have only two unknowns remaining, namely θ and t. Since we also have two independent equations, algebra allows us to isolate t in both equations and, with appropriate manipulations and some sweating, obtain θ. The resulting formula is big and ugly, but don’t panic, it can just be used in a plug-and-play manner in any little physics engine with amazing results (see applet below). Without further ado:

If any of you should be interested in the algebra needed to derive the formula, Wikipedia has a page dedicated to projectile trajectories that explains it in a detailed fashion here.

Let’s go back to the big formula one last time very quickly and break it apart for those programmers among you who’d like to use it. θ is the elevation angle that we’re trying to calculate. arctan is the inverse of the tangent trigonometric function, which in turn is the ratio of the sine and cosine functions applied to a given angle. Generally, all math programming libraries have an arctan or atan function ready for use. Then we have our good old v (read: velocity), which stands for the initial speed of the arrow. In our case, that would depend on the strength of the Bricktron firing the arrow, or the tension in the catapult at the moment of releasing a projectile. Finally, we have x and y, which in this case mean the horizontal range at which the target stands, and the altitude of the target relative to the shooter, respectively.

So, that’s what’s happening in the Bricktron archer’s head. Looking at the target. Estimating its range and altitude. Plugging his firing power in the equation, and computing the right firing angle. Since the arrow travels reasonably rapidly, the target will not generally have the time to move too far away from the aimed spot, but we’ve also included a small estimation of the target’s future position according to its speed at the moment of aiming. We won’t cover that last detail in today’s blog, though.

Catapults

While archers can change their firing angle very quickly and easily, catapults can’t. Their mechanism is designed to brake at a very specific angle, something like 45°, and to throw any given projectile along a relatively similar trajectory. Where the catapult changes is in regards to it’s firing power. Not only can it project objects of different masses at different speeds, in can also be handled by a Bricktron to release more or less firing power at a time. Increasing the fire power makes the projectile go farther, and decreasing it makes it go closer, which makes it relatively easy to gauge where the catapult is shooting.

The following not-so-simple formula computes the initial speed that a projectile needs to have in order to reach a particular point in space (at horizontal reach x and altitude y, aiming at angle θ).

Try it yourself!

We’ve made a small applet that allows you to play a little bit with angle and firing power if you want to. Click inside the rectangle to change the target’s position. Knock yourself out!

Anyway, that’s it for this week’s blog, now to the soundtrack of the week!

See you next week everybody!
Peace.

The Sauropod team

Phew, that was a tough week! I’m glad it’s over so we can take a break.

François, Benoit and I all hit tough task requiring deep debugging, long testing sessions and leaving our comfort zones. Here’s what we worked on:

*** WARNING: THESE PICTURES ARE NOT IN-GAME GRAPHICS ***

New weapons and new tools. Bricktrons will no longer have to cut trees with hammers.
Includes: Arrows, shields, bows (string missing), swords, hammer, axe and pick.

New character model with new combat ready pose. The character hasn’t been imported in Unity3d yet, so we have to make renders using our modeling software.

Part of the “shoot arrow” animation. The bow will be a bit complicated to do if we want the string and arrow to animate with the character.

A Bricktron climbing a ladder. Damn that animation was hard to pull off. I’m not very good animating and this one was a bitch. I also just realised that I’ll have to make one for going DOWN the ladder. AAArg!

So anyway, that’s all we can show this week. The rest is just walls of code and lots of frustration. Too bad, I hope it pays off next week!

We’ve received a first draft of music for our game. Courtesy of Mattias Häggström Gerdt and Josh Welchel. It’s really great and we can’t wait to show it to you guys.



Speaking of music, here’s our

That’s it!
Thanks for reading.

The Sauropod team

How was your week? Ours was pretty ordinary. As ordinary as a week can be if you take into account the fact that we’re living our dream making games for a living. We’re not complaining.

Aside from working really hard, we took part in an epic 200,000 people manifestation right here in Montréal yesterday. That was pretty awesome.

Anyway, here’s a list of what we accomplished:

The wooden blocks

The wooden block will be the scaffolding of your castle. Wooden blocks are fragile and a ressource that is harvested instead of mined. However, wood is a much more flexible building material. It is lighter, so bricktrons can lift the wooden block and place it at a height of 3 instead of 2. The wood blocks can merge with each other to form wooden beams able to support weight. You can also make columns with wood. This allows you to use wood specifically like scaffolding.

Wood can be transformed into planks that can cover a large floor area. Those planks can be used to fashion any number of useful items like barrels, doors, chests and crates. Here is a demonstration of using wood to build a structure inside a brick wall.

Logs can be used as colums by simply placing them on level ground.

That’s about all of it for the wooden blocks! More about that next week.

Come back next week!
Cheers.

The Sauropod team

Here is the list of questions that was answered and thx to the people who logged it :P. (log from user Gijs)

________

First question round.

________
Q: Why choose unity 3d?
A: (Germain) Before we used Unity we had a software called Virtools. It was pretty old and ugly, so we decided to move to unity because it’s much more user friendly. You can start making a game for free in like half an hour. It’s also more modern, and updated more frequently. We tried UDK (unreal dev kit) and it’s also free but much harder to use. (Francois) So basically we chose it because it was simple and flexible.
________
Q: Will there be more blocks like steel?
A: (Germain) We are definitly designing more blocks. The first one is the wooden block, we’ve been working on the wooden block this week actually. But yeah since we’d like you to build castles with a lot of different resources, we’re going to implent blocks that do better stuff. Steel blocks are a good example, stronger, but much more expensive.
________
Q: Will there be RTS elements like food or water?
A: (Francois) There will be RTS elements, but none of them have been implemented yet. We did think about food and water, but it is not certain if any of them will end up in the game. Food is interesting and it is an important variable in a strategy game. We need to test it first and see how it blends with the rest. Water is intereseting too, but it is complicated. There is a limit to the number of dynamic things we can add to the engine. If we can do water properly, we will. If it turns out to be heavy or too hugly, we may not.
________

Q: Will there be infinite map and random island generation?
A: (Francois) It is a tricky question. We would like to have a huge and generated world, but it may not be infinite. The thing is, in my opinion, a completely random world is generally not as interesting as a partially random one with some elements that have been designed to be interesting. We have not started that quest yet, but we plan on experimenting a lot in that direction.
________

Second question round.

________

Q: Can we save our blueprints?
A: (Germain) Yes we’re going to call those prefabs. There will be a maximum size for a prefab, so you can’t save your entire castle (that would kinda suck, right?). But in the game you will be able to place a prefab somewhere to speed up building. We haven’t implemented that yet, but we’ve been thinking about it for a while.
________

Q: I’d like to know if they have any plans for enemies. Will there be other bricktrons only? Or monsters too?
A: (Germain) There will totally be monsters. We want the bricktrons to be cute so having them fight each other wouldn’t be nice, right? Monsters aren’t implemented yet, but they’re an important part of our lore.
________

Q: Whats your favourite restaurant in Montreal? Also what is your favourite part of working on this game?
A: (Francois) I really like the Café Santropol. It is a restaurant specialised in big sandwitches. It’s not to expensive and there are a lot of organic and vegetarian options (I am vegetarian). And there cake is both awesome and huge. What I prefer of working on this project is the small and flexible team, designing a video game is a lot easier if there are just two people involved. For every complex question, you can just turn around and talk about it out loud to get the “entire” team’s opinion.
________

Q: Is it possible to make mines in the mountains and than build a castle inside of it, or will that be a problem for the camera?
A: (Germain) This is a really difficult system we’re talking about. To be able to “slice” in the terrainand see what’s inside is a really difficult system to build. We’ve been working on it for more than a year and its not ready yet. But it’s so important to the finished game that we wouldn’t release the finished game without the ability to see inside the island. So yeah if you can see inside a cave I don’t see the reason why you couldn’t build your castle inside one.
________

Q: What about multiplayer?
A: (Thierry) A lot of it will depend how the mechanic react in the game. About the dedicated it is sure that it could be a good idea but we aren’t there yet in development, we want that the game work on a single mode first and then we will develop tools to make it work on multiplayer :)
________

Q: How did you start making the game and what did give insperation to it?
A: (Germain) Three years ago, a friend of ours showed us a game prototype he made, where two players would have a castle build out of blocks on spinning platforms. On each side of your castle, there was a cannon with a certain color. If you rotated your castle and shot with a cannon of a certain color, the bricks of the same color that you hit would give you points. It’s hard to explain, but it was a really fun game. That was our inspiration.
________

Q: Will the day/night-cycle have a big influence, like bonuses for units depending on wether it is day or night, or is it simply cosmetic?
A: (Germain) The night and day cycle will definitely not only be cosmetic. We plan on having a completely different ambience and a completely different gameplay. During the night, there won’t necessarily be more monster (there will be monsters during the day too). But during the night there’s gonna be magical shit going on. Magic is going to be a big part of our game, and the night’s going to be when all the magic stuff happens
________

Q: Will there ever be an element of “machinery” or traps?
A: (Francois) Yes. It is hard to say how much traps will be elaborated, but we are already planning some basic macanism like draw briges
________
Q: Are you hoping to put music into the game? If so what kind of music are you hoping to have?
A: (Germain) We just hired composers. We haven’t heard what they did yet, we gave them a lot of room for creativity, so it could be anything. Check out Anosou music (mattias haggstrom gerdt) and Josh Welchel to hear what kind of music they make.

________

Third question round.
Over 9000 messages/sec (seriously).
Germain: “LOOOL”

________

Q: Will your base island travel or be moved around?
A: (Francois) Islands are static and will stay so for now. Getting the Islands to move would be the work of several months so let me put it that way: it is a dame cool idea and we seriously thought about it, but we do not plan to make it. If we end up updating that game for many years (who knows?) it is one of the things I would like to add.
________

Q: Is there anything that we can do to help you make the game? Any more thoughts on Kickstarker, or similar?
A: (Germain) YES, we plan on making a kickstarter really soon. Helping us by donating to the kickstarter is the MOST helpful thing that can ever be done. There is a lot of preparation though, that come in making a kickstarter, because you can only do a Kickstarter in the US. Since we live in Canada, we had to find people that live in the US to help us, and then we had to hire lawyers to sign the right papers so we don’t go to jail.
________

Q: How did you realize, and what was your reaction to your game’s sudden explosion in popularity, it’s obviously been much more popular than you imagined?
A: (Germain) I was pretty dumbstuck. I’m not used to being in the spotlight, so this really helped me build my confidence. (Francois) A friend of mine told me that the game exploded on reddit. I got there and didn’t belived it at first. In my opinion, I would have been happy to get 1000 views in one month or so.
________

Q: If someone gave you a million dollars to make a “better” game, would you pass up the money to keep it just you two or would you hire on more staff to add more features quicker?
A: (Germain) I don’t know about a million dollars, cuz it’s A LOT of money… But I definitely want to stay in a small team. This game is our baby and we don’t want some random dudes working on it. Indie development is all about taking risks, and since I quit my job for this, and now that I know that the game is kinda popular, I will never “sell out”.
________

Q: How big is your fanbase at this time, approximately? (in thousands, I guess) And how does that make you feel?
A: (Thierry) Very big, each day we receive between 5k-15k (depend of it there is a new blog post ;) ) on the website. I know that it scares me sometimes but it is very encouraging for us at the same time.
________

Q: Do you look at this sites suggestion forum? Did you see anything you like?
A: (Francois) Yes, we read everything you write. Or at least we try. We try to spend one hour of every day of work thinking about our game’s design and we have been working on it for almost two years, so we have already thought about and considered most of the ideas I saw. However, what I really like about the suggestions is seeing how you discuss them. It gives us a feedback about what you think and what is most interesting to you. We did, however, find a couple of new and very interesting ideas. One I can remember quickly is a suggestion about how to make an simple rebuilding system after your castle blowed up.
________

Q: Will there be any way for the bricktrons to “level up” as in if they spend a lot of time mining will their mining speed increase?
A: (Germain) We plan on having a few stats on the Bricktrons, but the game is not going to be based around it. For example, a particular Bricktron might be good as a Knight, but if you want you can change him as a miner, he’s just going to be slower than a Bricktron who’s been mining all his life. It’s going to be simple though, not big complex RPG stats.
________

Q: Are you going to add volcanoes to the game, and if you are is there going to be any uses for the lava/magma?
A: (Germain) Yeah, lava could be really cool! We’d like to be able to program that into the game, but it will be hard.
________

Q: Will there be seasons? If so will they have any influence on the gameplay?
A: (Germain) There won’t be a season cycle, but having islands with snow, or a desert island would be nice. We would do that once the basic game is done, we want the grass island to work right first.
________

Q: Is it difficult for you to choose features that you want to add to the game? Or you have a clear vision how the game will look like at time of it’s release?
A: (Thierry) Like every indie games I think that the ”beta” stage of the game will allow us to decide what to keep, what feature to add, keep or remove. We already have a sort of vision of it but it is sure that more we get in the development the more we consider adding more features.
________

Fourth question round.

________

Q: I was wondering about how “structurally sound” our buildings will have to be. Meaning: will chosing arches over colums, for instance, make ANY difference on how resistant our castles will be? Will a certain material be able to hold more blocks over it than another material (eg. stone and wood)? In other words: apart from the blocks we chose, will there be another way to make our castles “tougher” or can we completly ignore physics in the building?
A: (Francois) For now the most important thing in making a solid castle is how you alternate your bricks. For example, damage spreads in a regular patern and the way you alternate and mache your bricks influences the way damage spreads in your walls. You can do things like “damage sinks” by matching perpandicular walls in your constructions for now, there is no real wheight system so arches are not better thant simple colomns. We plan on making suche a system in the future however
________

Q: What age rating will you guys be aiming for? Not exactly asking for you to make it “mature for mature gamers such as myself”, just curious.”
A: (Germain) We will try to keep the game available for everyone. I believe that everyone can enjoy ourgame in the current state. It’s good for kids, but also has this nostalgic vibe for older people.
________

Q: Do you add hotkeys? And something that everyone is wondering on the forums: how do we produce new bricktrons?
A: (Germain) There will probably be hotkeys once the game interface works. You will be able to produce Bricktrons with a bit of magic and some special resources.
________

Q: Is weather affects like Earthquakes, tsunamis, snow, hail, rain being considered? And if so how will it affect our fellow bricktons?
A: (Germain) Lol, tsunamis would be pretty harmless to flying islands. We’d like to add wind storms or thunderstorms, but that will definitely be added later than sooner.
________

Q: How will Bricktrons be trained into Knights, Archers, or Miners?
A: (Francois) Well I can’t go into details, because any kind of system will be subject to tweek, test, and experimentation. The general idea, however, is simple. To make a knight, you first need to craft a set of equipment. So a knight is anyone who wears a armor and a sword. Then there is the training. Exposure to combat will probably improve their fighting skills, but it is all we know for now. The same goes for the archers.
________

Q: Will there be some sort of a competitive multiplayer mode, maybe even with a ladder ranking? Or in other words: Have you thought about going into the direction of a competitive RTS like for instance the Starcraft franchise?
A: (Thierry) As said before, we aren’t there yet but I already thought about gathering statistics for each game like game/win/ even maybe acheivements? because the player will already have an account to play multiplayer so why not make it more fun than just a simple log/pass system.
________

Q: Can you tells us more about bricktrons? Like how do we get more of them? Is there anything funny about them?
A: (Germain) Like the evolutron wallpaper shows, bricktrons are definitely made out of something like stone, but there’s a bit of magic in there too. The bricktrons are pretty unlike anything in our own world.
________

Q: Can you live stream when you work form time to time? Is it going to be multiplayer and how many can it be in the same map?
A: (Thierry) We could livestream maybe, the problem we have here in Quebec is the bandwith limitation, and we don’t have make any multiplayer yet so we cannot tell yet :P
________

Q: Did dwarf fortress influenced the development in any way?
A: (Francois) We never played dwarf fortress so no, we didn’t took direct inspiration from it. We recognise, however, that it is a important precursor of the style and completely respect it.
________

Q: How would this rebuilding system work?
A: (Germain) Basically, everytime a brick is dislodged/broken, a special phantom block will be added to a second set of blueprints. You can assign bricktrons to this second blueprint so that you have some dudes dedicated to fixing your castle.
________

Q: Did you like Mobe’s Story?
A: (Francois) Yes, We really liked Mobe.
________

Fifth question round.

________

Q: Will there be any other methods to explore the world? Such as air transport?
A: (Germain) We really like airships. We think they’re awesome.
________

Q:
A: (Francois) At first, we thought that most of the game would be singleplayer and story based. After a while however, it apeard to us that there was a great potential in turning the game toward a multiplayer/open game so we took that direction. So for now, we do not plan on having a direct storyline. Having some narrative elements would be cool however and, given the time, we whould like to add some.
________

Q:About mobile versions yet, Unity for Adnroid and iOS?
A: (Thierry) Unity3d Indie does not provide mobile export, so depending on the succes of castlestory, maybe. We really want first to make it work for computer and ”puny laptops”.
________

Q: Will there be Bricktron offensive magic users?
A: (Germain) There will be magic in the game, but there won’t be a specific “Sorcerer” type of Bricktron. We have this idea that you can create magic effects by combining special magic ressources together. Then you could have a Bricktron running around throwing magic stuff around him, but he won’t be a magic user specifically.
________

Q: Will you be supporting LAN?
A: (Thierry) I guess for the multiplayer, we will work with IP adress, so it should yes.
________

Q: In Francois’ video (development blog 4) we could see a catapult. Is this catapult finished yet? How does it work?
A: (Germain) Well, we have been working one the basic mecanism, but nothing is ready to show for now. To be honest, we thought of making it a suprise, but forgot to remove that button for the video. Well hopefully we will get another ocasion for that.
________

Q: Will you plan to translate this game in other languages?
A: (Thierry) There is not much text now, but I guess when it will be time to get ”international” we will ask for help from the community for that.
________

Q: Something I read a lot in the suggestions, was the comment “maybe they can make an extra mode for this”. Are you planning to add different gamemodes once the basic game is done? Or will you rather add modding support, and let the community do so themselves?
A: (Germain) Gaming modes ideas are being planned, like capture the flag, invasion, freeform building, exploration (singleplayer) but we’d like to finish the basic gameplay before we start working on that.
________

Q: Could TNT be used to mine out materials?
A: (Germain) It’s a bit extreme, and probably expensive, but why not!
________

Q: Where is Francois’ brother?
A: (Francois) He is spending the night at his girlfriend’s.

________

Sixth and last question round.

________

Q: How will weapons work within the game, do you plan on cannons, if so how will they be built?
A: (Germain) Cannons killed the castles and ended the dark age because they were unbalanced. Catapults didn’t. Cannons are cool but we have to put a limit in the level of technology accesible. They will most probably not be there.
________

Q: Will they show signs of fear or happiness when presented with different situations? Either through small emote bubbles, or animated emotions (or both?)
A: (Francois) Yes, definitly. Giving emotions to the characters is one of our musts.
________

Q: When will the About section on Sauropod Studio be done xD?
A: (Germain) Before the Kickstarter! We have a friend who takes really good pictures, we’ll put them up with a short description soon.
________

Q: Will you introduce a random event system, One that causes Disadvantages and advantages to players?
A: (Francois) Too early to say. Thought about it, though.
________

Q: Will there be a “floor”? Where all the exploded blocks/Bricktron fell and are waiting to be get picked up?
A: (Francois) Absolutly not. It is one of the funny thing when you live on a flying islands.
________

Q: Will monsters be able to make/use seige weapons? How nasty can these monsters actualy get?
A: (Germain) We haven’t programmed the monsters yet, but they will have tricks up their sleeves, like being able to climb and being big and strong. We’ll start by programming a basic monster, then we’d like to go crazy.
________

Q: Friendly monsters?
A: (Germain) Totally, we have good ideas for those.
________

Q: Will there be flying unicorns?
A: (Germain) No.
________

Q: Do you ever interact with other indie developers? Like those of Starbound or maybe Cube World?
A: (Francois) We have a couple of indie friends here in montreal, but our social game develepper network doesn’t got farther thant that for now. We are really busie, but we whould definetly like to meet more people doing the same things as us.
________

Q: I noticed we’re not chatting with any sound designer right now, do you guys have one?
A: (Germain) We don’t. If you like to submit a porfolio, send it to contact@sauropodstudio.com
________

Q: What kind of music do you guys like?
A: (Germain) The type of music we put every week in our dev diary! Chiptune is good too.
Red: “<3 Chiptune”
________

Q: Neutral Bricktron villages?
A: (Germain) In the singleplayer part, most probably.
________

Q: Would there be a tech tree, and bricktrons could research better things such as improved bows or better siege weaponry?
A: (Germain) Upgrading you stuff would be nice. We’ll keep it simple though.
________

Q: Will there be animals that have specific behaviors, like fleeing from people, eating, staying in certain areas, living in caves and not leaves them, etc?
A: (Germain) Yes! we can’t reveal exactly what kind of critter, but this is a big part of our concept.
________

Q: Will there be different races of bricktrons? Example: Yellow race specialized in building, Red race specialized in fighting, and so on?
A: (Germain) Most of your bricktrons will be yellow. it’s part of their concept. Instead of changing colors, we’re going to give them different hats and props. This might change in the future, though.
________

It’s been a slow week. Combine bad weather, an outbreak of flu among the team, and the fact that we’re all starting new tasks, nothing concrete really got finished this week. We’re definitely not procrastinating though, here’s a list of what we’ve done:

Redesigning the game character

So a few weeks ago, we decided to update our asset importing pipeline. Essentially, this meant fixing scale and orientation issues directly in 3dsmax, instead of in Unity. This fixed a lot of our problems, but unfortunately, this meant that we could not use our original character rig.

What’s a rig? The rig is basically the skeleton of the character model. When we animate the bricktron, we move the bones of the rig, and the “skin” (the visible part of the character) follows and deforms appropriately.

The problem is that rigs rarely scale properly. And since we changed our world scale to match the one we use in unity by a factor of 100, the rig completely exploded. Nothing could be salvaged so I had to re-build it from scratch. This gave me the opportunity to rebuild the character model a bit better too!

Here I will explain my personal process for modeling, rigging, texturing and animating character models:

Sculpting

I have a rather unorthodox way of modeling characters. First, I start by sculpting a detailed mesh in a software called Sculptris. It’s ridiculously easy to use and it’s free, go check it out. It allows me to model away without having to worry about topology and also lets me go into as much detail as I want. This is by far one of the most enjoyable part of the whole process.

Topology

Secondly, before importing this into 3dsmax to create a low poly version of the model, I bring the high resolution mesh into paint mode. This is where things get weird.

I proceed to paint the low poly mesh by hand on the high res surface. This allows me to be much more creative with my topology and lets me try different ideas. It’s much faster too, in my opinion.

Low-poly modeling

Now that this is done, I import the model into 3dsmax, and simply recreate the painted mesh with actual polygons. Normally this would be one of the longer parts of the entire process, but in this case, since I planned everything out beforehand, it took me less than half an hour to get a low poly mesh.

Unwrapping

Next, We have to UV Unwrap the low poly mesh so we can apply textures on it. This is the part everyone hates. It’s hard, complicated and you have to deal with stubborn tools that insist on messing up your work. UV Unwrapping consist of cutting out your model so you can lay it out on a flat surface. It is the digital version of papercraft.

Texturing

Once the model is properly unwrapped, I do a quick pass for texturing. Contrary to everything else I do in Castle Story, the Bricktron model is not painted by hand. I prefer to build a clay-like shader and bake a bit of the lighting information in the texture. This gets me better results. Notice that I don’t include the face in this model because we plan on having face animations, and this involves having separate objects for the eyes and the mouth.

Rigging

After that I have to build a rig (skeleton). This involves placing the pivot points for the joints in the right spots and testing how the knee of the elbow flexes if I place the joints differently. It is a very complicated process to build the bone hierarchy and create the Inverse Kinematic joints. This part took me most of the week, and I had to start over a few times.

Skinning

Then we have to skin the low poly mesh to the bones. Basically, this means attaching every vertices (the points where the lines meet to form polygons) to their respective bones. To get a skin-like effect, we attach most vertices to multiple bones with a percentage. For example, a vertex on the top of the head will be attached to the head bone with a weight of 100%. However, a vertex in the armpit might be attached to the shoulder, to the upper arm and to the spine with a weight of 33% each. If this is done properly, the skin will deform realistically and the character will look good.

Animating

Finally we animate the character. This is where i’m at right now. I havent started this part yet. I will have to create animations for every possible movement of the Bricktron. There may be dozens or hundreds of animation in a finished character, but if I do a good job, they should all blend into each other and the character will look lifelike.

That’s all of it!

So yeah, this blog post is getting pretty long, so I’ll wrap it up real quick.

Anyway, that’s it for us. Don’t miss the live chat session, like… right now! Friday the 16th, 8pm Eastern Time, on the CastleStoryOnline forum IRC.

See you next week,
Peace.

The Sauropod team