In short, the video’s statement is that the high cost of cars in Brazil is not really due to high taxes, but to profit margins from car dealers. This conclusion comes from the fact that although car taxes are high, they’re not a significant part of it’s  end price. At a first glance, this seems legit, since we’re comparing the proportional price of taxes over the car’s total end cost. With that said, I will now discuss in this post why I believe that analysis is incorrect and attempt to prove that taxes can have a huge impact in a product’s end sale value.

You see the percentage of taxes over a products end price is misleading. Saying that 10% of taxes on a $10.000 car will not change it’s end price significantly enough to impact it’s sales is an insufficient analysis of this problem. What’s necessary is in evaluating the buying capacity of the market, and the segments in which it divides itself. Here’s a simple example, from a hypothetical country Foo :

Foo’s citizens can be described in the above market segments, where each has a corresponding buying capacity for a car. This means if a car costs $3.000 then all users can buy it. But if it costs $8.000, then only users B and A can afford to buy it. The key component here is the margin in which a user can buy something, since all off them have one.

If you don’t believe so, think the last time you went to a store to buy something. You said to yourself you would only spend at most $80. However the product’s cost was $100. After pondering for a while you still decide to buy the product. Now you could think you over spent your initial budget, but that’s irrelevant. What really happened is that you spent within your buying capacity. It’s not that you will buy a product if and only if it costs less than $80 — you will buy it if it’s within a bound.

Since users can then afford to spend their money over the same object — a car — what the market then attempts to do is two things :

• First it tries to create products for each user segment. There will be specific car brands for each user segment.
• Second, and here’s a key factor here, the market will try to sell these car brands at the top price for each user segment.

To understand the second bullet, think of it this way. Suppose car brand #4 is geared towards the low income individuals — namely users D. The market will then try to sell car brand #4 the closest possible to $5.000, since it knows that users D can afford it. In short, the market will diversify itself to reach out to all potential user segments, and maximize it’s profit margin as much as possible within each user segment.

It’s under this point of view that taxes become a crucial factor in a car’s end price. A reasonable thing to do is to keep car taxes in a way that the end cost of a car’s brand will still be under it’s original user segment buying capacity. Here’s an example — suppose car brand #4 costs $4.000. With a 10% tax rate it’s cost will bump it to $4.400. Under that price car brand #4 will still be withing users D buying capacity. However if the tax rate is 30%, the end price will be $5.200. What happens then is that car brand #4, which was targeted for users D, can now only be bought by users C and above.

This is specially problematic since this “car brand bumping to the next user segment” effect spans the entire chain, as it can be seen in the diagram below.

However, as previously stated, we cannot forget the fact that the market will attempt to maximize it’s profits by making the products they sell to be as close as possible to a users buying capacity. So the net effect isn’t simply that car brands bump up in user segments — their prices bump to the maximum value of that user segment as well.

So what ends up happening is that under 10% tax rate, car brand #4 will on average be sold for $5.000. However under 30% tax rate,  it will not be sold for $5.200 – it’s average price will be $7.500, over half as much as before.

It’s important to highlight this since the high tax net effect doesn’t affect only cars — it affects all products, games included. Over the last few years, with specialized distribution models such as Steam, and with the advent of new user bases such as the casual market, games prices per user segment have become dramatically important. Via this, an entire matrix of users buying capacity per product has been established in the gaming industry. There’s bundles of games per discounts, daily games per $0,99, DLC averaging from $5 to $30, and so on. All sorts of combinations, trying to cater to each specific consumer market.

There’s a large set of consumer products under the $10 range. Gamers view a one dollar game sale in a completely different way than they do if it costs five. Proportionally, four dollars won’t have a significant impact in someone’s life, but it’s irrelevant — this discrepancy exists and users react to it.

It’s under this scenario that high tax rates are especially problematic. If taxes bump games prices up, than the entire portfolio of user products per market segment gets whipped out. A $10 tax rate on any external game, even though it’s quite small, simply abolishes the low cost game market.

Thus we need to understand that tax rates impact not only the end product’s price, but the whole net effect of what it does in the market as a whole. Simply put, high tax rates makes cars incredibly more expensive and cripples the low to mid-tier game development community.

Download link: vtool (96)

I managed to add three basic functionalities to this editor that I wanted. The first is the ability to move freelly through it’s space, without any scope restrictions. In the Solis editor when you create a new map you set it’s width and height and it remains static. It didn’t really bother me at first, but it’s something that every now and then reduced my design.

The second was the ability to zoom-in/zoom-out freely in each window without any restrictions. Using the mouse wheel you can easily do that. I still need to make the editor center on where the mouse is as it zooms though.

The third is the ability to easily scroll through the map. That’s something I did have in the Solis editor and wanted to have in this one too. Just press and hold the right mouse button and you can move around the map.

To add walls to the world just left click and move the mouse. Left click again and the wall is set. On the next release I hope to have some basic editing functionalities like selecting walls, editing and deleting them, copying and pasting.

Again this project is open to community feedback! Send me an e-mail on what you think about it!

Until then!

However I do intend to make things different this time. You see all my other projects I would only talk about them once they were done. This time though, I intend to talk openly about it through out it’s development.

It’s not that I like to keep things secret. It’s that I always worried about becoming something I usually criticized: talking more about a game than developing it, and in the end have tons of rambling about a never finished project.

But now I think I can go beyond that point since I at least proved to myself I can get a project done, regardless of how much I talk about it or not. So my intention with this new project is to do at least a weekly post about it, displaying how it’s current development is going. And it doesn’t matter how simple or stupid the project is going thus far, the point is talking about it. Don’t really know why, I guess I’m trying to make a social experiment out of this thing,  just to see what happens in the end.

Anyway here is a picture of how the “editor” is going.

To download:  vtool (80)

Basically I intend to do something where you can have multiple windows showing multipler things about whatever you’re editing. I’ll start focusing on that once I get the gist of the toolbars and rebars going.

As a book that concerns itself with software engineering I say it does the job. It’s an 800 page beast covering topics from UML, resource management, project risks, stipulations and damage control. More interestingly enough it tries to tie that with actual game development. It goes quite in-depth in each of it’s topics and gives plenty of further references if any particular one interests you. Overall it’s a good book.

But that’s not really what I want to discuss about.

You see, the book comes with a game a small team of developers made using a variety of software engineering techniques. This serves to show how one can apply them into game development. The game is quite stable, performing well given the myriad of things attached to it (3d mesh loading, textures, events, GUI, scripts, etc). However there”s just one problem with it:

It’s not really any fun.

Now I’m sure the goal of the book  is to teach software developers techniques they can use in their own development, with the game being fun not a pre-requisite in this scenario. It had to be functional, not fun.

That’s one of the things game development as a software differs from others. If a program manager assumes that a project will take:

• w hours of development
• take y developers to develop it
• cost z dollars
• have k use cases

And it ends up taking exactly that, most likely that was a successful project.

The problem with game development is that even if you manage to make a game with all your estimates correct, if the game in the end is not fun than you still have an unsuccessful project. Sure it can still sell well, but it’ll probably take tons of marketing to make up for it.

Some could say that fun is a non-functional requirement, which is true. However it undermines it’s importance into the actual game development process. Sucesfull game companies have long realized this and build entire systems of software enginnering whose sole goal is to enhance and facilitate adding ‘fun’ to a game.

Valve software uses their CABAL system, ID software with their endless internal engine prototypes, Blizzard with their QA tests, and so on.

Which leads me to conclude:

Sometimes the most important aspect of a project cannot be expressed in a process or in a form. That is still not a justification to leave it out off processes and forms.