• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
  • comments
  • views

About this blog

Fun is just part of the concept

Entries in this blog

Matias Goldberg


Distant Souls

I've been working a lot since the last time the pre-alpha demo was released. I've been doing improvements overall based on the feedback from testers. I'm trying to get a new demo ready so that more testers can be engaged into the play mechanics. There were two big elements that were present but were very overlooked in the last release: combats & platforming.

Additionally, I've noted there was something lacking, and I believe there was some sort of customization factor. Players are now have an inventory! They're able to wear equipment to become stronger, loot items Diablo II-style, and even level up. It looks like an easy feat but trust me, it takes a lot of time!!! There's a lot of gotchas: what happens if I unequip an item that was allowing another item to be equipped? Should that item be also unequipped? And what happens if there's a domino effect? What happens if the inventory was full? Should the item be dropped? But what if the player was just experimenting? Wouldn't it be frustrating if all it's gear wears off?


Combat is now balanced (or at least, not so unbalanced as it was before); but there's still missing a subtle but straightforward introduction to the combat mechanics. Combos were included in the previous demo, but most of players didn't even notice or figure it out. I need to work on that.

Aesthetics revamp

I dedicated some time to adjust contrast, brightness, HDR exposure, colour balance, sun's size (it was huuuuuge). All stuff I've been delaying until I eventually got used to it being wrong. Good thing players keep reminding you to them. With these corrections, it's much easier to note the cloud shadows (which are very cool)

There are also new 3D models, and a new enemy character. Furthermore, I've significantly improved the normal mapping on the terrain. The close ups are unbelievable detailed.

Towards multiplayer

Even the first demo supports multiplayer, it's just disabled and hidden. However this time I'm working both gameplay-design and code towards full multiplayer integration, matches are already possible; but there's no GUI to setup the connection yet.
Distant Souls supports both PvP as well as team quests.

The Dead Linger

I joined Sandswept Studios' team! I'll be working with them to take their Graphics to the next-gen. They're working really hard towards an alpha release of The Dead Linger and I'm going to make it look good(TM).
Naturally, this will impact in the development of Distant Souls by slowing it down (as I'll only be working on it in my little free time), but it's for the best for everyone.
The project data is downloading as I write this post, once I get to the code I should be able to buff up their graphic tech considerably smile.png

Final words

There's a lot I didn't talk about, but there's not enough room or sometimes I don't even remember every improvement detail! There's a lot more to come, but as I said, for the time being my main focus will now be in The Dead Linger. Enjoy the pictures!
You can view all of them in full resolution through the web player


This is a repost from my Dev. blog
Matias Goldberg
How to design a massive boss battle

Initially I wanted to get ready an introduction scene and a boss battle. Shortly after I realized the timeframe wouldn't allow me to do both. I had to choose. So which one would more badass and entertain more? I went for the boss. And I'm glad I did.

In case you have no idea what I'm walking about, you can

watch the video here

. Or

download the game demo from here


Creating the boss battle

I had an idea of a giant enemy. Something BIG(*). something that would cause impact in many senses. This boss presented a lot of challenges:

  • Physics representation was enormous (Sphere radius was of roughly 80m). Havok isn't prepared for something that big unless it's static. And you were supposed to to hop on it while it's moving?
  • A lot of animation data was in this boss. Therefore the physics need to interact accordingly.
  • Not only is it big, but some movements are fast. Due to it's size, some velocities reached the order of 1.000 m/s. Again, Havok isn't used to such operating conditions.
  • Even with continuous physics enabled, using mesh shapes resulted in lots of bullet-through paper glitches. Too often the player would end up stuck inside Turtarian's shell.
  • The engine's code needed to be improved too. How the camera handles tracking of such a large object, the allies & foes' AI was going nuts with him, a custom AI had to be made to script the boss battle, the lock-on system was buggy, etc. Placing this object in scene revealed a lot of small bugs or limitations that needed fixing.
  • All of this while the game is running internally @60 fps.

    Standing on top while still running at 60 fps and no glitches wasn't easy.

    Once it started to work, it seemed reminiscent of Shadow of the Colossus(R), even though I've never played it. So, I started to watch more Youtube videos about SotC, God of War III(R), and Castlevania: Lord of Shadows(R), all of them featuring gigantic bosses.
    I liked more the idea behind SotC & Castlevania: LoS, rather than God of War's. In the latter, giant boss battles were limited to "face the enemy straight and smash the attack button"; where in the former two, there was a more strategic and patient approach. What I really missed was to ditch the climbing elements present in SotC and Castlevania, which are very fun when the boss is moving. Originally, when I first starting coding the engine, I wasn't thinking of large scale-enemies. It was a happy coincidence that worked far more than I expected.

    (*) Rule #1 of scale: if everything's big, nothing's big. Just because your 3D model software says it's huge, doesn't make it so. A giant must be in contrast in a place where almost everything is tiny, in

    How the solution was approached

    I tried several solutions before ending up with something I liked and worked:

    • A dummy object is used for character controller. Everything else (shell, head, claws, tail) is controlled setting Havok's motion types to Keyframed.
    • The main shell is a mesh shape, based from the same object that is rendered, but previously decimated.

      Physics shell (left) vs Final version used to render (right)

      • Using the mesh shape caused lots of bullet-through paper. Since you're not supposed to be inside it; multiple phantom shapes had to be placed inside the shell, teleporting you out of it as soon as you get in contact with it. Due to time constraints, I was unable to refine their placement, therefore some players may still experience a few glitches for a few moments if they try hard to get inside.

        Phantom inside the shell to prevent getting inside

        • The claws, tail, neck and head are all native shapes. Mostly capsules, and a few boxes & spheres. All of them are compund objects. Each compund object was attached to a bone. A blender script exported the shape's definitions, as well as the correct parameters to make a perfect alignment when attached to the bone.


          Capsules boxes and spheres were used for the physics representation (left). They don't exhibit bullet through paper like the shell, because of they're native and closed method. On these objects, bullet through paper would only appear if a velocity is so big that between two frames, the character goes from one point to the other of the capsule. This isn't a problem when your objects are this big. Think of it as having native objects being filled, while Mesh objects instead being thin and hollow.
          Blender supports Bullet physics. Since Bullet & Havok are ridiculously similar, the Logic pane was used to set the Physics shape information correctly, using parenting to define compound linkage.

          Blender's cursor was very useful for synchronizing the shape's position and orientation and the bone's starting position, (Shift+S in Blender). Workflow was very straightforward.

          I admit, Turtarian's boss battle experience may not be yet on par to SotC or Castlevania's, I'd love to be proven wrong by gamers, but I know there's a lot of room for improvement, and I can do it much better.
          It was my first giant boss fight. And I learned a lot. Plus, now I have the tools development, and a stable code that can handle it.
          As with all games, a lot of ideas were cut. Furthermore, the more I played with Turtarian, the more ideas kept popping out. Specially ideas on how to climb big bosses while using current mechanics. It's very common to think of using gameplay mechanics from other games, some of which are not even implemented or would be difficult to do. That's why it's very important to test, test, test.
          New ideas will keep coming that will match your mechanics.
          Other ideas included additional environment models where you could climb to hop easier to Turtarian. Even interacting with the city walls was very interesting, because they were more or less the same height.
          Even more ideas kept coming after I tried Turtarian in the final terrain, which has uneven heights. For a long time, I only tested the boss battle in a flat terrain. Getting your character on elevated ground gives you an advantage, while being in great disadvantage if you stayed on lower grounds. Furthermore difficulty suddenly increased when the tail (which at some point becomes a weakpoint you need to hit) was burried underground because of a sand hill, therefore you first needed to attract Turtarian by running off that place.

          Thanks for reading!
          Matias /signing off

          This is a repost from my Dev. Blog
Matias Goldberg
First, there's bad news: Distant Souls failed to run on the spec. machines from Intel Level Up contest! sad.png
Therefore, it's disqualified.

Now let's change the subject:
There's a DEMO AVAILABLE FOR DOWNLOAD!!! smile.png

You may have seen I a forum thread about it in GameDev



    [size=1]Update: Uploaded new version SVN 608, which fixes incompatibility issues with Intel 4 Series & nForce 6150. Thanks for your feedback!
    System requirements:

    • Windows XP/Vista/7
    • Intel Core 2 Duo 2.2 GHz or better/AMD Athlon 64 X2 5000+
    • 2 GB RAM
    • NVIDIA Geforce 8 series or better / ATI Radeon HD 2000 series or better (Shader Model 3.0 compliant with full VTF support)

      Unsupported Hardware:
      The following hardware is known not to work. And it's really hard to support them, this list not likely to be reduced:

      • ATI Radeon X1000 series
      • Intel GMA 950 series
      • GeForce 6200 (??? needs confirmation)

        Gameplay Videos:


        Ways you can help:

        • Share! Follow! Subscribe to my videos smile.png
        • Does it run in your machine? Post all your 5 Logs, they are in the file %AppData%\Distant Souls. Also post all your *.rpl files there so I can reproduce your bug.
        • What do you think about the game?:

          • Do you like it?
          • Is it fun?
          • Was there something you spent too much time to figure out?
          • were you stuck?
          • Did you enjoy it?

            Didn't enjoy it? Then tell me! You won't hurt my feelings! Games are an iterative process. We will work on it as many times as possible until we're all 24hs addicted.
            This is valuable feedback and please post your results!

            IF YOU OWN AN INTEL HD 3000 PLEASE SHARE YOUR EXPERIENCE WITH US!!! I'm 99% sure the game didn't run in the contest because of that GPU, even though, it's ought to be capable to run it. I need to fix that!



            Plot summary

            Distant Souls takes place in the historical events in Dyrvingahl. Long before the start of the game, a dark being killed Nathan's parents, destroyed his entire village, and started a war between the Three Proud Nations.
            15 years later little is known about the dark being and those few who track him down call themselves hunters; each hunting it for it's own personal motive.
            Today, the world is in complete turmoil, many factions constantly form alliances to take over cities; lasting their control as short as the alliance was formed; while hunters have to make it's way through to reach their ultimate goal.
            Player's hunters will have to face with the decision to involve in local affairs or stay distant as much as they can.

            This is a repost from my Dev. blog
Matias Goldberg
So, I was reading a few forums today, and crossed around this page, about the tax implications of crowdfunding.

I don't know how it's currently being handled. Probably the way it's been suggested by the posters.

I'm not in the US, nor am I familiar with their tax laws, but I am familiar with the one's in my country and Taxation Theory in general. I would like to develop further on the concept; since my soon-to-be accountant mind can't stop guessing about it:

The problem with crowdfunding, as I addressed previously in another post, is that it's not well defined what it actually is. And hence, it's hard to tell how it should be taxed.

It looks like a pre-sale on most aspects, except that if the project isn't delivered, the money is lost; which is why it also shares some aspects with an investment, because backers take a risk. Or it could be seen as a simple donation.

Note: When I speak about "some laws" I'm referring to "laws in different countries".

Is it a pre-sale?

If it's a presale, then the company is owing something. In accountancy terms, that money doesn't constitute accrued revenues yet.
Some tax laws impose the obligation to pay the tax the moment the money enters the company's pocket, but most of the time, the obligation comes when the revenue becomes accrued.

This means the tax will be paid the moment the game is sold (or when the project gets cancelled, unless the money could somehow be handed back to their backers. Although this would bankrupt any start up company)

Is it a donation?

If it is, then the moment to pay is when the money enter's the company's pockets unless it's a non-profit organization. Seemingly easy case.
Except when the company then "gives away" their game to their backers, it constitutes a donation (which is actually a delievery of what's been promised), this time from the company to the backers.

The thing is, some laws prevent or impose limits to substracting donations from their Gross profit, resulting in higher gross profit(*). Therefore such "donation" is taxed again. This constitutes double-taxation, so proper care must be taken to explain your local Country's IRS of the situation.

Another approach to the double-taxation problem is that it's not a donation at all, but rather a necessary cost to sustain the Source of Earnings, therefore the limits to substract donations from net sales don't apply.

(*) I simplified it since most of the readers aren't tax experts. Donations are actually substracted from gross profit, resulting in higher net income. Doesn't really change the point of the discussion.

Is it an investement?

A long discussed argument. I won't go into why it is, and why it is not.
But if it is, then investments aren't taxed. The moment the investors pay their revenues varies wildly per country. Normally, variations include:

  • Investors pay their taxes when they receive their dividends.
  • Investors pay their taxes when the distribution of dividends has been decided.
  • Investors don't pay, because the Company already paid for them.

    • The company is not allowed to substract dividends from their Gross profit, resulting in higher Net income. Paying a tax on the dividends would be double-taxation, so nothing is done.
    • The company is allowed to substract dividends from their Gross profit. The tax is separately paid by the company either when the dividends have been approved or when the investors actually receive the money.
    • There are also hybrid models (investors pay a portion of the tax, the company pays the other part)
    • etc....

      The thing is, none of the backers receive dividends. Therefore the money they put in, is never taxed; but we could do a bit more reasoning behind it:

      • If the final game is worth more than the ammount the backer "invested", that difference is a taxable result. Thing is, unless some law says otherwise (i.e. for the sake of simplicity), it is the backer the one who should pay the tax, not the company! It should be noted though, the company ought to be able to deduce that difference from their gross profit (see donations above); in which case the total ammount the Government receives is cancelled. As a result, tax laws should consider not to pay in this case; as it doesn't make sense to spend effort on this. But unless there's a law allowing it, it is the backer who ought to pay the tax.
      • If the final game is worth less than the ammount the backer "invested", that difference is also a taxable result! The company received more money than it should and must pay taxes for that. As for the backer, unless he makes game for a living (the backer is either another game company or an indie developer), he probably can't substract that donation (depends on the each law). This difference is a taxable result.

        Since the only way crowdfunding can be taxed is, in this line of thought, when the final game is worth less than the ammount the backer invested; this is clearly the worst option for the Government, and the most beneficial to videogame companies and the "investor"; from a taxation perspective of course.

        My personal opinion, crowdfunding resembles a lot like pre-sales, and should be taxed as such. The alternatives are way too complex; while the pre-sale method of handling taxes is widely used and well understood. Furthermore it is the most fair and provides incentives for start up companies, since tax payment is delayed until the game is produced & released, allowing a company to use funds obtained from crowdfunding with more freedom; provided there's an exception for start ups in case they fail to deliver the project.

        Well, this ended up being longer than expected, but I think I fully covered the issue. Hopefully we'll start seeing some more serious debate about it.
        I'm hoping to see some feedback, as well as some of you sharing your stories or your a view from your Country's legislation in the comments.


        Don't forget to subscribe! @matiasgoldberg

        This is a reprint from my dev. blog: http://distantsoulsd...-and-taxes.html
Matias Goldberg
3 months in crunch mode, 2 sleep-less weeks and a fully playable demo has been developed.
Evertyhing has been made under a very tight scheduled and I'm glad I was able to meet it.
It requires a lot of sacrifice and self-discipline. Indie game development is not for everyone and there are a few articles already about it.
Everything's now up to the Level Up 2011 judges. All I hope is that they have a lot of fun when playing the game.

What to include in the demo?

Initially I wanted to get ready an introduction scene and a boss battle. Shortly after I realized the timeframe wouldn't allow me to do both. I had to choose. So which one would more badass and entertain more? I went for the boss. And I'm glad I did.
In the next weeks I'll be writing about how this boss was made some other time.

The importance of contests

The contest's prizes sure are juicy. They're quite motivational. But it's not just that what makes a contest so important. They impose you a deadline. You're against the clock and you know that by certain date, you need to have a fully playable demo. And better have it polished.
"But it's a tech/prototype demo, right? Judges will take into account". Yes, they probably will, may be they won't. But I believe a more polished, professional-looking game will be at an advantage over those that don't. This doesn't mean that an unconventional prototype-state competitor appears to be too fun has less chance to win. Additionally, here was my logic:
Among all the contest prizes, whether it was the first or the last prize, one of them is that the demo will be featured in the Steam's 'Demos' page. May be they'll ask the winners to polish a bit more before publishing the demo (i.e. create an installer); or maybe they won't. After all, the demos don't require to meet the quality standards that full-featured games have (Steam integration, leaderboards, achievements, etc)
If they won't... I asked myself, "Do I really want my game to look unprofessional when it goes to the demos page? Judges may be forgiving on prototypes, but gamers/consumers aren't"

And there it goes. A driving force as how polished a game should be. I had already noticed this advantage from entering a contest when I was doing Derby Attack.


Last 2 weeks... /CRUNCH MODE: MAX

Just like in traditional game programming, when you're approaching deadline, development(*) consumes your whole life.
That may sound awful, but very good things came out of it:

  1. The GUI was developed in those 2 weeks. I finally have GUI. Wheeee!! Now I can change game settings on the fly without having to edit a Lua file. I can also make interfaces for controlling live values in real time.

  2. Levels can be restarted over & over again. At first frequent crashes appeared, and some engine weakpoints were revealed. But almost everything is well now; and I can change a Lua file using hotspot and reload the level without having to reload all resources again.

  3. It looks professional the whole time. Now everytime I'll need to demo the game (i.e. to potential investors) I can ship it as is, with latest modifications & enhancements.

  4. Fixed small bugs & details that where being delayed. Those are flagged for "fix later". Two or three bugs have been there since... a year ago!

These are the sort of details that one doesn't push unless there's goal to achieve, as when it happens when there's a contest deadline.

(*) Note that I prefer saying "develop" rather than "programming", as I've been doing all kinds of non-programming tasks that take me an equal amount of time: 2D & 3D modeling, game design, sound fx recording & layering, testing.

That's all for now.
Remember to subscribe!
/crunch mode: off


This is a reprint from my dev. blog: http://distantsoulsd...ntel-level.html
Matias Goldberg
It's been a long time since a made a post. I have ton of new material; but my focus is in getting the demo ready for the Intel Level Up contest. It's a very tight schedule. My apologies on that. I have a whole city and a badass boss battle on the works.

I'm just passing by to tell my thoughts out loud regarding Double Fine's success:

  1. With so many backers, does this:

    1. Actually mean the company is just getting a lot of pre-sales?
    2. If, so, the Company gets +1 Million in funding plus revenue for sales; or they won't sell well because of that high ammount of "pre-sales". Is a great portion of his market funding the project; or just a tiny bit?
  2. Will they sell like millions or tens of millions of copies, or just a few thousands more?
  3. Will Valve be happy to give away +42k free Steam codes? Having a popular, successful game in their portfolio certainly keeps clients loyal to the brand; but Steam might face little direct profit from it.

Due to these interrogations, the concept of "funding" must be carefully taken; because as is; it's potentially including the concept of "profit" itself. Under normal cirumstances, one usually tends to believe that, given a budget, he is allowed to spend most or all of it (as long as it is well spent, well distributed over time, and fits expectations).

Then profit will [s]magically[/s] come to recover the investment. But in this case, profit may have already came in advance; therefore I think it's wise for Double Fine to analyze the situation, where they're standing: What were they initial expectations, their expected budget (i.e. 400k); how much better can the game be made by adding more money to it and what's the upper limit at which throwing more money just doesn't make a better game. The rest of the money's fate can't be taken lightly; unless new information would indicate this is only the tip of the iceberg.

My quick thoughts on the subject. I thought I'd have to share them, since no one seems to be doing this kind of analysis other than "amazing, record-breaking success". I'm happy too that Grim Fandango's creator gets such success; I was kindly surprised as well; but it's easy to overlook the gotchas when one's filled with excitment.

Before I sign off, let's leave with a teaser:
This is a boss fight. Notice down below the character's head...

Until next time...
Matias Goldberg
It has been a while since the last post. A lot has been done and I just happen to have little time to be writing blog. Development is steadily progressing and despite the quiet blog. there's a lot going on.

[size="4"]Adrianne was finnished
The main female protagonist/antagonist wasn't finished at the time of writing my last post. Her gameplay mechanics of one of those I like most. She can control the wind to her advantage, making enemies hard to move freely and while throwing environmental objects to them.


[size="4"]Revamped animation system
Animation system was updated, took a couple of days but now works better with particle effects triggering at the right time. It's also easier to write.

[size="4"]Lua Hotspot and Particle FX reloading
For Lua, I created what I call the "hotspot". Basically it consists in three Lua files the engine monitors constantly for file changes. If it finds out it has been updated, it will automatically execute it's contents. This is great for rapid prototyping, without having to restart the game for each small change while, at the same time, having the comfort of your favourite IDE. The hotspot works over a network. If you have an extra PC, you can control the game from one machine and play on the other, without having to Alt+Tab all the time.

The three files have the following behavior:

  • Const.lua: The engine will open this file, execute it's contents, then close the file.
  • New.lua: The same as Const.lua, but the contents of the file are removed before closing.
  • Old.lua: This file doesn't get executed. It gets incremented with New.lua's previous contents with each execution.Intro.jpg

    At the same time, the engine is monitoring all particle effect files (Ogre particles means it watches for *.particle files) If they're modified, the particles being executed are loaded again and restarted. This greatly improves the feedback of particle changes and their visual appeal in game.


    [size="4"]Changed sun's position
    The sun's movement was restricted to the same YZ plane. Very boring, creating very boring, horizontal and vertical shadows. The sun's movement is now more realistic and more fun, creating very dynamic, diagonal shadows in cities.

    It's about perception, take a photo from a car in 45? angle and looks much more in motion, vivid and fun than the same picture being taken straight horizontally. This site explains it very well. I really recommend that website. It contains great explanations about how professionals place their cameras, lights, and edit their scenes. It's a total eye opener.






    [size="4"]Implemented three-point-lighting setup

    The default lighting setup is now a 3-point-lighting setup. It now looks a lot better, and now has this unique feeling I felt it was previously lacking. What I really like about this setup is that it solved a problem that had me worried: it was too dark and "dead". Now the outlines are clearly highlighted, the sense of depth is much greater, and what is darkened is still dark, but you still are aware of what's there, something that was missing before and shadowed scenes could really just become frustrating.







    [size="4"]New site layout
    I knew the blog was looking very simple and without much care. I finally decided to put more on effort on it, since it's currently the visible side of my work. I was hearing a presentation where the speaker said the website is the visible face of the organization, and it affects how people perceives the quality of your work. Crappy website = crappy product/service. That struck me and urged me to do something about the site.
    The mood and colour theme matches that of Distant Souls Act I.

    [size="4"]Attack Animations
    Most attack animations are done (and with it, combos). It still needs tuning, and many of them still have particle effects missing. Still that's the least effort and the coolest part. Not really an issue and it's very exciting!













    [size="4"]New buildings
    Following these tips & tricks, I've started modeling new buildings. One floor per day. I've done 4 floors in total. I could've made more, but studies started delaying me this month.














    [size="4"]Next Focus
    University is taking quite most of my time next weeks. I am now focusing on having more buildings to get a vibrant city soon. It takes little time and highly satisfying results. I'm trying to build an intro in hopes of getting the first trailer and some gameplay footage soon.

    I'm going to participate in the upcoming Intel Level Up 2011 contest so wish me luck.

    There's also a angel investors meeting late November, which I intend to attend. This is quite new in my Country, this year would be the second time this is made. I'm somewhat both fortunate and unfortunate that the game industry is hardly developed in my area.

    Until next time!
    Thanks for reading!

    Did you like it? Then don't forget to share! Click in Share in facebook, or retweet.

    This is a repost from my dev. blog: http://distantsoulsd...ots-better.html
Matias Goldberg
This is a repost from my blog. It was originally posted here.

Whoaaaaa!! It's been a busy month. I apologize for the lack of updates, but I've been very busy lately.

[size="4"]What's new?

[size="3"]Personal stuff

Been studying like crazy, I passed Auditory! It's been very very hard. I'm now this close for graduating as accountant (yes, I'm a C++ programmer, a modeler, and an accountant. Being versatile helps keeping oneself open minded and you learn a lot; as well as taking a business seriously)

[size="3"]Other projects

Ogre Meshy hit 1.3 version. Three versions had been released since last time I posted. Bones can now have their names displayed in the 3D window, better Linux integration and improved stability. Fixed crashes on some resource reloads. It now supports the latest Ogre's 1.8 skeleton format.

[size="3"]Distant Souls

The juicy stuff! Best things come last. I've been working on new models for the game. They're all secondary and primary characters (aka protagonists). By reusing as most as possible, I've been doing new characters at a rate of about 7-9 days per model. This includes modeling, texturing, rigging and readapting the new animations. Each character is taking less time. Last one took me 6 days.

At the beginning I was trying to make each character unique. As a start, each character having it's own height. Really bad idea! Blender is terrible when scaling a skeleton (oops, they call it "armature") as their animations may need serious adaptations. Blender doesn't have retargeting algorithms to automatize the process, so it takes one to two days in fixing these bugs.

Lesson learned: From now on, use standardized sizes. One for boys, one for girls.

Note the following screenshots were taken as is during development. They don't reflect the quality of the end product.

And now, let me introduce you to...


"Look at the camera sweety"




She's young, passionate, s[size="2"]weet and cheerful. One of the main character's love interest. I have very special plans for this character (you'll have to wait for the game!) as a key plot element for the story. Rachel comes from a gifted family, manifested every now and then as a yin-yang symbol in her eyes instead of regular pupils. Naturally, her connection with the spirit world is stronger than most people.






[size="2"]Don't bully him about his girly complexion or he'll kill you. Despite his appearance he's a trained deadly assassin who went rogue. He helps the main team as much as he spends fleeing from the Hashashin order for leaving them.

[size="2"]Originally, I intended him to be the "pretty boy", with some story jokes about it. He was the first male character I did, based on the female models I've been doing. As a result, he looks very feminine. It looked far more feminine than I envisioned. But he wasn't a primary character, and I spent one week on him and wasn't noticeable until it was too late. To be honest, his design is the one I liked less. Let me rephrase... I don't even like it. He was supposed to be a bad-ass looking assassin paying tribute to the game that inspired me to make this game, with a "pretty boy" harassment. So I said "f*ck it". He's staying so. Instead, I've slightly modified the story and he's now a rogue assassin with a psychological complex for being bullied for looking as a girl. I'm considering making him mentally unstable.

[size="2"]His fellow assassin will be bad-ass when it's time for their Order to enter the story (by the way, the other are all bald)

[size="2"]By the way, Matrix-style capes may look awesome, but they're painful to animate. Unless you have a real-time soft body simulator, it gets through everything. It always finds it's way.


"[size="2"]Leave them be, it's not our problem"




[size="2"]One of the main characters. Prefers avoiding battles where he is not involved or has nothing to do with it. This clashes with Nathan, which is the exact opposite. Once he is involved though, his impulses makes him quickly engage directly in battle.

[size="2"]Very astute when it comes to planning. Usually cold, which is the way he hides his emptiness and despair from the harsh world they live in. He's rather pessimistic.

[size="2"]I'm truly proud of his design and details. Took me 7-8 days. He was based on Ismael's model. This time my mom (yes, my mom!) helped me with the face shape. She made me notice the weaknesses in the previous model. For starter a woman's face is more rounded, and if we were to find a shape for the head, it is more like a triangle or pyramid.

[size="2"]A man's face instead is a cube. Of course a rounded cube, but a cube; and with sharper, crisper details. The chin must be considerable wider. His cheeks must stand out to give his male appearance, but they must cover a big area in the face otherwise it looks like a girl's cheek, causing the opposite effect, which stand out even more but are smaller.

[size="2"]As for the torso, a female's body has curves, it's looks like a parabola from both sides. A male's body is a straight triangle pointing down, or a trapezoid.

[size="2"]He's probably my favourite character. Although the name "Joseph" doesn't have quite a ring to it. I'm open to suggestions to change his name.


"Are you looking at me? Good, that way you won't lose hope"



[size="2"]The[size="2"] main character alone with Adrianne. Nate for short, Nathaniel is actually his real name. Determined and focused. Doesn't like injustice, which makes him involved in trouble more than he needs. He understands though, to carry his mission he needs to cast away his feelings. Tries to fill his sadness with smiles and humour.

[size="2"]When Adrianne is near Nate's judgment becomes clouded, causing trouble in the team.

[size="2"]I wasn't sure how he was going to end up looking. I had a rough idea in my head about his clothes, but not about his face. His design wasn't as clear as Joseph's.

[size="2"]In the end I like how it turned. I admit he looks rather typical 16-year-old girl's stereotype of "pretty boy". Nevertheless it as an opportunity for appealing to part of the female audience, while I'm hoping the other part of that audience will be attracted when Adrianne is completed (She's a strong, independent, lone wolf protagonist). The story will tell a sad love story, where the protagonist has a crush on the girl but in the end... well. Talked too much already. What I will say is that it's not a tragic love story, it's a sad one. Tragic (cliche) love stories are about two love birds until one of them gets shot. This is NOT it. It's about complex relationships.

[size="2"]I was dubious whether to make him a pretty face boy who gets rejected, or a tough guy with a soft/weak spot when it comes to her. As the model ended up, pretty face boy it is.

[size="3"]Budget drives plot? Sort of

A plot driven by budget like the title says, sounds like it will result in a terrible story. But wait... what has budget have anything to do with the plot? Nothing is cheaper than writing a sheet of paper, unless you're paying a best seller author full-time to do it.

Well, it boils down to time and technical constraints. The most notable example is the character "Ismael". I've adapted his story to fit his looks, rather than spending 3-4 more days in him to make him look the way I wanted. For a more important character I would definitely spend more time until he looks just the way I envision him.

There are other small details like height. Due to scaling the skeleton being such a PITA, the model's height doesn't always match the specification document I wrote (which has far more heterogeneous values). A few liberties have to be taken and be prepared to accept some changes in order to achieve a fully polished game in a realistic time frame.

I'm usually an obsessive person when it comes to details. And I believe a story has to maintain certain coherence to express the author's true intention. But you have to be able to adapt to the situation, be realistic, evaluate what's important and what's not.

This is still a fun process. It's not always "budget" constraints. During development there were a lot of bugs, wrong parameters, or even tests that failed to do what they were intended to do. Nevertheless out of that process great, original ideas are coming out. I've had lots of ideas just by thinking, and I'm afraid I will only be able to implement less than 1% of these. It even worries me the final product doesn't get to a repetitive boring game by always focusing on the same few things (Assassin's Creed 1, anyone?). I have to be watchful for it and gameplay test a lot.


The cool aspect of the ideas coming out of bugs and failed test (which often results in quests, innovative boss battle ideas, minigames) rather than pure thinking is that if they're already working... then I won't lose time implementing them! Just develop it a bit further, understand why it works, and include it in the game. Simple as that. The hardest aspect now becomes how it will fit in the progress of the game and story, it can't look like a just threw a minigame in the middle of nowhere, with no relevant plot relation at all.

[size="3"]What's next?

This week I probably won't be doing much, I have to study for another hard exam (wish me luck!!! Thank you). Afterward I will resume development of Distant Souls. I have very specific ideas about Adrianne, so I will spend in her as much as I need, as she's very important for the game. That should take around a week. May be I'll do a few weapons, which are easy to make and are certainly lacking.

After Adrianne, it will be time to focus on smaller characters, like crowds, enemies, minor NPCs. Their quality will be considerably lower. We could say they're "mass produced". All of them should take between 2 and 3 weeks (I'm hoping for less). Furthermore the current character have lots of detailed animations (Nathaniel has circa 25 different animations) while these won't have as many, only what's needed for them. Many crowd models will also probably be just a texture swap, same model, same rig.

After that, it's time for attack animations (I've done a few tests so far). That may take quite a long time depending on how it goes (may be even 2 months!) They have to be done once I've done all major characters so that their attacks (times, reaction speed, invulnerability frames, hitboxes, attack combos) are all balanced.


Once that's done it would be time to deal with buildings, level layout, then quests, missions, etc. I'll wrote more about it once I get there. Once missions and levels are laid out, bosses will be modeled.
Some cut scenes will be done along the way, while the rest once everything is done.
All this and I haven't got time yet to talk about the main antagonist. He'll be feature in another post.
It will be a tight schedule but I'm aiming towards February 2012.

I'll keep you posted!!! See you soon!!

Don't forget to comment, feedback is king!

[size="2"][size="3"]Thanks for reading :)

Dark Sylinc

PS: If you're a talented environment artist or animator and want to join the team, contact me at
dark_sylinc [at] yahoo [dot] com [dot] ar Note we work on a profit share basis.

Matias Goldberg
This is part II, you can find part I here.

[size="3"]Motion extraction

As you may have read in the art guidelines, Distant Souls is animation driven. This means the actual behavior of the characters is determined by the mesh' animations, This gives a lot of power to artists, while taking advantage of modeling packages tools.

An attack's (combo) length, how fast the character moves, if it step asides 45? to the left or just 15?; everything is determined by the animation. Some of these settings can be tweaked through Lua scripts, such as walk speed and jump height; avoiding going back and forth between Blender and the game for such nuisances. The animation is automatically readjusted for these parameters, though extreme values won't look good.

This is called motion extraction. The implementation is actually pretty simple; it takes a main bone (i.e. a root bone) and sees how it is translated over time; extracts this information and creates what I call a velocity curve, and then subtracts this translation from the mesh' animation. When the animation is being played, the mesh is now always centered, and the velocity points from the curve are interpolated to find out at which speed should be moving.

Lua code is used to determine how motion is extracted. For example, it is possible to generate a velocity curve without recentering the original animation; or extract motion only along Z axis.

The 3 main advantages from this system are:

  1. Animators control movement. No more "sliding foot" while walking.
  2. The animation has now a physical representation, it collides against stuff, and stuff (i.e. a wall) can prevent us from walking further through it
  3. Certain animations can be very complex, going forward, backwards, left, right; everything done within the modeling application, no scripting or special tools required.


[size="3"]Procedural animation

Back to the character I am working now; it's animation uses a python plugin I've found over Blender forums (noise constraint 1.1) which is awesome. It is applied to carefully selected bones for a more natural animation; since it keeps these bones always in motion. Human beings, even when we try hard to stand still, are still moving, shaking perhaps if we tense our muscles.

This plugin is always active, which means that by just not moving a single bone, I get a very natural looking idle animation. Plus, the hair's motion looks awesome.

I had to enhance the plugin though, to make it loop-able. The original script meant that even the same keyframe at start and end would not match, which is terrible for walk, run and idle loops. The script now uses an advanced technique developed by fellow GD.Net member using an imaginary plane to loop as a circle, using time as a parameter, and animation's length to determine the circle's radius. I believe this is a much superior way of generating seamless noise than the traditional methods, though with a few disadvantages.

The main drawback is that I have to save (and keep it updated, it's automatically generated on-demand, though) a text file inside Blender which keeps track how long each animation lasts, as Blender doesn't provide any straightforward way to get the "Action" length; and finding it in real time every moment the constraint is evaluated hurts performance badly. FPS went down from 60 to 5 fps; by using this file as a cache, FPS went back to 60. cPickle is teh best thing evar1 :)

For anyone interested the script is attached in this post. I won't be explaining how to use it, figure that out yourself. I'll just warn you that you need to set two keyframes at different frames. One to tell Blender the constraint needs to updated constantly, the other one to avoid a division by zero because the time length is 0. If a division by zero happens, delete ActionsNoise.cfg from the text editor and hit refresh in the constraint options to reenable the plugin again.


[size="3"]Walk animation

As for the walk animation, female walk must look sexier and softer than a male's walk. Seeing fashion model runways is a good reference. The hips swing left and right while balancing part of the body in the opposite direction, and the leg from the hip going up goes forward. The other leg should be aligned (not completely) with the leg on the front. Male walk on the contrary, doesn't align the legs much, they move mostly side by side. One must be careful not to make the butt movement too exaggerated, otherwise it goes from looking sexy to being vulgar. There's a fine line, sometimes difficult to tell which side is your animation standing.

01.jpg 02.jpg
Showing the walk animation in different stages

[size="3"]Dead eyes, dead character

Although the new mesh looked a lot better than the old one, when it was put into the game engine I couldn't stop feeling there was something huge missing. It was, for some reason, still as bad as the old one. What was wrong? This new model had more vertices, it's bones were in constant motion, the topology allowed better rigging, the animations were more detailed and this model had two bone weights per vertex while the other one had one.

And I discovered it by chance. What surprised me most is that it's a problem I've heard and thought millions of times, and still I forgot and made the same mistake: the eyes.

That's where our focus is. My thought was that if I kept the eyes still and then move it slightly over time it would mimic real life behavior. I couldn't be more wrong.

I happened to use an IK Target constraint on both eyes. Then it magically changed:

  • Mistake N? 1: Even when we get our eyes still, they're focusing onto something, this means their vision overlaps at some point. Our two eyes aren't parallel. In some cases it's less than a few degrees, but we still truly notice such subtlety.
  • Mistake N? 2: Our eyes aren't in constant motion because we look everywhere; they're in constant motion because we move all the time while we're trying to focus into one single place.
    I tried using IK target for the eyes in the old model, but it didn't look good because the eyes had a few problems (when rotating, the eye sphere went "through" the skin). The missing IK target led to mistake N? 1.

    Furthermore the old model wasn't in constant motion, which led to mistake N? 2.

    The only problem with this IK Target is that I have to be wary all the time to keep the target in place according to the animation, otherwise the eyes spin around or the look in her eyes feel like those from a crazy murderer. Parenting the target to something like the head's bone could have solved it, but then we fall into mistake N? 2 again, as the eyes stop trying to focus into a single point anymore.

    Note we don't focus on the exact same spot all the time, so be sure to make sudden changes from time to time (i.e. shift left, then right back)

    My nose itches!

    This isn't an exorcism, right?

    After IK Target was added, the character just came to life. The change was just abysmal.

    [size="3"]Reusing, reusing, reusing

    Given Distant Souls is slightly ambitious, reusing assets is essential. This rig has been prepared for easy IK (the old rig had lots of problems when IK was on) and most animations will be reused in many characters from now on. That's what Naughty Dog did in Uncharted. I am being very careful not to make any mistakes while doing this "template". Having done one before helped me learn a lot of mistakes. And I'm most likely still doing some which I won't see or be able to fix until I'm more experienced.

    Some animations will be tweaked or modified to avoid monotony and give main characters it's own personality, a few animations can't be reused for obvious reasons (i.e. male characters won't use female's walk animation) and the only animations that will be unique are attacks, combos, and spell castings.


    [size="3"]New hair shader

    I finally got some time to implement Scheurmann's hair rendering algorithm. IMHO, my version doesn't look as awesome as in the paper, but still a major improvement over the grey hair. Note the screenshots attached are a bit old, the hair has slightly been improved by using better noise textures. The eye brows are now darker, brownish (not shown in the pictures). I wanted to look them like true eye brows by using alpha blended hair strands with this new shader, but it looked terrible. This brownish colour outlines better the eyes, I like how it ended, not as photorealistic as I originally planed, but still I'm not after 100% photorealism (plus, I want some artistic freedom). I'll leave that to the big budget titles who want it.




    Well, that's all for today; I'll leave you with more screenshots, and the perlin noise script as I promised. Next time I'll be adding a new animation to withdraw the weapon when entering a fight. Completely unrelated, I'll be taking a very difficult exam this friday (lasts from 6 pm to 10:30 pm!!) so wish me luck; the better I perform, the more time I'll have to focus on the game!

    Dark Sylinc



    [source lang="python"]#BPYCONSTRAINT
    PyConstraint template, access this in the "add constraint" scripts submenu.
    Add docstring here

    import Blender
    from Blender import Draw, Mathutils, Noise
    import math
    import cPickle
    import string

    This variable specifies the number of targets
    that this constraint can use

    PI = 3.1415926535

    #Action data is saved and then reloaded otherwise performance goes waaaaay down.
    def calculateActionLength( action ):
    """Updates firstKeyFrame and lastKeyFrame considering the current IpoCurves.
    firstKeyFrame = None
    lastKeyFrame = None
    ipoDict = action.getAllChannelIpos()
    if ipoDict is not None:
    # check all bone Ipos
    # ipoDict[boneName] = Blender.Ipo
    for ipo in ipoDict.values():
    if ipo is not None:
    # check all IpoCurves
    for ipoCurve in ipo.getCurves():
    # check first and last keyframe
    for bezTriple in ipoCurve.getPoints():
    iFrame = bezTriple.getPoints()[0]
    if ((iFrame < firstKeyFrame) or (firstKeyFrame is None)):
    firstKeyFrame = iFrame
    if ((iFrame > lastKeyFrame) or (lastKeyFrame is None)):
    lastKeyFrame = iFrame
    if firstKeyFrame == None:
    firstKeyFrame = 1
    if lastKeyFrame == None:
    lastKeyFrame = 1

    return [firstKeyFrame, lastKeyFrame, lastKeyFrame - firstKeyFrame]

    def saveActionsData():
    actionsDict = {}
    arm = Blender.Object.Get('Armature')
    act = arm.getAction()
    for act in Blender.Armature.NLA.GetActions().values():
    actionsDict[act.getName()] = calculateActionLength( act )

    # Save all actions data to a Blender text 'ActionsNoise.cfg'.
    textName = 'ActionsNoise.cfg'
    # Remove old configuration text
    if textName in [text.getName() for text in Blender.Text.Get()]:
    oldSettingsText = Blender.Text.Get( textName )
    Blender.Text.unlink( oldSettingsText )
    # Write new configuration text
    settingsText = Blender.Text.New( textName )
    settingsText.write('This file is automatically created. Please don\'t edit this file directly.\n\n')
    # pickle
    settingsText.write( cPickle.dumps(actionsDict) )
    except (cPickle.PickleError):
    print 'Couldn\'t pickle actions\' data!'

    def loadActionsData():
    # Load all actions from a previously saved Blender text 'ActionsNoise.cfg'.
    textName = 'ActionsNoise.cfg'
    actionsDict = {}
    if textName in [text.getName() for text in Blender.Text.Get()]:
    settingsText = Blender.Text.Get( textName )
    # Compose string from text and unpickle
    # unpickle
    actionsDict = cPickle.loads(string.join(settingsText.asLines()[2:],'\n'))
    except (cPickle.PickleError):
    print 'Couldn\'t unpickle actions data! Regenerate the file in the settings file!'

    return actionsDict

    This function is called to evaluate the constraint
    obmatrix: (Matrix) copy of owner's 'ownerspace' matrix
    targetmatrices: (List) list of copies of the 'targetspace' matrices of the targets (where applicable)
    idprop: (IDProperties) wrapped data referring to this
    constraint instance's idproperties
    def doConstraint(obmatrix, targetmatrices, idprop):
    # Separate out the tranformation components for easy access.
    obloc = obmatrix.translationPart() # Translation
    obrot = obmatrix.toEuler() # Rotation
    obsca = obmatrix.scalePart() # Scale

    # Define user-settable parameters. # Must also be defined in getSettings().
    if not idprop.has_key('u_loc'): idprop['u_loc'] = 1
    if not idprop.has_key('u_rot'): idprop['u_rot'] = 0
    if not idprop.has_key('u_scale'): idprop['u_scale'] = 0
    if not idprop.has_key('u_locamount'): idprop['u_locamount'] = 1.0
    if not idprop.has_key('u_rotamount'): idprop['u_rotamount'] = 30.0
    if not idprop.has_key('u_scaleamount'): idprop['u_scaleamount'] = 1.0
    if not idprop.has_key('u_speed'): idprop['u_speed'] = 1.0
    if not idprop.has_key('u_seed'): idprop['u_seed'] = 1.0

    la = idprop['u_locamount']
    ra = idprop['u_rotamount']
    sa = idprop['u_scaleamount']
    noise_speed = idprop['u_speed'] * 0.001

    arm = Blender.Object.Get('Armature')
    act = arm.getAction()
    actionDict = loadActionsData()
    if not actionDict.has_key( act.getName() ):
    actionDict = loadActionsData()
    myAct = actionDict[act.getName()]
    time = Blender.Get('curtime')

    radAngle = ( (time - myAct[0]) / myAct[2] ) * 2 * PI
    # Keep the noise always starting at (0,0) by displacing the circle. Otherwise different speed parameters change the 'seed'
    # Mul by myAct[2] (anim. length) to keep speed constant for different actions
    x = (math.cos( radAngle ) - 1 ) * noise_speed * 0.8 * myAct[2]
    z = math.sin( radAngle ) * noise_speed * 0.8 * myAct[2]

    s = idprop['u_seed'] * 12.3456789
    noise_vec = Mathutils.Vector( x + s, x + s, z + s)
    rv = Noise.vTurbulence(noise_vec, 3, 0, Noise.NoiseTypes.NEWPERLIN)

    half_vec = Mathutils.Vector(0.5, 0.5, 0.5)
    noise_vec = noise_vec - half_vec

    # Do stuff here, changing obloc, obrot, and obsca.
    if idprop['u_loc'] == 1:
    obloc[0] += la*rv[0]
    obloc[1] += la*rv[1]
    obloc[2] += la*rv[2]
    if idprop['u_rot'] == 1:
    obrot[0] += ra*rv[0]
    obrot[1] += ra*rv[1]
    obrot[2] += ra*rv[2]
    if idprop['u_scale'] == 1:
    obsca[0] += sa*rv[0]
    obsca[1] += sa*rv[1]
    obsca[2] += sa*rv[2];

    # Convert back into a matrix for loc, scale, rotation,
    mtxloc = Mathutils.TranslationMatrix( obloc )
    mtxrot = obrot.toMatrix().resize4x4()
    mtxsca = Mathutils.Matrix([obsca[0],0,0,0], [0,obsca[1],0,0], [0,0,obsca[2],0], [0,0,0,1])

    # Recombine the separate elements into a transform matrix.
    outputmatrix = mtxsca * mtxrot * mtxloc

    # Return the new matrix.
    return outputmatrix

    This function manipulates the matrix of a target prior to sending it to doConstraint()
    target_object: wrapped data, representing the target object
    subtarget_bone: wrapped data, representing the subtarget pose-bone/vertex-group (where applicable)
    target_matrix: (Matrix) the transformation matrix of the target
    id_properties_of_constraint: (IDProperties) wrapped idproperties
    def doTarget(target_object, subtarget_bone, target_matrix, id_properties_of_constraint):
    return target_matrix

    This function draws a pupblock that lets the user set
    the values of custom settings the constraint defines.
    This function is called when the user presses the settings button.
    idprop: (IDProperties) wrapped data referring to this
    constraint instance's idproperties
    def getSettings(idprop):
    # Define user-settable parameters.
    # Must also be defined in getSettings().
    if not idprop.has_key('u_loc'): idprop['u_loc'] = 1
    if not idprop.has_key('u_rot'): idprop['u_rot'] = 0
    if not idprop.has_key('u_scale'): idprop['u_scale'] = 0
    if not idprop.has_key('u_locamount'): idprop['u_locamount'] = 1.0
    if not idprop.has_key('u_rotamount'): idprop['u_rotamount'] = 30.0
    if not idprop.has_key('u_scaleamount'): idprop['u_scaleamount'] = 1.0
    if not idprop.has_key('u_speed'): idprop['u_speed'] = 1.0
    if not idprop.has_key('u_seed'): idprop['u_seed'] = 1.0

    # create temporary vars for interface
    uloc = Draw.Create(idprop['u_loc'])
    ulocamount = Draw.Create(idprop['u_locamount'])
    urot = Draw.Create(idprop['u_rot'])
    urotamount = Draw.Create(idprop['u_rotamount'])
    uscale = Draw.Create(idprop['u_scale'])
    uscaleamount = Draw.Create(idprop['u_scaleamount'])
    uspeed = Draw.Create(idprop['u_speed'])
    useed = Draw.Create(idprop['u_seed'])
    udataFile = Draw.Create(1)

    # define and draw pupblock
    block = []
    block.append(("Speed", uspeed, 0.0000001, 1000.0, "The speed of animation"))

    block.append(" ")
    block.append(("Location", uloc, "Randomly modify the object's location"))
    block.append(("Amount", ulocamount, 0.0000001, 1000.0, "The amount of location randomness"))

    block.append(" ")
    block.append(("Rotation", urot, "Randomly modify the object's rotation"))
    block.append(("Amount", urotamount, 0.0000001, 1000.0, "The amount of rotation randomness"))

    block.append(" ")
    block.append(("Scale", uscale, "Randomly modify the object's scale"))
    block.append(("Amount", uscaleamount, 0.0000001, 1000.0, "The amount of scale randomness"))

    block.append(" ")
    block.append(("Seed", useed, 1.0, 1000.0, "Use a different random value "))

    block.append(" ")
    block.append(("Generate File", udataFile, "Do this each time you've created new pose actions or modified it's length."))

    retval = Draw.PupBlock("Noise Constraint", block)

    # update id-property values after user changes settings
    if (retval):
    idprop['u_loc']= uloc.val
    idprop['u_locamount']= ulocamount.val
    idprop['u_rot']= urot.val
    idprop['u_rotamount']= urotamount.val
    idprop['u_scale']= uscale.val
    idprop['u_scaleamount']= uscaleamount.val
    idprop['u_speed']= uspeed.val
    idprop['u_seed']= useed.val
    if udataFile:
Matias Goldberg
I come from a programmer's background. I've always been interested in 3D graphics, paying a lot of attention to the details. A description that probably fits me best is technical artists: someone who increases the quality and looks/appearance of the work by writing new shaders, doing some fancy math, procedural stuff, writing 3D tools (viewers, editors, etc)


Therefore, I'm quite surprised to find another side of me, much more artistic than technical. It's still a far cry from experienced and talented Cg artists out there, but it isn't your regular "programmer art" either.

There's a lot of art influence in making a game look good, rather than the tech. Often an underestimated job by noobs (and not so noobs). Just a look at CryEngine 3 Licensors' showcase, they're all running the same engine, even though it doesn't look like; and none of them gets near Crysis 2 (this doesn't mean tech isn't important!)


Well, I'm mainly modeling in Blender. Took me a long time to master, but it's the ultimate tool for techies like me. Unlike Maya or 3DS Max, Blender allows moving, rotating and scaling by input values on the keyboard, and very quickly! Hotkeys, once you've learned them, boost productivity a lot. Furthermore, it behaves more like a game engine than Maya. There are a lot of disadvantages as well, but Blender is right for me, and fits my budget (it's free!); I can't live out of free trials.

These tutorials helped me to start out with human modeling a lot. It introduced me to the concept of edge flow in Cg human anatomy.


The images show a character I'm currently developing. Her identity is going to be kept secret, which is why her filename was removed from it. No, she's not one of the main characters. Note the first picture is a viewport capture from Blender.

The hair currently has a basic shader, and isn't supposed to be white. I'll be taking care of it later. I'm planning to use Scheuermann's hair rendering technique for rendering characters' hair in Distant Souls.


Each model is improving over the last one (which means at least there's something I've learned!) which is why I didn't start with the main characters first.

I've modeled and rigged her with reuse in mind, the plan is to use sculpting tools, a few scripts, and poly editing to reshape her into other models, including males. Then re-texture.

This model has around 13.678 vertices, compared to the first model's 5.331 verts. Animations are a lot more fluent, running a side by side comparison in Ogre Meshy makes an astonishing difference, probably because the first model walks like a damaged Terminator from the first movie.

Also shading was finally tweaked since it was too shiny, it's a lot more matte now. The dress' material still needs tweaking as it is too shiny as well, it's supposed to look like silk, but currently looks like leather or plastic. To make it look like silk, the shader has a special feature which allows very flexible lighting tweaks, including some anisotropic.

Part I covers an introduction of the new character.

Part II will cover animation of the mesh in Blender, among with more full-body screenshots. If you have a critique, spill it out. Better hurt my feelings than having a boring game ;)

Until next time

Dark Sylinc

PS. If you're a talented 3D environment artist or animator and want to join the team (even part time), feel free to drop me an email to dark_sylinc [at] yahoo [dot] com [dot] ar
Matias Goldberg
Time to start a Journal

First post on GD.Net Journal! Wooohhooooo!!

I'm going to use this space to start talking (majorly) about the develpment of my new game, Distant Souls. Mostly these will be repost from that blog, occasionally providing exclusive content :)

Why I'm starting this you may ask?

Well.... two reasons:

  1. Our beloved Ninja (Drew Sikora) loves gorgeous pictures in his Weekend Journals, and I have my hopes he will like the content I'll be posting here. It is my intention to fulfill his thirst! My intention is to do the same Danny Green did (quite an inspiration to me, shall I add) by spamming zillions of images and updates about the game's progress . Besides it's been a while since we enjoy his site since he signed the deal (which is understandable, but we miss it!). I'll try my best to submit quality content
  2. Attention! GD.Net gives the blog a better audience and reach, not to mention a better opportunity to get critique.

Last but not least, guys like Danny Green (from Radioactive Software) and flash animator Mark Haynes (aka Alvin Earthworm) have been of great inspiration for me, they don't stop amazing me how much a single person can do, breaking the limits of what seemed possible. If they can do it, I will too.

Let's leave with a high quality forest screenshot for now. (click to enlarge).