Saturday, October 20, 2012

How to enable UV correction when using Loop Cut in Blender 2.6x

While I was working with Blender a few days doing the light volume data for the flaslights; I've noticed that in Blender 2.49 Loop cut kept the UVs correct, while in Blender 2.6x it gets stretched. This was annoying. Even after downloading Blender 2.64a, I saw this problem still persists.

A quick google returns a cryptic solution saying that it's not a bug and can be turned on & off. Because I prefer visual solutions, here's how to turn it back on:

Go to the User Preferences (Ctrl+Alt+U; alternatively "File->User Preferences..."), then to the Input mapping options:

 Then find the "Loop Cut and Slide" key binding:
Open it and make sure "Correct UVs" are checked. You're done :)
Quick fix to a very annoying problem. I hope this visual description helps a lot more than that cryptic message over the bug tracker.

Note that apparently there may be a rare bug in which Correct UV may completely screw up your UVs which may be the reason the default was changed to unchecked in the first place. That seems to be something much harder to solve and the developers are working hard on fixing it. Keep an eye if that happens to you. You've been warned.

That's all for today! Have a good day. Now back to work.

Sunday, August 19, 2012


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 :)

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

Sunday, June 24, 2012

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:
  1. 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?
  2. A lot of animation data was in this boss. Therefore the physics need to interact accordingly.
  3. 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.
  4. 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.
  5. 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.
  6. 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®, even though I've never played it. So, I started to watch more Youtube videos about SotC, God of War III®, and Castlevania: Lord of Shadows®, 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)

Phantom inside the shell to prevent getting inside

  • 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.
  • 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.
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

Tuesday, May 22, 2012


First, there's bad news: Distant Souls failed to run on the spec. machines from Intel Level Up contest! :(
Therefore, it's disqualified.

Now  let's change the subject:


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)

Ways you can help:

  • Share! Follow! Subscribe to my videos :)
  • 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!

 Posted Image
Posted Image

Posted ImagePosted ImagePosted Image
Posted ImagePosted ImagePosted Image
Posted ImagePosted ImagePosted Image

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.

Saturday, April 7, 2012

Crowdfunding... and taxes???

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 games 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!

Monday, March 19, 2012

Demo finally submitted to Intel Level Up contest!

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.
Don't forget to subscribe!
/crunch mode: off