Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Offline Last Active Private

#5209082 Ignored by press?

Posted by Promit on 06 February 2015 - 11:02 AM

First, watch this and pay close attention: 


Second, dealing with press can be a full time job. It will take lots of work, repeated direct contact and emails to dozens of people, and then just maybe someone will notice you. Game journalists don't really care about press releases unless you're somebody who already has their attention - and frankly, you don't want coverage from anyone who's picking up press releases.

What I would suggest: look up game journalists, see what they're writing about, and when you find one that could be genuinely interested in what you have to show, let them know about it (I know, it sounds simple stupid, but it works).
In your case, finding a metalhead seems like it would be ideal, and I think you can find a few around IGN/RPS/Kotaku if you look deep enough.
Next, find a way to present the idea to them under such a light that it sounds like a "story". Doesn't matter what the game is, it needs to be sold as a story that they can rally readers around. So start thinking: what funny things happened when you secured licensing to show portraits of actual people? Did they give you show tickets to convert rookies to the metal scene? Did any of them say anything to endorse you? etc.

This is great advice.

#5208802 Bus Bandwidth

Posted by Promit on 04 February 2015 - 08:36 PM

No I'm simply wondering why 100,000 glVertex3f() calls had almost no overhead 8 years ago, but my modern GPU completely dies when I call   glDrawElements 4,000 times. I have stripped the geometry and shaders, so its I'm literally not processing anything, and those 4,000 function calls KILL performance nowadays. So my question is.....why are the draw calls so expensive internally compared to say a state change glBind() or a glVertex3f() function?

1) glVertex isn't a draw call - glEnd is. How many times were you actually finalizing the draw call? The cost of glVertex is predominantly CPU side, and as long as you're not saturating the CPU with them it isn't necessarily worse than client side vertex arrays. 

2) As you've figured out, not all API calls are equal.


In fact, a state change call is actually "free". Imagine this call sequence:


Yes, this happens in real life. All the time. (Scene graphs love to barf up this style of driver calls.) Do you want each one of these calls flipping around GPU state and taking forever? No. So the driver actually buffers up all of your state changes, Bind calls, Vertex calls, etc, and commits everything at the point of the draw call. In a stupidly designed API like classic GL, this also triggers a vast amount of internal validation - up to and including total shader recompilation and potentially pipeline flush. That is why DrawElements is expensive, and that is why DX11/12, Mantle, Metal, and hopefully glNext look nothing like this.

#5208801 Why not chord tones?

Posted by Promit on 04 February 2015 - 08:18 PM

And it makes sense, listening to the song, that it doesn't really ever resolve to anything at all. It's not really even a song, so much as a simple looped phrase. A resolving version might go ii V I instead.



I was not expecting any notes to be missing because then you can just use a thirteenth chord and be able to use all the notes in the whole scale. tongue.png

9, 11, and 13 chords are totally normal in jazz progressions.

#5208670 Why not chord tones?

Posted by Promit on 04 February 2015 - 11:42 AM

It's a D minor 7 chord, without the 5. That's why the D is in the bass line. The full chord would add an A, but that can get crowded and often the 5 doesn't add a whole lot to the tonality. And guess what the next note to appear in the bass is?


You need to familiarize yourself with all of the seven chords, as well as inversions. That covers your core 'traditional' chords. It may also be helpful to look at suspended chords.

#5208456 The dilemma of PC vs iPhone in my indie game

Posted by Promit on 03 February 2015 - 02:34 PM

I'm an aspiring indie developer and I was hoping to make a mobile game which has more depth than the current games on the market. But I feel that if I implement the game in its entirety, the masses are going to be turned off by the idea and go back to simple but shallow mobile games.

You're approximately correct. We've been down this road and it never plays well.

To be successful, the game has to have a low file size (so 25 unique levels is a no-no, there goes one unique selling point), be able to be played for a minute each time and have a very simple interface so the masses would play the game more often.
Yeah, more or less.

I had figured that I develop two different versions for different needs - one for the masses who only want short burst gameplay and another for a niche audience who wants to be immersed in a game for hours. I would develop and support both versions and name them accordingly so people don't get confused. But there are a few problems with that, specifically the overlap between the two audiences and development time. Also, I would essentially be butchering a perfectly fine and balanced game into yet another shallow game but with prettier graphics.

Consider having different game modes, perhaps "Arcade" and "Standard" or something along those lines.


Unfortunately what sells doesn't always jive with an artistic vision, and staying true to an artistic vision doesn't sell well. Picasso didn't have to sell his artwork to a million jaded strangers. With almost no exceptions, large time consuming experiences just don't fly with the audience on mobile devices. You'll have to make your choice.

#5206973 Second programming language...

Posted by Promit on 27 January 2015 - 01:10 PM

I would say C#. Going to a functional language strikes me as premature.

#5206245 College degree and Job in the game industry

Posted by Promit on 23 January 2015 - 01:49 PM


a degree from a Ivy League University such as Harvard?

I interviewed a guy from Harvard once (that was over 15 years ago). I saw his snooty snobby school as a minus, not a plus, but I tried to put that aside and just look at it as "just a degree."

I see things a bit differently now. I know that some of those big schools have outreach programs and give scholarships in underserved communities to deserving students. I realize now that a school can be seen by some as snooty but that doesn't mean its graduates are snobs.


Apparently Harvard in particular is especially vulnerable to this problem, to the extent that people avoid mentioning that they are alums.


#5206028 3 pm EST: Our interview with AIGameDev about AI/Animation in Shark Eaters

Posted by Promit on 22 January 2015 - 01:09 PM

Hopefully it's alright to post this here - At 3pm EST (one hour from now), we are doing an interview with Alex Champandard of AIGameDev about our AI and physical animation work on the iOS game Shark Eaters.


This interview with Omar Ahmad looks at the animation technology in mobile game Shark Eaters: Rise of the Dolphins. The game features a different system that animates skeletal rigs — inspired by neurology and learning of motor control. The result are smoothly animated fish and water mammals whose behavior partly emerges from the animation.


It's primarily with my colleague who developed it, but I will be there too. Basically we'll be talking about how we do the animation in the game, which is entirely driven by physics simulation. We'll also be talking about how the AI is linked into the physics, both driving it and using physics data to control/derive enemy behavior.


Here is a review of the game: https://koffeeklaud.wordpress.com/2015/01/22/ios-review-experiencing-reincarnation-in-shark-eaters-rise-of-the-dolphins/

And some gameplay videos:

#5205883 Lone Poor developer protected from Mega companies

Posted by Promit on 21 January 2015 - 05:59 PM

The key is to understand that the AAA games produced by big companies are vulnerabilities of at least 20 million, and comfortably north of 50 million for the big titles. These things need to make back their large investment, reliably, in order to be worth doing in the first place. So major companies' productions are carefully assessed for market, risk, marketing, etc and set up appropriately. They're almost universally unwilling to take risks on new stuff that is niche, arthouse, creative, etc. That's simply not their role.


It's where our role as indies starts. The big team sizes work against the corporate productions in many ways. The biggest indie successes happen when taking things in a completely different direction, one that would have never been greenlit for a full scale production in the first place. Probably the most powerful modern example is Minecraft. Can you imagine that being created by a major company? No way would any publishing exec sign off on that.


Think waaaaay outside the box.

#5205442 Ambient Occlusion for Deforming Geometry

Posted by Promit on 19 January 2015 - 07:58 PM


Could ambient occlusion be used correctly on skinned models that are animating? It would seem that it only works on static objects that could be repositioned, rotated and scaled as a whole, but not when its geometry is deforming because the radiance map would have to be re-computed. Is this correct?


If by pre-baked ambient occlusion, then it's certainly used less on skinned models but is still used. Some will prebake only on areas that move less relative to each area. World of Warcraft, for example, has always used it on character models. Areas like armpits and etc. can still make use of it, and it's probably a good idea for any game still needing prebaked ambient occlusion.


I imagine that WoW and many other games are not prebaking AO but simply painting it into the diffuse/albedo maps by hand. That's something artists have done for decades. Centuries? Millenia?

#5202988 C# seems good, but....

Posted by Promit on 08 January 2015 - 08:53 PM

--While reading keep in mind I am in a mobile device--
C# seems to be really popular here, but I have heard it is slow and similar to java. I can read java code, but can kinda write it. I have messed around with c++ (which I kinda like so far), python and lua. So as I know when you begin, you should stay with one language. Should I just stick with c++ and learn a "pro" language first or continue on with Java. I have written a "black box" in java before and would not mind doing it again in any other language. I want to get into game programming and would like to start off with a language that is versatile and I can write faster (in the start of developing). What language should I start with and is the there any good ebooks/ text tutorials online that I can use with the corresponding language. I am open to almost any language that will be continued for a long time.
P.S. I really like game dev so far because on most dev forums your post get rejected because of stupid reasons cough *stack overflow*

> I'm new to driving a car. A lot of people seem to like the Toyota Camry, but I've heard it's very slow like a Hyundai. Should I just stick with a Lamborghini and drive a "pro" car first, or continue with my Hyundai?

If you try to drive a Lamborghini fast as your first car, you will wreck it and look like an idiot in the process.


C#, Java, and C++ can all be very fast if you know how to use them properly - or very slow if you don't. Most of these people talking about how fast C++ is, usually don't know jack squat about writing fast code in the first place. A few have some inkling but have never done it on a serious scale. Many are just blindly repeating what they heard in 2006. That said, I find Java's usability to be infuriating, and consider it easily the worst design of the traditional client languages. Graphics code in particular in Java is just awful looking.


In general my recommendation for newbies is C# or Python, with a strong lean towards C# if you don't have trouble learning it. C# is also the language that I personally would recommend for somebody who is trying to complete an indie game, even if that person's day job is professional game development in C++.

#5202415 do most games do a lot of dynamic memory allocation?

Posted by Promit on 06 January 2015 - 05:27 PM

Rather than engaging directly in the valuable discussion here, I'm going to share a couple vignettes from 'in the trenches', so to speak.


The last time I worked in AAA, that engine was using a lot of modern C++ features and was, by all accounts, cutting edge code for 2007. Cutting edge enough to break some compilers, in fact. This meant a lot of STL containers, a lot of allocation, entity component systems, all the fun stuff except for exceptions. This was a 360/PS3 title and did run on PC, though that was not the intended target.


In the last couple months, optimization work began in earnest. Allocation was a significant problem. First up? Tons of traffic in std::vector. A lot of the usual suspects - improper reservation sizes, unnecessary temporaries at function level, etc. Nothing terribly interesting, but a lot to go through in aggregate. Eventually std::vector was dropped in favor of a custom vector with broadly similar behavior but more tightly specified, pooled, and instrumented. After that and a few other low hanging fruits, things were much better but not perfect. I think a lot of small allocations were cleaned up to deal with fragmentation issues, and ultimately the memory allocator itself was replaced with some well known open source third party thing. I don't remember the specific advantages, but it got us to shipping without fragmentation/OOM issues.


I heard about another game in a relatively similar timeframe that used entirely static allocation of everything. It may have been Halo. The idea is not dissimilar to Norman's code, though obviously much more complex in practice. The usual issues arise - game behaves unceremoniously when designers exceed hard coded limits, etc. But I have one simple point to make.


Let's assume you have a hard limit of 10 MB of memory for your new game, Aardvark Crossing. This memory has to be shared between Aardvarks and Zebras. Level 1, 2, and 3 feature 4 MB of Aardvarks and 3 MB of Zebras. You set the pools at 4 and 3, and leave the rest open for later. Now your designer adds level 4 with way more Aardvarks - 8 MB of them. Problem! But the designer won't relent on Aardvarks, so now you resize the pools and Zebras have to be cut down to 2 MB in all other levels.


Things really become a problem, though, when you hit level 5. See, every five levels are the Zebra Bonus Level. It's 9 MB of just Zebras! Or it would've been, if your engine could actually be reconfigured that way in the first place. There's no way you can make the Zebras fit, and there's no way to cut back the Aardvarks in a game called Aardvark Crossing. So now you have to dynamically choose your pool sizes when each level loads. One thing after another falls victim to the dynamic allocation virus, and by the end of it every type of object has its own pool allocator and you're juggling two dozen pools.


The truth is dynamic allocation was not invented for laziness, and static allocation is not foolproof. My personal opinion is that it's necessary to have a mix of both, and more important to be able to track everything.

#5200000 Should I use std::cout or have using namespace std; ?

Posted by Promit on 25 December 2014 - 04:58 PM

Short version: Use using std::cout; at source level when appropriate, but avoid pulling in the whole namespace, or putting using statements in headers. Remember that using can be applied at function or class scope, not just file.

#5199907 How does one start off in programming?

Posted by Promit on 24 December 2014 - 05:00 PM

Don't start with C++. You'll get there in time; it's a terrible starting point. And don't trust anyone who says otherwise, frankly.


C# and Unity is an excellent way to get started nowadays; don't feel that you have to spend a lot of time getting a handle on C# first. A little, yes, but not a huge amount of time. Programming and game development are very much learn-by-doing and teach-yourself disciplines. Think of something reasonably sized you'd like to create, and then figure out the individual elements you need to learn or accomplish in order to create that thing. Then simply set about learning each of those things and assembling it all together. Google is your absolute best friend, as are the various communities out there - the Unity3D forums, StackOverflow, etc.


If it sounds lax and unstructured, good. This is not like classes, where you follow a syllabus chapter by chapter. Don't worry about it. Just start making things.

#5199293 Difference between clock tick and clock cycle?

Posted by Promit on 20 December 2014 - 01:33 PM

There are many, many different clocks in any given computing device. You always need to be clear about which clock you're talking about, or the terminology is pointless. Clock cycles typically refer to the clock signal driving a processor, usually the CPU or occasionally the GPU, but those are not the only clocks around.