If I were a farm owner and wanted you to create a machine that sorted the bad potatos from the good ones, what would you do?

Seemed like a simple task so I thought about it for a few seconds. Initially I imagined a device that would take pictures of the potatoes and perform image processing queries on them. These queries could then figure out if there were any fungus or odd shapes in the potatoes.

When I told this to my father he laughed. He said: just throw the potatoes in water. The ones that don’t float are the bad ones.

Now this is a very simple example of an issue that I think rises with a lot of development and engineering teams. You see, had you had asked that question to an electrical engineer he might have thought if the current that passes in bad potatoes is different than in the good ones. A mechanical engineer might have thought about the weight difference between the potatoes, and so on.

People tend to face problems from their technical backgrounds, which is not particular a bad thing, but it is important to be able to extend to other areas of knowledge, even trivial ones. Had any of those engineers had asked a cook about the potato problem, they would have probably had the best answer.

And to me that’s the crucial point here. I think a lot of projects fail because people fail to assume some other realm of knowledge might have a better understanding of the problem they are facing. They assume they can ‘deal with it’ and in the end, all they get is a bunch of bad project decisions and thus, bad potatoes.

I pretty much disagreed with most of the things he said, but he did say one thing that struck me as true and it’s pretty much the only thing I took with me from his classes. He said:

An artist writes how he feels and how he feels is a direct consequence of the environment he finds himself at.

In other words an artist’s background, culture and the society around him influence his artistic views. Makes pretty much sense doesn’t it? But people usually apply this to writers and the normal standard of an artist. The catch is that it affects all creative thinkers, this includes engineers and software developers as well. Here’s an example.

Every now and then I read some article comparing the PlayStation 3 architecture with that of the Xbox360. Makes sense since they were both platforms developed to handle massive amounts of data. Usually those comparisons involve a instruction/triangle/frame/shading per second/pass view or how the 6 synchronous SPU cores compare with 3 asynchronous cores.

It’s all quite interesting, since for on one hand you have an architecture that’s basically massive raw power, running at the highest possible clock speed, with tons of ram. Big and bulky American muscle. On the other side you have a series of smaller cores, that require a more ellaborate design, streched throughout each individual node. Less but more refined, efficiency through group effort. When I see these sorts of things I think of only one thing: Motorcycles.

You have the classic American choppers, big bulky American muscle. Lots of fuel, big engine cylinders, raw power per torque. Made to last.

And then you have the Kawasaki’s lines. Less fuel per cycle, more refined in it’s architecture. Made to run fast.

Each of those types of Motorcycles present its ups and downs. With one you can go from coast to coast and back again. The other you can only go from one to state to the other but at top speed. They’re the same type of vehicle but the catch is that they were designed by engineers of different nationalities.

I’m not trying to throw the cliche dilemma of East vs. West here because I see it more as a general social example. Both engineering teams were given the same task: built me a motorcycle, but their final product is obviously different in terms of style and scope. To me a big part of it is that both teams had different cultural backgrounds, were in different societies and had thus different views on how to solve the same problem.

I think the same happened with the Xbox 360 and ps3 teams. Both had the same task: build me a video game, and the final product is obviously different.

Both systems have it’s ups and downs but the point I’m trying to make is that I think an ideal developer/engineer would be able to go beyond his cultural heritage and be able to reach the same conclusions the other team had, and in the end make the best overall decisions.

Generally I think a good artist is not bound by the limitations he found himself at. He is able to roam freely from it and create an art that doesn’t speak to only those individuals in his current social realm, but to all individuals. To me a good artist is universal in his approach of seeing and making art. As James Joyce put it brilliantly:

When the soul of a man is born in this country there are nets flung at it to hold it back from flight. You talk to me of nationality, language, religion. I shall try to fly by those nets

I think it’s a beautiful quote and strikes at the core of that which I spend so much time thinking about. Joyce is a relly good read, though unfortunally I don’t think my Literature teacher would read him.

At least you understand now why I disagreed with him so much.

He initially used to wide of an angle to try to get into the parking spot, so after maneuvering the car in, he kept moving back and forth, trying to adjust the cab to the right spot. Unfortunally, since his initiall angle was so wide, no matter what he did he could not get the car close enough to the curb.

He kept going, back and forth for at least 2 minutes, until finally he moved the car completely out of the spot, took the right angle , and managed to fit the car perfectly in the parking spot this time.

Now I don’t know about you, but when I saw that I thought : “That’s a perfect software enginnering metaphor.” And indeed it is, heres why.

You see the vast majority of software managers when trying to do their job, aka manage software development, they usually list the things they should estimate: functional requisites, prototype, develop code, refactor, etc. They usually forget one simple and yet crucial thing:

You will throw code away.

Every software that’s used requires maintanance. Maintanance requires to increase or change the scope of software. As you do that, previous software under that new scope doesn’t function or isn’t the best for that system. They have to re-write things, start again, but with the new goal in mind.

But software managers usually don’t like the sentence “Throw code away”. It implies an idea of waste of time, or that any system can be adapted, it’s just a matter of figuring out how.

Those managers are doing exactly what that taxi driver was trying to do. Going back and forth with their code, hopeleslly trying to get their software/taxi in the right spot. They never will, and regardless of how many factors point to it, they won’t admit they’re bad drivers. To them the car will eventually set in the right spot, while in reality they should restart the parking procedure as a whole.

Those usually are bad managers, ones that I try to avoid. If they can’t park a car right, how the fuck do they plan to manage software development?

Download link: vtool (3)

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!

Try it out, what did you like and dislike?

Tell me what you think!

Until then!

In some ways I feel ashamed to say that I ‘read’ it because it’s a behemoth of knowledge spanning over 1200 pages. Of course I learned a lot from it but it’s the sort of book I’ll read again and again and again until I can finally grok it. It’s a collection of over 10 years of Abrash’s papers and I doubt one can absorve it in a matter of months.

You see to learn programming concepts in a self taught manner I think it’s crucial to not only read the code in the book, but also write it down, play around with it, to truly understand what is being taught in its finer details. With my current project I intend to do just that, since it’s a FPS and the last chapters on the book concern directly with Quakes development at id Software, where Abrash worked.

What’s more interesting is that the author doesn’t focus only in the development aspect of programming, but in the general mentality of it. Not as one solves a problem, but the mind that solves it. As you become better in development I think you ask yourself less “how to solve this problem” but more of “what is the best way to solve this problem”. Abrash shows us several ways to solve a problem in the book, be it linked lists, spatial visibility or making a faster game of life, each one consistently faster than the other with either assembly optmizations, algorithm optmizations or rethinking the whole approach to the problem. The idea is to not expect that there is only one way to handle an issue. In his own words : “Assume nothing”.

The book is also quite pleasant to read, since the author narrates the development cycle more as a journal than a tech book. It’s quite interesting to read the last chapters where he focus on making a faster rendering back-to-front polygon rendering approach to Quake. Almost goes like this:

March 14, 1941. We begin our approach to the BSP tree, were still having heavy losses on how to figure out a way to make the spatial visibility problem faster. The worlds we want with Quake  feature at least 5000 polygons and in the worse case scenario we redraw each pixel 5 times. It’s too slow, we must take a better approach.

May 22, 1941. We sucessfully managed to create a potentially visible set (pvs) that managed to break into enemy lines. We will now proceed to use it to flank their defeneses.

June 10, 1941. We have now conquered the enemy’s battlefield. I’ve reduced the inner loop of the rasterizer to 2.5 cycles per texel. We decided to use z-buffering for drawing the enemy meshes, since it’s faster and not that big of a problem as we expected. Victory is eminent.

And so on. Overall the book can be divided into 3 parts:

• General assembly optimization techniques
• 3D rendering done via software
• Common 3D engine development problems and solutions.

I recommend it to anyone that’s interested in taking game development or programming in a seriously yet elegant manner. I learned a lot from it, and still intend to learn more.

Download here: vtool (7)

Didn’t manage to get as much work done in the editor as I wanted to (kind of a busy week), but I did manage to put in some details that I wanted. The opengl windows now resize themselves as the master window gets resized and I added an automatic resize button. It only works though when the number of windows is a perfect square: 1,4,9,16… Still trying to figure out how to handle the non square situations. I think i’ll do a drop down menu with several choices you can choose.

The top menu now is a rebar also. That means the user can position them as he wishes. I prefer that sort of design more than toolbars because users generally have their own work preferences.

My long term goal with this project is to have a very flexible editor where the user can edit in any way he feels comfortable with, and to achieve that it needs to be as customisable as possible. Ideally I see the user being able to have an environment with windows where he interacts with the “game world” in many ways. For example he can have one master window that sees the world on top where he can edit it, and two sub-windows where he can see on-sight how those changes are ocurring. If this system is robust enough he can change that to any way he wants.

I’m heading towards that sort of design because I think one of my flaws in designing both the Solis and World Train Royale editors is that they gave no artistic freedom for the user. I see artists messing around with Photoshop and they all have their preferences and designs they call their own, not Photoshop’s in itself.

By the way I still don’t know how to properly name this project. Anyone got any suggestions? Also I would like to get people’s feedback on the project. So if you were to use an FPS editor, what sort of features would you want to have in it?

Anyway I guess that’s it for now. My next goal is making the editor more interesting, so I’ll be adding level building next. Until then!

Today I’d like to keep talking about that but focusing more on the technological nature of that which is being developed. Here’s a short story to better explain why:

While I was working on Conira, early on I decided just for the hell of it that this game would be multithreaded. Given my previous experience developing the Solis engine I saw that you could dissect the game engine into three threads.

1. One that renders all the objects in the game, be it sprites, particles or models. This thread uses the ‘get’ methods each object had.
2. Another that updates all the objects in the game, their displacement, acceleration, hit detection, etc. This thread uses the ‘set’  and ‘get’ methods each object had.
3. One thread that takes care of loading/unloading objects and handling the Operating System calls like windows and messages.

Initially I thought this would be a good design. I elaborated on how the threads would communicate, tried to figure out and reduce potential deadlock /livelocks and set off to code!

It wasn’t but one day later that I had to redo the whole design.

You see there is a technical limitation when dealing with rendering systems, threads and the Win32 specification. MSDN clearly states that “the same thread that RENDERS the objects MUST be the same thread that CREATES the WINDOW and handles its OPERATING SYSTEM calls.” In other words, thread 1 and 2 had to be same. In the end it wasn’t a big alteration, meerely trivial given the design I had but it did bring me into re-thinking certain software engeneering practices people take for granted.

When I was in college I was basically told that “code development is a final product of a series of design decisions”. You figure out your system first, its classes, structures, layers and then the code you write is merely an extension of that. In other words, take the broad view of a project and as you develop it, handle the inner details and its intricancies as they come. But that type of methodology fails to work in development environments where those same inner details and intricancies are what actually defines the system as whole.

I think Agile Software advocates say the same thing but with different words. “Work on the code first, let the inner details of a system be delt as they come, so don’t worry about documentation, design, etc. Code, code and code!”. They also usually point cases where such methodologies worked. However they fail to point out the architecture of the system in which they developed. Most, if not all, of those success stories I heard were either web applications or with an interpreted language such as Java or C#.

Well it makes sense for those projects to work on those scenarios! They were built on top of languages where it is expected to delegate the inner details of a system to whomever is handling it. So all they have proven is that those agile methods work on those environments, which is ok, but not that agile methods work as a whole, which is what they usually advocate. Honestly, I’m yet to see an long run story of a sucessfull low level driver or high optmized high-level assembly language project using Agile methodologies.

Don’t get me wrong, I’m not saying that Agile methods suck or that they don’t work. They do and can work quite well but one must understand the context in which they work, or else failing into the trap of beliving that they work in any environment.

If one doesn’t take into consideration the end product as well as it’s internal architecture while taking enginnering decisions, he’ll end up eventually just making bad or lucky engineering.

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 (9)

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.

The e-mail I got basically complemented the game, saying he liked the style but thought it had too much text hahah. Always good to get feedback from my projects.

Solis is sort of a special project to me. It was the first BIG project that I developed and every now and then I check how many downloads it managed to get (5000+ and counting). It`s not a big project and it ain`t no RPG Maker killer but it was a fun game to make.

With this game I learned 3 very important things:

1. No matter how close you are to finishing a project you will only, and only after you finish it, be able to learn and truly take a critical perspective of it. This is the sort of thing you can’t really explain why. Basically you know why when it happens to you and after that you understand why it can’t really be explained.
2. Different games take different amount of resources. Quite obvious, but it’s the sort of issue that gets commonly overlooked. Solis was a 2D rpg game, and with it came hundreds of sprites, tiles, images, maps, sounds… The list just kept getting bigger and bigger and I was soon to find that I needed an artist.
3. Know your user base before doing the project. During halfway through developing the Solis tool set, I thought I had actually found a development niche. You see, people make RPG maker maps and images all the time, write tutorials about it, etc. But most of them use pirated versions of it. I thought an open source RPG maker would fill that need and actually be able to create a community out of it.
   Boy was I wrong heh. The RPG maker community is mostly of artists and script writers and since Solis was written in C++ that didn’t really appeal to them. Maybe if I kept investing into it I could have pulled that one off. But after such a long development process, I felt I wanted to do something else.

And I guess that`s it. There was one interesting side effect of developing this game though… and hasn’t faded yet:

I never managed to play a JRPG again. Ever. I finished Solis and could not stand looking at JRPG…. Pretty weird heh.

I would go to a new school and usually the topic of games would come up. We talked, played it for hours and generally had a good time. Games have been my companions since early on and they served me as a way to become accustomed to the new place I found myself at.

Now, usually one thing that struck me is that people, no matter where I go, would generally have the same game preferences and the same emotions and experiences as they played the same games. I did to. Every gamer remembers the first time they played a Mario game, beat a Final Fantasy, saw Ryu’s haduken and so on. These are all common experiences we have and shared.

However there are a few that pretty much everyone I know has had except me. These are my video game moments of shame. So without further ado, here is the list :

• I never finished Final Fantasy 6 nor Chronno Trigger. Only got half way in FF6 and to the final lavos battle in CT.



• Never finished Street Fighter without using a continue or resorting to using a very easy level.



• I never won a Stracraft  multiplayer match.



• I cannot for the life of me beat a Heroes of Might and Magic 3 map. I always get my ass kicked.



• Never killed a person in Counter Strike with an AWP. Ok, I hated using the weapon and everyone that used it, but still.



• Never beat a Megaman game without save states.



• I love all the point & click adventure games by Lucas Arts but I am still yet to play Grim Fandango.



• It took me almost a decade, with the same save state on the NES cartridge, to beat Dragon Warrior. I played that game to death when I was 11, maxed out my character but got stuck in the story. When I was 21 I dusted of the cartridge, got a FAQ and finished the fucker.



• I actually enjoyed playing Star Wars Shadows of the Empire.



• I own a original copy of Daikatana. Didn’t buy it but I still managed to get  copy, for free at least.

I guess that’s it for now. Quite shame full. Triple face palm.