SHARAD MITRA

The Difference Between a Career and a Job

2011-04-26T13:04:00.000+05:30

I have got a really nice and precise description that is crisp and to the point.I really liked it. It was posted by Ravi on :
http://thedesimag.com/2011/04/25/the-difference-between-a-career-and-a-job/

There are things that your boss and your human resource director will probably never tell you. One of them is the fundamental truth that a job is not a career. Your job is an integral part of your career but it differs in many ways from your career. Understanding the difference is perhaps one of the most important steps you can take in your career.

Most organizations are geared towards maximizing the productivity of its employees, and by definition, the focus is on people to do their jobs better. Traditional career paths entailed succeeding at a series of jobs and climbing the ladder towards success. That ladder has increasingly become curved and convoluted. Therefore, it is very important that we manage our careers as a business; we need to recognize that if we don’t, we are depending on others to do it for us, and we are increasingly relying on fortunate turns and twists of fate.

A career is everything about your professional life that is portable. By this, I mean that a career is what you would have if you suddenly did not have a job. This includes your knowledge, your special skills, your experience, your network, your goodwill, your credentials, your education, your reputation and your professionalism. A good and satisfying job should build your career, but it is up to you to monitor the health, direction and path of your career. You need to take on the assignments, which enhance your experience and strengthen your resume. If you believe you are stagnated, you need to perform a self-diagnostic on your career. Stay connected with your network and get by feedback from your industry associates and mentors. Decisions to obtain additional training and education must be weighed against opportunity costs.

There is only one person responsible for your career – YOU! Accept it, embrace it, cultivate it, nurture it and polish it. It’s you and your brand. Once you realize that you are driving your career actively, you will gain confidence and make sound decisions, which will make you a better professional. This, in turn, will make you a more valuable asset to your organization and to your clients.

UV Layout: Non-square Texturing

2011-02-05T13:54:00.004+05:30

Creating UV layout for a non-square texture sheet

Often in gaming, we need to make non-square textures for environmental props. This requirement occurs due to one of the following reasons:

Scene importance

Object size

Saving texture memory (reduce fill rate)

Many a times, I have seen artist laying out UVs in such a way for such textures sheet requirement that, though the texture seems fine on a model, it’s actually a stretchy non-square checker layout.

In this tutorial, you will see how the UV needs to be laid out to get perfect non-stretchable layout Texel density on the model.AS a base point I have a model (Machet weapon)

Based on its proportions and importance, I need a 512(w) X 1024(h) texture sheet. I have laid out the UVs like a normal layout with perfect square checker size.

Keeping the UVs on one half of the layout will not solve our problem because this means we are just using half of the complete texture that will be applied to the model.

To better understand, make a dummy 512X1024 sample checker texture sheet and apply it to the model. It will look like this:

This is a stretchy uv layout and to make it proper we need to scale the UVs non-uniformly to +U direction (in this case).

(For 1024X512 texture sheet, the UVs need to be scaled in +/- V direction.)

Now you have a perfect square checkered Uv layout for a non-square texture.

Here is an another example where I need 256X1024 texture sheet for the model and the UV layout need to be something like this.

How To Pitch Your Game- dallman

2010-09-01T11:21:00.000+05:30

I found this article at: http://makeitbigingames.com/2007/09/how-to-pitch-your-game/by Dallman.

This is a superb article on how to approach a publisher for ur game concept.have a look!

It was one year ago that GarageGames introduced the Affiliated Developer program. In that year as a producer I’ve reviewed countless video game pitches from good to awful. I am marking the one year occasion by guest authoring Jeff’s blog to offer broad tips that will help independent game developers successfully pitch themselves or their game to any publisher without boring the publisher or losing their interest. Batter up!

Insider tip: “Zzzz” is not the sound of approval

First, a quick reminder on what our own AD program is:

“We are working with a few great developers to make games that are exclusive to GarageGames and that we help bring to market. We call this our Affiliated Developer partnership program.”

- Jeff Tunnell in Sept 2006, coining the Affiliated Developer program

Even before the coining of Affiliated Developer we always got pitches and sought good developers. It did not change with the AD program and has not changed since. Good publishers are always on the lookout for new projects and people to work with and we are no exception. This has always been the case and is no different now.

My goal here is to help you make better pitches by sharing what I’ve seen. It is broad advice and totally non-specific to GG (making it highly DIGGable *wink*). The subtitle for this post could be “pitching tips from a game industry catcher.”

The range of pitches I’ve reviewed is huge, from literally two word emails (”you like?” followed by an attached movie) to 30 page design docs complete with appendix detailing every mouse click. Everything from casual puzzle games to WOW clones; from someone who’s never shipped a game requesting a third of a million dollars to start their business to experienced developers delivering sober proposals. From that stack, here’s my advice:

Research the Publisher

My first tip is true for any publishing field, be it books or films. And that’s to do your homework. If the publisher is Popcap, don’t pitch them the next Half-Life. If the only casual game a company has made is Puzzle Poker, chances are they aren’t big on funding match three clones. Target publishers who are in your genre and you will have a greater response rate. Look at that publisher’s portfolio to get a feel for what they are interested in seeing. If you do not, you are wasting their time as well as your own. That is time you could be spending targeting more likely publishers.

A Picture is Worth a Thousand Words

If your pitch contains only text, it will be scanned over, and crucial details may be missed. While it takes time to process words, visual scenes are processed quickly by the brain. And game industry people, especially creatives, are visual communicators. A quickly mocked up in-game screen will tell more about the game than a page worth of text. The more clearly you can communicate your idea, the better it can be weighed, and the more likely it is to be accepted, at a minimum, as something of interest. A picture eggs the viewer on — it says, “imagine this scene with real art, and brought to life.” It captures the viewer’s imagination in ways that words cannot. Photoshop mock-up, programmer art, MS-PAINT, it doesn’t matter. Any sketch is better than none. If you have a real concept artist and include pre-production art in the pitch, it is that much stronger, and shows you put that much more thought into all aspects of the pitch.

“No” can Happen in one Sentence

Present your high level concept first, with one sentence. If the high concept is accepted, the publisher will continue to read for greater detail. If the high concept is rejected, the publisher stops right there, and any work you did on further details for the pitch are irrelevant. For example, your high level concept may be a genre the publisher does not work with, may be something considered too risky (an MMO), or the publisher may already have a title in the works that is too similar to consider a second. Don’t assume or expect the publisher to read the whole pitch, it can end at the first sentence. Which brings us straight to the next point.

Have Many Things to Pitch

Don’t put all your eggs in one basket. If the publisher rejects one pitch, that doesn’t mean the end of the relationship — if you have more pitches up your sleeve. Be prepared to pitch multiple different projects, and a diverse range of projects (though not all across the board and too diverse). I heard one developer whose game a publisher loved pitched an idea for his next game, which the publisher wasn’t impressed with and thought “maybe this developer doesn’t know as much about design as we thought he did.” Luckily he had a backup which was an instant hit, making the publisher forget all about the weak first pitch. One game was RPG-like, the other arcade-like. The second pitch was not a trivial variation of the first, but not as widely divergent as MMO/match-3 either. By that token, don’t have so many games to pitch that you’re just firing in the dark and seeing what sticks. Anyone can do that and it shows no commitment on your part.

Be Professional

Your pitch should be professional in presentation, not informal. You are afterall formally requesting publishing services and/or funding. A conversational style is indirect and meandering. If you want to be seriously considered, be serious.

Be Passionate about What you Pitch

This is harder with a paper pitch than an in-person one, but despite being professional in a pitch, passion comes through nonetheless. It’s simple: if a developer is passionate about a project, they are more likely to make sure they create a fantastic product and follow through on deadlines. If they seem ambivalent, then guess what, so will the publisher, which all but guarantees a “no.”

Know What you are Making

Know what your core game concept is. Know what elements support that. Know your design inside and out. Publishers will not pay you to experiment or prototype. Granted your design may change through the course of development, but you are not pitching a direction, you are pitching a specific game. Make sure you know what that is and can communicate it simply and clearly. Be able to answer why you are making the game that you are beyond just “I think I will like it.”

Know Budgets

I’ve talked to developers who, upon being asked what the budget is for the game they pitched, said they had no idea and offered nothing further. I’ve seen budgets whose only line item is “the game” with the total amount listed and no further details. Make sure you know what you are asking payment for. How much will be needed for art? For code? For administrative overhead? Are you familiar with contractor costs for these things? Do you have ballparks of man hours required for various features? How much of your budget could be saved by cutting feature X? By adding feature X? As much of this should be known upfront, not discovered later on.

You can be Greedy or Stupid but not Both

I heard this line a year ago and it’s true. If you have a great proposal, but are asking for too much money and too many “deal points” (no exclusivity, no right to sequel, no alternate format publishing) you can still be negotiated with. If you have a great proposal and at the right price, but are missing a big piece of the picture (neglecting customer service costs for an MMO, or neglecting the true difficulty of implmenting a certain feature for example), you are still potentially in business. But if you are both greedy and stupid there is no reason for a publisher to work with you no matter how great your game is. There are simply far too many intelligent, humble, capable developers out there to work with in your place. This industry has a surplus of people wanting to be in it, not a shortage. Avoid these pitfalls.

Be Almost-Greedy

I am showing my colors as a developer and not a publisher here, but it’s good advice and bears passing along. It’s true not just for video games but for any business deal. We have a tendency to shortchange ourselves or to expect the execution to be perfect with no bumps and fail to account for the unforeseeable. Rule of thumb, ask for slightly more than you’re comfortable with. At the same time, be prepared for slightly less than you’re comfortable with. Somewhere in that zone your game will get made.

License and Registration, Please

In a publisher’s eyes the team you have is as important as the game or concept itself. Ask yourself these questions and be prepared to answer them: What have you shipped? What is your industry experience? What contract work have you successfully completed? Be honest with yourself. Now ask, do the answers to these match up with what you’re proposing and asking for? Make sure they do. Publishers do not see just project but faces behind them. In sales it is cheaper to get repeat customers than find new ones. Publishing is no different — it is more effective to work with existing partners than identify and orient new ones. More often than not publishers are looking for long term partners to trust. If all you see is the one game, or all you’re showing is one game, and no the value of the team behind it, your vision is not broad enough.

When’s it Shipping?

Have a timeline and associated costs for dates. Milestones can be feature based (prototype/campaign/multiplayer/final art/bugs) or stage based (alpha/beta/RC/gold) or both. There is no absolute standard except that without this information, the publisher is going to be left wondering how long your project will take. Moreover, the publisher needs to know how much you need at each of these stages so they can project their internal budget accordingly. You’re not going to get paid entirely upfront, or entirely upon completion, so set your needs and expectations here, and be ready to negotiate.

Competitors

Capably discuss your game’s position in the marketplace. More is better than not enough. How have other games in the genre performed? What was the last succeeding similar product? How is your game similar to and unique from competing products? Who are your competitors and why is your game better? These are all important questions to answer. A pitch that is weak that deeply understands its competitors is as likely to succeed as a pitch that is strong that dismisses or misses the mark on its competitors. Showing that you know who else has your same idea and who has executed well on it (and who has failed) tells the publisher that you are that much more likely to succeed yourself. It shows that you deeply understand your genre and have done your homework.

Now with 8-way Joystick and Second Button!

Platform matters! If it’s an arcade cabinet game, how will you leverage that. If it’s a cellphone game, or a web game, or a LAN party game, how will you leverage those. Miss this and nobody will notice. But include it, and get it right, it’s that much more firepower to ignite the flame of a go.

“It’s for Hardcore Gamers… AND my little sister!”

Know who your target consumer is. “Everyone” or “people who like racing games” does nothing but tell the publisher that you didn’t do your homework or don’t really understand the game industry. There is no one right answer to this or right way to do it, but it should be some blend of age/gender/hobby/lifestyle/game preferences and the range should not be too broad. If “9 to 90″ is your “target” that’s not really a target is it? You can’t help but hit it. Find something and aim for it. Then find ways to strengthen the pitch for that particular market.

What you Do, Do That

Stay within your limits. A publisher is not going to pay for you to attempt never-before-attempted feats to see if you can. Where there is money, there is by necessity certainty. Staying within limits reduces the risk of failure for both parties. If you’ve never done networked games, don’t pitch a networked racing game. If you’ve never worked with physics, don’t pitch a game that relies on physics as a key component.

To the Point

Stay to the point. You do need to share the plan for how you will produce the game. You don’t need to detail what source control methods and what team management techniques you will use. You do need to state clearly what the game content will be. You don’t need to share the plan of how you will run the details of your business and which HMO you will be choosing for your employees. Stay relevant to the publisher. If you need an affirmative pat on the back for the details of your other plans, get that from a fellow developer or a friend, not from the publisher. They have neither the time nor the interest.

Business is Business

Don’t get personal or take things personally. The games industry is a business. The people reviewing your game are not there to make you feel good about yourself, they are there to further mutual and legitimate business interests. They are in that business because it satisfies personal interests they have (creative, social, whatever), but that does not make things personal. You will make friends, and ideally business relationships blur into social relationships, but at the end of the day, and especially with a new potential partner, business is business.

Don’t Ramble (like me)

Less is more. Publishers get dozens of pitches a day. The more text you have, the less likely they will read it all. If your “killer feature” is buried on page 28 in section 3 subsection B, they will never get to it. Make bulleted lists and summarize things until more detail is requested. Your first pitch should be three pages: an introduction letter, a one page overview, and some mock-ups or concept art (ideally with a link to a demo) with an invitation to see more if there is interest. You have all day to write up the most detailed proposal on earth. Publishers do not have all day to read dozens of them. And they get only dozens a day if they’re lucky. I’ve heard of publishers that field hundreds every day.

Tie-in

The more relevant you can be to the publisher’s history the better. Do your homework. For example if they made a hit FPS game, acknowledge it or try to tie your game to it (“like your game x, my game has an emphasis on team co-op”). But don’t go to absurd lengths (“like your game x, my game also has graphics!”). Yes, this is partly ego-stroking. And yes, it does work (but will only get you so far).

Originality

Your pitch should be original. As soon as it’s “it’s Metroid but with X” most publishers will no longer look at what you’re doing, and will instead focus on who you are. Anyone can come up with “Metroid but with X,” but only a very talented team that knows what it’s doing could pull it off. If the best you have is a rip-off of an old game with some different features, or a mash-up of some popular games, don’t bother unless you’ve successfully done it before.

Orson Welles Syndrome

Be flexible with your features. This isn’t about the publisher trying to creatively control your project. They don’t have the time or desire to do that. If a publisher is interested in your game, but wants to scale up or down, react accordingly. If they don’t like a certain feature and you’re not married to it, let it go. Don’t be too defensive or worried about “the publisher designing your game for you” until you actually feel like it’s happening. Asking to drop a certain feature or set is not a slippery slope and is common practice. This does not mean the publisher is designing your game.

I am Error

Don’t try to impress the publisher with your knowledge of games or gaming history. It’s irrelevant to the pitch. If you have a good pitch or idea your knowledge of games will be self-evident.

Who What Where When How Why

Make sure to go back and ask yourself if you’ve covered all the basics: who, what, where, when, how, and why. Who are you making the game for, who will be working on it. What is the game itself. Where will the game live (on what platform is it ideal for — certain platforms cater better to certain markets than others, PC/strategy for example). When can you start, how long will it take, what are your milestones. How will you develop the game, with what tools and tech, with whatwhy do you believe the game will be a success and is worth looking at (without that being a three page impassioned essay about how you’ve been playing games since you were five and know everything about them). kind of team (in-house or contractors). And

LET ME PLAY!!!

A playable prototype or demo is golden. No graphics, no sound, no building out of the game, just core game proof of concept. A pitch with pictures will get ten times further than a pitch without. A pitch with a prototype will get a HUNDRED times further than a pitch without. Don’t apologize for the demo, they’ve heard “this isn’t the final game art or gameplay” as many times as I’ve heard “please excuse the mess” walking into a perfectly nice home. Even if a pitch is rejected, if you re-submitted it with a playable demo, it could be re-considered. Many publishers will not accept unsolicited pitches without a playable demo.

Mess Up

You’ll make mistakes and it’s OK. If you think there’s people in the industry that know everything and never make mistakes you’re wrong. You don’t need to be that person because that person doesn’t exist. If the publisher raises an issue that you hadn’t yet considered, don’t front — the publisher is smarter than that. Fess up to it and tell them you’ll discuss it with your team and follow up. Then actually do that. Especially the follow up part. Be humble.

This is by no means a step by step guide on how to pitch, this is general advice for studios or individuals of all sizes, professional or not, on how to pitch publishers, solicited or not. As with any blog these are my own thoughts and opinions and by no means GG policy. We’ve worked with some great studios in our seven years in business and hope to keep working with plenty more.

Happy indie game-making,

- Joshua Dallman, GarageGames

Game Model: Asset Complexity Guideline

2010-05-31T17:03:00.018+05:30

This documentation explains the importance of defining smoothing groups as well as practically showing how careless unwrapping can increase vertex count in a model which will not be visible in a 3d application like Max or Maya.

The model in this example is a simple pillar (below):

Vertex count is more important for a mesh because of the simple fact that in any 3d application or game engine the mesh/model is displayed/ rendered based on the position of the vertices.

No 3d application knows about a face or an edge but creates a face based on the corresponding vertices and their position.

We cannot define vertex count for a mesh (especially for gaming model) because it depends on many things like smoothing groups, UV-Unwrap and multi-material. Moreover, the smallest face that can be rendered is a triangular face (Connecting 3 vertices), we prefer defining tri count for a model rather than vertex or face count.

Coming back to our example models:

First Model is exported to unreal editor with auto smooth applied (each face has its own smoothing group based on the angle defined). Importing the model (Especially for Reich) will give you an error:

What is this error?
Model’s vertex count exported to unreal should not be 125% more than the actual mesh count in 3d application. E.g. If your model has 100 vertices, the exported vertices count should not be more than 125 vertices.

In unreal engine the actual vertices exported are 66 instead of 17.

Why this happened?

Whenever 2 different smoothing groups are applied to 2 adjoining faces, theirs common vertex is split into 2 (each contain information of their face smoothing angle)

2. This time we import manual smoothing model. This model has less smoothing separations compared to auto smoothing import. Vertex count comes down to 52.

3. Now we import single smoothing group model and definitely it will have least no. of vertex count.

(Check the shading issues with single shading)

Surprised??Vertex count remains the same contradicting out though….No…this is because of the fact that vertex count also depends on unwrap, even though smoothing is single default unwrap islands created so many vertices.

4. Lastly, we import chamfered model and see the count.

Surprised again?? Though tricount has increased but the vertex count got reduced to 49 compared to all previous imports.

Why this happened?? This is because of the simple fact that it all depends on smoothing group and unwrap layout.

In all the above exports we didn’t touch Unwrap….Now we start fiddling with unwrap on the model. All the models has now flattern mapping applied.

(Normal Model) (Chamfered Model)

1. This time we export our very first model (Auto smoothing group) with generic flattern mapping.

See how vertices reduced from our first export with no mapping (60 vertices) to one level of flattern mapping (52 vertices).

This change occurred because in default/no mapping, unwrap was broken at many places while in flattern, it got reduced to lesser UV islands.

2. Now we import manual adjusted smoothing group model with default flattern mapping.

The vertex count again reduced from 52 to 44 because smoothing groups was same but unwrapping was different.

3. If we import single smoothing group model with flattern mapping:

Same result…….Vertex count reduced due to flattern mapping.

4. Last import is of chamfer model with flattern mapping.

This time vertex count raised significantly because of flattern angle breaks in the mapping. More the number of uv islands, more the vertex count.

We can reduce it more after adjusting the Unwrap. We try to change mapping to our models and see the final count.

(Normal Model with adjusted unwrap) (Chamfered Model with adjusted unwrap)

1. Our first import is of auto smooth model with adjusted and fixed Unwrap.

Vertex count didn’t change. It all depends on the UV layout.

2. Next import is of manual adjusted smoothing group with adjusted unwrap.

Same result…..no change..It must be because wherever there is a shading split there is a UV split. If shading split is on one face while uv split is on another face, then both the split will be taken into consideration.

3. Now, simple models with single smoothing and adjusted unwrap.

Drastic change……decent count but lighting issue is persistent.

4. Lastly, we import our chamfered model with accurate smoothing and adjusted unwrap.

Again, the count got reduced to a decent level.

As a final not if we compare all the models we have the chart:

(In all the modes above, chamfered model is perfect in terms of specular highlight and shading)

AUTO: Such smoothing is rarely used since it increases unnecessary vertex count. Though smoothing angle can be adjusted to get more appropriate smoothing result. Drawback is there will be razor sharp edges with no specular highlight so the model looks bad visually. It is always recommended to manually adjust the smoothing.

Manual: Manual adjustment of smoothing is always necessary to reduce smoothing groups wherever possible and thus keep vertex count in limit. Try to keep, wherever possible,different shading only at those face where UV gets split. In this process, try to get as few smoothing groups as possible (while not hampering lighting/shading information) so as to minimize smoothing splits.

Single: It really helps to get the model with least vertex count in the engine at the cost of lighting issue if the model is less complex (At times). Such smoothing can be used where the mesh count is enough to support pooper lighting. Since this is a very basic model (example above) lighting is not so much accurate but a complicated model with single smoothing group is best way to create gaming models.

Chamfer Corners/Edges: Rather than setting different smoothing groups for a cornered surface, it is always better to chamfer the models and assign single smoothing. Though it increases the mesh count a bit but it is far better way to reduce vertex count and get lighting/shading perfect on the surface.

Another Example:

Texture Memory Table

2010-05-31T15:20:00.005+05:30

Here are the two images that show the texture memory (in Kb) used when we convert or create an image in Dx1,3,5 format (with and without Mip-maps).

CGtantra Award Nomination

2010-05-27T20:25:00.000+05:30

My Game Model got nominated(best 5) for CGtantra award for Best Game Model.

Here is the link: http://www.cgtantra.com/forums/showthread.php?t=23126

Game Engine Survey

2010-05-27T11:08:00.016+05:30

This is one good article I read on Gamasutra (by Mark DeLoura) which describes the changing trends in Game engine usage and acceptability.It presents few eye openers.

The Game Engines

Certainly there are quite a number of game engines one can license for a game. The ones that are relevant to any particular game vary based on targeted platforms and genre, as well as timeline and budget.

For the purpose of this survey I (Mark DeLoura) focused on these commercial engines, primarily in the “core” market:

Crytek’s CryENGINE
Digital Extremes’ Evolution Engine
Emergent Game Technologies’ Gamebryo
Epic Games’ Unreal Engine
Garage Games’ Torque
Id Software’s idTech
Terminal Reality’s Infernal Engine
Trinigy’s Vision
Unity Technologies’ Unity
Valve Corporation’s Source Engine
Vicious Cycle Software’s Vicious Engine

There are many more engines available, including many open source engines. Some other notable engines not focused on in this survey include Blitz Games Studios’ BlitzTech, Digini’s Blade3D, and Dassault Systèmes’ 3DVIA Virtools.

Foundation of the Survey Responders

The approximately 100 executives whose data are used for this report are spread across the game industry, but by-and-large focus on the “core” market, PCs, consoles and handhelds, targeting traditional gamers. The casual and mobile markets have different engine demands which in some cases overlap with core, but the results of this survey should not be taken as directly applying to those markets. The core market appears potentially very fertile and lucrative at the moment when compared to others.

So for your reference throughout this data, our survey responders stated that they are currently working on titles for the following platforms:

Development on other platforms (PS2, WiiWare, Mac, Linux, iPhone, other mobile) fell below this rate.

Current development budgets for these titles fell largely into two lobes: under $4M, and over $16M. 42.2% of responders are working on titles costing less than $4 million, and 42.4% were over $16M.

Game Engine Awareness and Use

With so many game engines available now, which of these have game industry members actually heard of? Which have they used? Clearly one of the most important elements for game engine companies is just getting their product in front of the right people, so if executives aren’t even aware of their engine, they’ve got big issues. The game engines with the most awareness from our responders were not a huge surprise, and both the technologists and producers had roughly the same level of awareness on all the engines. These were the top five:

However, asked which of these game engines they’ve actually used, the picture becomes more interesting (I’m leaving off the lower parts of the data purely for brevity):

What is immediately noticeable in this data is the massive awareness and knowledge of Epic’s Unreal Engine. It is the most well-known, and more remarkably, a majority of our responders have used it!

After Unreal Engine, the data drops off a cliff fast – with Torque, Gamebryo, and Source all roughly equivalent as the second most frequently used game engines, with about one out of five people having used each. The distance between Unreal and the rest is interesting.

Even more interesting is the massive awareness of CryENGINE even though there aren’t many games on the market using it. Let’s see how perceptions of these game engines correlates with this.

Perceived Usefulness

Beyond simple awareness of these engines, how useful do the executives think they are for their current projects? Those who have used the engines before (or are using them now) should have a very good idea, as should those who have evaluated them, but these ratings probably mostly belie a simple perception of a game engine’s capabilities. I asked our responders to “opt out” if they didn’t know how valuable each engine actually would be for their projects, or rate them on a scale of one to five, if they did know:

Something that pops out of this data immediately when combined with the previous questions is the belief that CryENGINE is the second most useful game engine middleware available, even though it is also one of the least used!

Also notable is the sudden emergence of idTech and Infernal on this top five list. Does it reflect a belief that game engines made by companies that are using them for their own games must be the most “useful”? Or, keeping in mind that people are responding to how valuable these game engines would be for their current project, it could be that these engines have been seen used for games of similar genres, and on the same platforms. Certainly some of the other game engines pride themselves on being more broadly useful across a variety of genres. This data seems to suggest a belief that genre specialization is valuable. Or, maybe we’re all making a lot of the same types of games. :-) It’s hard to sort the complete answer out of this set of data, but it is interesting to see.

Using Game Engines

Backing up for a moment, why do we believe that people even want to use game engine middleware? If it is true that game engines are becoming more accepted by the industry, it should open up the market for more engine companies. Certainly the leading perception is that engine use is on the rise. But let’s check it out.

When asked if they are using game engine middleware on their project, our responders definitely indicate that engines are popular. 55% noted that they are currently using a licensed game engine on their title – that’s specifically an engine, not middleware libraries.

But when asked if they WANT to use game engines, the opposite results were returned:

Although the majority of our responders are using a middleware game engine, it appears that they would rather not! By this data, it appears that perhaps a thin game engine which adeptly integrates middleware libraries from other companies may find more acceptance in the marketplace than one which tries to do everything on its own.

The Economy

The difference in the percentage of people using game engines versus those who want to is certainly interesting. Could the high level of use have something to do with the economy, or with the increasing cost of development? I asked the producers whether they’ve found themselves with tighter budget constraints due to the economy. 78.6% responded yes. But in the comments many people pointed to tighter control over their budgets, as opposed to diminishing budgets.

Following up, what has been the impact of these rising development costs and a dwindling economy? What concerns have increased most for developers in recent years? The five most popular responses were:

Increasing development cycle length, increasing headcount, trying to create game designs that stand out from the pack... these are fairly consistent game developer challenges. But looking for rapid prototyping and rapid iteration tools? Here we find interesting new news. Rapid prototyping enables a developer to more quickly draft and test game concepts for fun in the early stages of a project, and also use the prototype to acquire funding. Rapid iteration gives one the ability to quickly try out many ideas during development, improving the game through frequent experimentation and fine-tuning.

If rapid prototyping and rapid iteration are weighing heavily on people’s minds, what are they using now? And how many studios have live preview on the target platform in their current content pipelines?

I asked, “what are you using for rapid prototyping?”

Several people noted that are using their previous engine versions to create prototypes for the next game. But what do new studios use? It looks like they probably create one-off C++ applications, sketch things out on paper, or use Flash or Lua. I had suspected that more developers would be using C#/XNA due to the ease of quickly knocking out quick test applications with it, but only 5% of the responders said they are using this for prototype development. (However, 76% of developers are using C#/XNA for tool building.)

If rapid iteration is also a growing concern in game development, how many developers currently have the ability to do live preview on the target platform for their content developers (artists and designers)? According to the results, 62.5% currently have this capability. Several responders noted that they preview on a PC version of their engine and that this is good enough for most work. Certainly using the actual target platform would be even more valuable though!

One useful tool for rapid iteration during development is the use of interpreted scripts; if the designer can write in a script language and immediately execute it on the target platform (as opposed to a long recompile or download), the iteration cycle can become quite fast, enabling many experiments and much more fine-tuning of gameplay ideas. But what script languages are most people using? (This query supported multiple replies.)

It seems that Lua is the hands-down favorite for scripting languages at the moment, although one developer wryly noted: “Lua is a failure - decided before I joined.” Lua is a solution that can work, but people tend to have a love/hate relationship with it. Using Lua on performance-constrained platforms can definitely be a challenge if you don’t understand the ins and outs of Lua’s memory usage.

Making a Decision on Engines

The last thing I wanted to know from both producers and technologists was: What factors do they use in deciding whether to license a game engine, and which one to choose?

The overwhelming favorites were of course cost and time. If we purchase a game engine, we want to spend less money and time than we would have creating the engine on our own. Otherwise why would we bother? (We’ll talk about that question more in the upcoming production-oriented post!) In third position to money and time came genre relevancy, or making sure that the game engine works properly for the type of game you are creating. This emphasizes the importance of doing a thorough evaluation of any game engine you’re looking at, and knowing if a particular engine was already used for a game technologically similar to what you are planning to create (a first-person shooter, for example.) Also highly important to the responders was support and thorough documentation, a good-quality content pipeline, and the ability to easily integrate the game engine into one’s existing technology as well as with other middleware libraries.

Licensing a game engine is an important decision. Clearly many studios are doing it, and you should do a thorough evaluation of each candidate game engine before settling on one. Unfortunately there isn’t enough public information about most engines, so seeing a game similar to your own, or knowing people on other teams who have used a particular game engine for a title can go a long way to helping you with a decision. As we all focus more on rapid prototyping, rapid iteration, and live preview in content tools, we hope that the game engine creators are listening and will continue providing us the excellent tools we need to create amazing games.

Game Engine Overview

2010-03-25T22:25:00.002+05:30

This slide is being created by gathering data from the internet (www.extremetech.com) and other sources.It provided inside story of what goes behind a game engine. Must for a new entrant in gaming industry.
Check out this SlideShare Presentation:

Game Engine Overview

View more presentations from sharadmitra.

Gaming Process

2010-03-25T22:21:00.004+05:30

This slide has been created, keeping in mind, upcoming artist who wants to know basics of 3D.Its is a must for artist who want to be technical artist and not just simple 3d artist.
I have added images taken randomly from net and have no intention of cheating anyone or stealing anyone's artwork.I want to thank all the people whose artwork is in the content and appreciate their hard-work and support in making this presentation.
Check out this SlideShare Presentation:

Gaming Process

View more presentations from sharadmitra.

Information Update

2010-03-25T22:13:00.000+05:30

This is just to inform that I would start adding tutorials and information regarding Gaming Industry on this blog really soon.Keep coming back to this blog for more information and update.

Profile Update

2009-11-26T22:23:00.011+05:30

It's been really really long time since I have updated my profile on this blogspot. After my job shift to Exigent game art studios, I was so busy with my new role and responsibilities that I didn't get time to post something new.

Now is the right time and here it is ......Unearthly Challenge posting.

Me and my professional partner Dimpal Maisuriya worked as a team to finish our entry. All in all, I worked on Low Poly stuff unwrapping few of them too, generation Maps and finally arranging stuff in Unreal and final composition while Dimpal worked on Concept art,high Poly and texturing work.
I am really thankful for him for helping me learn a lot of stuff during this competition.

You can visit our thread at:

http://www.gameartisans.org/forums/showthread.php?t=11453

Final shot images :

Level Design

2008-04-15T22:00:00.003+05:30

Hi
It's long time since I last updated my website.....This is my new creation ..a part of one level flow (A Big Hall)..mail entrance to the castle.

I don't know who's art work is this but I sincerely want to thanks him/her for his/her work and ask him/her to allow me to post his/her work on my blog and let me use it as a part of my personal profile and not professional reel....

Sailor

2007-08-20T21:10:00.001+05:30

SAILOR
Maya7.0, Max8.0

Hi

New Update..though still work in progress

Modeled in Maya and Max and will rig in Max....still working on Texturing

Tree Girl

2007-07-16T21:04:00.001+05:30

Organic Tree

S/w:Max7.0,Maya7.0,V-Ray1.46

Hi all

This is my new creation......
Base mesh in Max;Posed in Maya and then taken to Max for addin up Roots,Leaves,Flowers and other details....
Finally taken to Maya for further beautification..... Hope U like it..

HellChick

2007-07-16T21:02:00.001+05:30

Topic:Hellchick

Character:Female Chick (W.I.P.)
S/w: Maya7.0

Hi all

This model is based on a concept from Paul Richards- www.autodistruct.com..

Actually my idea is to build a base mesh in maya and take it to zbrush for further details....

Wait for update....!!!!

Unreal Level

2007-06-10T22:41:00.001+05:30

Hi All

This is my latest W.I.P.,a level for Unreal Tournament 2004
Mesh is done in max8.0 and will be used as a static mesh for the unreal editor.

Dream House

2007-01-17T17:42:00.001+05:30

Again some timepass stuff(though not really!!!).Everytime U do something U gain Something....
So hav fun!!!!
Modeling in Max7.0(Actually I saw similar model image somewhere..liked it and build it with changes as per my needs)

Bedroom Dream

2007-01-12T12:48:00.000+05:30

Hi all!!!!

It's the contemporary bedroom dream I m having lately in my dreams,so I jst thought to giv it a try.

Eveerything in 3DS Max7.0
Rendered in V-Ray
2 lights[1 Target Spot and 1V-ray]
Render Time:27 min[720:480]

Night Scene In V-Ray

2007-01-03T18:34:00.000+05:30

Another success to crack V-Ray.

Models r taken frm the net.Thanks to all those whose modeled these stuff.....
[OOpssss.....paintings too]

Rendered in V-Ray(2 V-Ray, and 5 Photometric Lights)

Quick Work in V-Ray

2006-12-29T15:50:00.000+05:30

I m really happy to get this rather quickly than I expected.

Job done in 8-10 hr.Mesh was collected frm net.Whole stress was on v-ray rendering and appropriate texturing and shading.

Everything in 3DSMax7.0 and
Rendered in V-Ray1.46
Render time:15 min

Castle Scene

2006-10-06T17:31:00.000+05:30

This is a scene....though not that new.I started it couple of years back but hanged it for more important work.
Recently it strike my eye and again I hav started working on it[work in progress]......This time I m trying smthng new.....hope u like it.....Do place some comments and critics......

Low Poly House Models

2006-09-29T14:38:00.001+05:30

Hi....
Old House Model and Posh House Model done in Maya and Max.Done as a Low Poly Game Model.

Girl Model

2006-09-15T19:02:00.000+05:30

Again Maya,again Zbrush same old story......Base mesh in Maya,Detailed and textured in Zbrush and finally Rendered in Max Mental Ray.....Enjoy!!!!!

Latest Zbrush work

2006-08-30T17:25:00.002+05:30

This is my latest work in Zbrush.Base Model in Maya and detailing done in Zbrush along with normal map generation and finally rendered in 3DS Max mental ray.

Merc C Class

2006-08-25T12:14:00.001+05:30

Mercedez C Class
Maya 6.0,3DSMax 7.0
Colored Render-MentalRay
Shaded/Wire Render-Skylight(Max)

First post on my page....Merc.Benz C Klasse