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.
Saturday, October 20, 2012
Sunday, August 19, 2012
Updates
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:
- 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®, 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.
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
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
DOWNLOAD DEMO!
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:
There's a DEMO AVAILABLE FOR DOWNLOAD!!!
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!
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.
Therefore, it's disqualified.
Now let's change the subject:
There's a DEMO AVAILABLE FOR DOWNLOAD!!!
GO CHECK IT OUT!
- MEDIAFIRE: PART I, PART II
- DROPBOX: SINGLE FILE.
- IndieDB: SINGLE FILE
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?
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.
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".
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)
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.
But if it is, then investments aren't taxed. The moment the investors pay their revenues varies wildly per country. Normally, variations include:
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:
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.
Cheers!
Don't forget to subscribe!
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.
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.
Cheers!
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:
- 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.
- 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.
- 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.
- 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
Subscribe to:
Posts (Atom)