There is good reason why he would think so. The current industry practices that relegate the player to just a user of the game is what is holding game design back. These practices treat the player more as an abstraction and design the game with a poor concept of the player in mind, often relying on demographic research from previous games. A probabilistic approach to plan recognition through Baynesian networks or case based plan recognition where case libraries are constructed by observing gameplay and the possible actions are encoded as a state transition tables, appears to be the main way game designers are imagining their players. The needs and preferences of the player while playing the game, however, have been going largely unnoticed.

To me it appears that player-centered game design is where the future is. Better player modeling along with adaptive technologies will be able to help designers communicate better with players and vice versa. It’s holds the potential to appropriate level of challenge, smooth the learning curve, and enhance the gameplay experience for individual players irrespective of their age, gender or race.

So with this post we’re beginning our foray into player centered game design. While optimistic of the rewards it holds, we’re still not expecting it to be an easy job as heaps of concerns spring to mind. Nonetheless, we’re very excited and our brains are exploding with ideas, which we’ll be sure to blog more about soon.

I must admit, it’s great! We had an awesome time with it! We were trying to assemble a small demo of a flag, for reasons known best to us You may see it [here]. Now, the unique thing about this demo is, that there’s no simulation or premade animation on the flag! The waving of the flag was achieved through code. There’s a neat function running there that procedurally moves the flag mesh directly. Everything apart from the flag is from the default Unity assets library.

I want to take this opportunity to congratulate the Unity team….amazing job, folks!

This time around, we added some rotational dynamics to our physics library. I hope you would remember our very first post about collisions. It looked something like this. You would notice that although the spheres are colliding, there are no rotations on them. That is what we have added now.

Take a look at this demo.  The spheres with bigger size have higher mass, and resultingly, higher momentum. This was obviously a long overdue and natural extension to our first post. So here it is…

We also tried the same test with gravity switched on. Take a look at it here. At a rough glance it looks okay…but it doesn’t take into consideration the point of contact of the spheres. So you would notice that they do not “roll” over each other, when their slides are against one another, deflect off edges etc. We would target that in the near future.

Do leave your comments and criticisms below. We would love to hear your thoughts!

He helped us to add a few constraints to our library. But, what exactly is a constraint?

“A constraint is a condition that a solution to an optimization problem must satisfy”. If that sounded Greek to you, don’t worry…..it sounded the same way to us as well when we started! To put it plainly, a constraint is a condition that an object must satisfy. But, that leaves a lot to imagination….on this definition, there could be loads of constraints, since the condition could be anything: stick to a wall, go round in circles, move with something, grow bigger/smaller with something, always remain perpendicular to an object, keep following something, keep repelling something…. blah..blah. Couldn’t all of these be constraints?

The answer is YES. They could all be constraints. We as of now, have around eight constraints in our library. We would keep adding more as the need arises. We were quite impressed by the simplicity and effectiveness of these constraints. The Knotty Worm demo, for instance,  has just two constraints: The follow constraint and the aim or look-at constraint. The follow constraint, makes one object follow another object, while the aim/look-at constraint keeps one object always “facing” or “looking at” another object. We had to choose which constraints to make based on their utility in games, so we picked a very select few to make. To describe a few,Point Constraint, for example, makes one object match the position of another object. Orient Constraint, matches the rotation of one object to another. All these have very strong utility while making  games.

We intend to soon add more constraints to our arsenal. Wish us luck!

Do leave your comments on the Knotty Worm demo.

Also, Game Montaz website is up – drop by to see what else we’re doing!

Our AI library is primarily Fuzzy Logic based. We started with understanding the theory behind fuzzy logic. Fuzzy logic typically is applicable in AI where for a given set of conditions, there is no clear-cut boolean answer. For example, if you were to determine whether a give age is young or not, there is no clear-cut answer to the question. While a range of ages may be considered young, you wouldn’t say that a person just beyond that age is NOT young. With a single such condition like age you can always take a call, but when conditions like this are used in combination with other conditions, the reasoning might not be very clear and is more human-intuition based. Fuzzy logic tries to mimic this “human” behavior.

When we started, the first problem we faced was of the input. What to choose as your input? What would you need to decisively dodge the bullets? We figured at the time that, the vertical distance between the bullet, and the distance to the left or right of the dodger should do the trick for us. But soon afterwards, we realized that whether the dodger (Boris) is on the left or right side is a simple yes/no decision: there was no need to use fuzzy for that. So we changed our input to vertical distance and horizontal distance between the bullets and Boris. Whether to go left or right was decided outside of the system.

Initially, thanks to our overzealous selves, we had about 12 sets in the system (you know, “we need better resolution!”, “more sets have to be better!”) and about 35 combinations to solve. After due consideration and some “mature” discussions (read: arguments…lol!), we agreed that more was not better in our case. So after quite a bit of chopping, our system had 4 sets and 4 combinations (!). And it was better! So….more need not be better, folks!

Next, was the problem of cornering: you could take Boris into a corner and he had nowhere to go! Easy as cake! Our choice of input could not enable us to deal with that….we needed a better, more elaborate input. We needed another fuzzy system! Hurrah! Err…I mean…oh, sad!

So now we had to enable Boris to avoid getting cornered as much as possible. We had to know beforehand when Boris is about to get cornered and urge him to get out of the situation. So when Boris figures he’s about to get cornered, he sends the message to our previous system and that system makes it its top priority to get Boris out of that corner. In-between, we also faced a small dilemma of getting the systems to smoothly “talk” to each other, but decided to do this talking outside of the systems. Let each system do its job, we’ll worry about the messaging outside.

So…such has been the journey of Boris. We had a ball of a time doing the Boris demo. Hope you like it! We would love to hear your views!

Since it was the illusion of physics we had to create, physics it was, as our starting point. So, out came our physics books! And we had a week full of equations and theorems… . It was tremendous fun! Of course, since we aren’t exactly physicists, we had our troubling times. I even ended up solving equations in my sleep!

One of the starting problems we faced was to translate the laws and their equations into a form that we could apply in code. I’ll take up the example of gravity. We all know gravity. Yes, it pulls everything down towards the center of the earth. So? How do we do it? What all does it affect?

Gravity is a force which always acts downwards. So we had to have a force system, which would keep track of the forces acting on a body and calculate the resultant. So gravity had to be one of the forces in the force system which would always act downwards. We also needed a motion system which would correct the motion of a body on every iteration of the engine. Studying the laws and equations and the physical quantities (like distance, velocity, acceleration etc) they affected really helped us design the engine (its still a WIP, though)

One of our biggest challenges so far was the collision detection and response(which is what the test shows). Firstly, there was the problem of estimating the shape itself.

We checked out the flash bitmap data technique to detect collisions, but that wasn’t something we were convinced would deliver 24 fps under all circumstances (our tests were not very promising). We had to come up with something that was fast as well as accurate. So we designed our own collision detection and response system. It wasn’t without its faults though!

Our initial test proved to be quite unpalatable! Some of the spheres would get “stuck” to each other and behave in the most unexpected fashion : instead of harmoniously bouncing back after collision, they would struggle with each other for a bit and then just rocket off each other…lol ! We first thought that our collision detection algorithm had a bug, perhaps. We went back to the drawing board and re-examined the code. Nothing was wrong there…..We also did some other stringent testing for the algorithm and it behaved perfectly in all the tests. The collision detection was working fine.So it was the collision response that was the culprit…hmmm. On close inspection, we also noticed that the post collision angles in certain cases were also off. After due consideration, we decided to scrap our collision response algorithm and develop something better. Back to the books, boys!
Sometime later, equipped with our new collision response algorithm, we again started our tests. This time, the angles seemed fine, but the sticking problem persisted…arrgh!

We again examined each and every line of code and the math derivations….and found the bug!!! It was a wrong sign in one of our equations. Incidentally, this equation was common to both our collision response algorithms…thats why the problem persisted. We fixed the equation and lo and behold! It worked! Eureka!..lol!

So….it was proved to us beyond doubt, how important it is to get your math right….because one wrong sign and we had to break our heads for so long to get to it! Get Your Math Right!

Here’s the link to our initial test on physics, hope you enjoy it. Drop In a comment or a criticism, we’d love to hear from you!