davidsiems

While this article makes a good point (don't say no just because you're lazy) I think it misses a more important one.

Time is incredibly important for projects operating with a schedule, especially if there's a fixed amount of development time (maybe the company runs out of money in six months).

As the implementor, it's up to you to judge how long something is going to take. Any time spent doing feature X, takes time away from tasks Y and Z. If the schedule is full(ish) then you need to have a discussion about tradeoffs. And quite often, even though X would be awesome, Y and Z are vital.

I think the 'best' trick I've seen is using pointer tagging on an object's virtual function table pointer to squeeze in an extra flag during garbage collection.

Adding another variable was thrashing the cache, so instead the GC would tag the VFT pointer (making it unusable obviously) and then untag it before GC ended, fixing the object.

I wasn't sure if I should be horrified or applaud when I found out about this.

If you're looking for a cutting edge whitepaper on this stuff check this out: http://maverick.inria.fr/Publications/2011/Cra11/CCrassinThe...

Cool article, it left out my favorite function though: http://en.wikipedia.org/wiki/Smoothstep

This is the magic sauce you need. (more visual demo here: http://sol.gfxile.net/interpolation/index.html)

Higher than the Xbox360 indie market, maybe. Definitely not the main XBLA store though.

From what I've read it's pretty easy to get up on Steam. Terraria and Magicka are good examples of games from unknown teams making it big. I think Terraria was put together in something like 4 months, made a couple million dollars too.

I've worked for a few video game 'startups' that tanked or are in the process of tanking. Here are some pitfalls to avoid:

* Make sure you focus on the company aspect of things. Why are you making games? If the answer isn't 'to make money' you're doing it wrong - make them as a hobby instead. Starting a video game company because you have great game ideas, or because making games is something you love to do is a bad, bad idea. The reason for this is that at the end of the day, if you don't focus on the financial aspect of things, your company.will.fail. Most game companies fail because they're living month to month off of publisher's paychecks without trying to establish revenue streams of their own (other than royalties).

* Speaking of royalties. If you're getting funding through a video game publisher, make sure you understand how the payout will happen, how your advance is being payed off, etc. You probably won't have much negotiating power here, and this isn't really a route I'd recommend unless you _really_ need the funding.

* Start small, don't try to make a game engine right out of the gate. Put something simple together and iterate on it. If it turns out you're making a lot of the same type of game over and over, then think about abstracting an engine out of it.

* Reconcile the awesome game that's in your head, with the awesome game you can make given the time and resources available. Don't overcommit, you'll just end up implicitly cutting features instead of explicitly cutting them, and the game will suffer.

* Don't forget about the importance of marketing and timing. Great games fail _all the time_ because they weren't marketed well, or because they released and then got buried by the latest AAA or hyped up title.

Yeah consoles are rough, high cost of development, and high chance to get overlooked.

Agreed, a good lead would be doing everything within their power to _prevent_ this from happening to themselves and the rest of the team.

Get off your high horse.

You could say the exact same thing about books, TV, movies, paintings, etc.

Games are just like any other form media. Yes, many of them are superficial, but a lot of them tell incredible stories, teach life lessons, and evoke powerful emotions. To top it all off they can also be incredible teaching tools.

Just because you think something's a waste of time doesn't mean other people aren't deriving real meaning from it.

As a reference point:

I have an nontraditional CS degree (DigiPen). I learned a lot of math in school, and programmed a ton. There was emphasis on data structures / algorithms, but not as much as you'd find in a traditional CS degree.

Part of my job is to hack around on JSCore in a Webkit port. I do this without much problem. I wouldn't say I understand the whole thing, but if I needed to I could.

In my experience, you learn as you go. As long as you're good at problem solving and using Google/Reading/Asking People Who Know, you'll figure it out. With or without a traditional CS degree.

There's nothing magical about JSCore, or hardcore storage, or spaceship control systems. It's just domain specific knowledge that you pick up if you spend time solving those kinds of problems.

There's a pretty big difference between making something playable and making something scale-able. When you've got 48 hours to make something playable scaling gets thrown out the window.

I'm a fan of 'Plan together, implement independently.'

I don't need someone looking over my shoulder hunting for bugs while I program. What I need is someone to bounce high-level ideas off of so that I don't get paralyzed by indecision, or overlook an important edge case.

Bad design decisions concern me a lot more than a bug here or there.

In my experience, planning with someone else away from the computer, and then implementing is as fast (and usually faster) than sitting down at the computer and trying to bang something out from scratch.

When you do things this way you don't really need to have another person there because you've already agreed on all the important details.

Just as a reference point, in this article [http://whatgamesare.com/2011/02/you-need-four-coders-product...] the argument is made that you need four coders to make a game.

I think formula being followed for these articles lends them to being a little...exaggerated. (You NEED X to make a game)

I successfully shipped an XBLA game with one other programmer on my team. It took us 14 months, and we delivered on time, in scope, and on budget.

We had two designers writing scripts, so I _guess_ you could say we had four coders, but there was a vast gap in programming talent there. I had to go back through near ship and rewrite most of the scripts to fix all the bugs.

What you need, is to be smart about how you work (make tools to make making the game easier) and be realistic about what you can accomplish in your given budget/time frame.

I'm not saying gamedev is easy, it's hard, and it takes nearly as long to polish the game as it does to get it up and running. But there are so many target markets out there at this point that saying something like you need 100k/4 coders/100 hours of gameplay is foolish.

You don't need variable names to understand what the code is doing, it's just harder without them.

Try going to google.com with chrome, opening the developer console, going to scripts right clicking and selecting 'de-obfuscate source'.

Crunch is the unavoidable result of poor project management. Project management in software development is notoriously bad, and in game development we're even behind that curve.

Schedules are built on hopes and dreams instead of historical data. Impossible promises are made to publishers in order to secure funding or keep from being cancelled.

Most harmful, is the belief that crunching actually increases productivity. If you look at the research on the subject the most you can hope to gain is about a 2 week boost before you backslide and become less productive.

If you could reliably deliver (fun) games on time and on budget you would have a serious competitive advantage in this field.

The first company I worked for had mandatory code reviews, I was on a team of about 20 other programmers and I thought it was a great system.

Then I went and worked for a startup video game company, the programming team was myself and one of my friends from college. We decided not to do code reviews because we were building a game engine from scratch and the churn was going to be way too high to keep up with.

You can claim that code reviews are fast, but when you're generating a couple hundred new lines of code a day that really builds up. Especially when each person is committing 5-10 times a day.

What we decided to do instead is go down to the coffee shop below our office every day and just talk about what we were working on, the problems we had run into, and what should be worked on next. As a result, we still had a lot of knowledge sharing going on without having to look at every single line of code going into the codebase.

Having a general idea of how the systems are being built and put together is _much much_ more important than going over every line of code looking for bugs.

My point, is that the knowledge sharing is what's important. We could have done code reviews, but it was actually a lot easier to just talk to each other for an hour or so a day away from the computers about the state of the project. As a hidden bonus, we also got fresh perspective on implementation ideas before any work was done, which I imagine saved countless hours.

This sort of thing is probably less feasible at larger companies, so maybe code reviews are the best way to share knowledge there, but if you're under 3-4 people I'd definitely try this approach instead.

I've actually done a fair amount of thinking (and even a little implementation) on this topic so I'll share my thoughts.

I've come to the conclusion that my ideal 'game programming' language would actually be 3 different languages that are tightly coupled. It would consist of the following:

- A low level language, similar to c/c++/d

- A scripting language that is tightly coupled with the low level language.

- A scripting preprocessor that's run as a preprocessor for the low level language (effectively replacing templates and the C preprocessor)

Low Level Language:

Games need to be fast, that's why they're written in C or C++. At the end of the day, when you're trying to squeeze those extra cycles out of your console, you need to be able to have precise control over how your data structures are arranged in memory, how things get copied around, what data is preloaded into the cache, etc.

It's okay for this language to be garbage collected, but the programmer needs to have full control over the garbage collector, ideally the garbage collector is of a variety that doesn't require stop-the-world collection. You'd probably also want manual memory management to be an option.

Scripting Language:

In game development, having a low-cost for iteration is also extremely important. If it takes your game designers 20 minutes to tweak something simple, the end product is likely not going to be very good. This is where scripting languages come in, you load all your resources (textures, models, etc) and then you iterate on the game logic without having to load everything from scratch. Loading can actually eat a very large portion of your development time if you don't have hot-reload or your game logic doesn't exist in script.

By tightly integrated I mean make the two languages intimately aware of each other's details. They each need to know how the other is storing data, it needs to be _simple_ (as in just a keyword simple) to call into and out of one from the other. This way the way they communicate can be fast, and a lot of the process can be automated by the compiler so you don't have to do it by hand.

A cool thing here would be having the ability to compile the scripting language to assembly or the low level language when it's time to lock things down for ship.

Scripting Preprocessor:

Embedding scripting languages into lower level languages can be a bit of a pain. In C++, you have a code generator do it, you use templates, or you do it by hand.

Templates are way too complicated for what they accomplish (code gen), the preprocessor is usually used in the same way (code gen). If you're not using these two methods to generate code you've probably written a code generator in an external scripting language that's parsing your C/C++ (yuck) and spitting out C/C++.

What we need is a preprocessor that is actually a scripting language in its own right. The scripting preprocessor gets run before the low level compiler, and just spits out code in the low level language. You have to jump through hoops to 'loop' or 'if' with templates, it's about time we gave ourselves a fully featured language to do our meta-programming in.

If you're really trying to write efficient code (which is what this article claims to care about) you don't 'forget' to do things like assert that the data is correct. You _guarantee_ that the data is correct and then you process it as fast as you can without having to check.

You only run into trouble with this method if the data verification step is the computationally expensive operation.

You would put an assert inside of the divide function like so:

  int divide (int x, int y)
  {
    defend (y != 0);
    return x / y;
  }

Now divide is guaranteed to produce a correct result if it's called with correct data. It's up to the caller to make sure the data is correct, or an assert will happen.

Just to finish out the example to show how much cleaner asserting is compared to error handling:

  int foo(void)
  {
    volatile int x = 4, y = 28;
    return divide(x, y) + divide(y, x);
  }

  int main ()
  {
    return foo();
  }

That's not to say that error handling doesn't have its place, but it should only be used for data that you can't anticipate.

You can accomplish this by using asserts in your code.

You don't need exceptions to get a callstack and you can assert that values are valid and force a crash / callstack dump when they're not.

On top of that, you can compile the asserts out for release builds if you're confident they won't be hit.

You're absolutely right. It is exclusionary. Participation should be exclusive to those who can vote. This means, no corporations, no organizations, no churches, etc. Individuals _only_.

Not letting Canadians vote in our elections is exclusionary too, that makes sense to me. Just because it's exclusionary doesn't mean it's a bad thing.

Of course we can't get consensus on 'best interest' but at least we can limit participation to those who's interests are on the table.

If you're CEO of X-Corp participate all you want, but do it with _your_ money and _your_ vote and that's _it_. At least there's a chance I'll be able to reason with and engage in political debate with you.

This is exactly why we need campaign reform.

If you're business X, who's product is something that is provably not in the people's best interest you can ram through its legality with enough money thrown at the policy makers who are supposed to be serving the people who elected them.

AT&T did not elect John Boehner. John Boehner should not share _any_ ties with AT&T.

If you've never read it before this book is a very intuitive introduction (and refresher): http://www.amazon.com/Calculus-Made-Easy-Silvanus-Thompson/d...

While I agree that attendance should be voluntary this solution doesn't address the whole problem.

Part of the problem is that education is not valued - neither by the kids, nor their parents. As a culture we need to make sure education is valued across the board.

Another part of the problem is that once these kids are out of school they'll be causing trouble at home or in their neighborhoods.

I think a better plan would be the following: - Make attendance voluntary, but put programs in place that allow people to return to school and learn regardless of their age.

- Put trade schools in place that teach practical skills quickly. This way even if you're not cut out for school, at least you can learn a skill that can make you some money. A lot of these kids are coming from low income families.

- Make parents responsible for their kids. Right now a lot of parents treat school as daycare for their kids, they don't care what happens there as long as the kids aren't at home. Schools need to be able to expel and discipline kids without being fiscally punished. (either by lawsuit or losing funding because of poor performance)

Long term maxharris is absolutely right, you can't teach someone who doesn't want to learn. It doesn't work. We need a cultural shift that places education at the top of the list. And we need political leaders who are willing to risk their necks and hold parents accountable instead of throwing money and bad policy at the problem.

It's actually industry standard for the publishing platform to take ~30% as the article says. XBLA, Steam, and PSN all do this as well.

It may seem like a lot, but those users wouldn't be available to you without the platform supporting you.

For C/C++ the debugger is an invaluable tool.

For large projects (especially large projects that don't have the files structured well) you can end up with very high compile and link times (> 2 minutes). Using a debugger in this case is much faster than incrementally adding print statements to the code.

Being able to see a callstack is also incredibly valuable on complex projects. The value of printing things out drops dramatically once you have multiple entry points into the same codepath.

Also, if you always run your program through the debugger, when you crash you can immediately diagnose and fix the problem without having to reproduce the crash. This is useful for hard to reproduce bugs.

Besides, it's not like this is an 'either or' type thing. You can use a combination of reading the code, debugging, and printing to track down problems.

Here's what Crockford has to say on the subject:

"One of the mistakes in the language is semicolon insertion. This is a technique for making semicolons optional as statement terminators. It is reasonable for IDEs and shell programs to do semicolon insertion. It is not reasonable for the language definition to require compilers to do it. Use semicolons."

http://javascript.crockford.com/survey.html

I'm inclined to agree. You already have to deal with enough complexity while you're programming, why add more? It's easier to follow the rule 'always use semicolons' than to try to selectively use them.

If you're interested in running a successful company you'll prefer whoever is most competent (technically, socially, etc.), regardless of where they're coming from.

If someone you think is a 'know nothing' gets hired instead of someone you view as technically skilled, you've learned something about that company. Maybe you don't actually want to work there.

College isn't a magical pill, what you get out of it is proportionate to what you put into it. If you're motivated enough to teach yourself to program, you're probably motivated enough to learn a lot in college as well.

Being self taught and being college educated are not mutually exclusive.

I think of it as more of a predictor of future behavior.

Pirating software doesn't necessarily mean you'll lie to your customers (or to me) but from my standpoint - If I see you being dishonest in one fashion, it makes it more likely you'll be dishonest in another.

The more ways I see you being dishonest, the less I will assume you are being honest (about anything).

If you're pirating software, you're sowing seeds of distrust at your company with those that don't approve.

One of the last things you want are your employees or co-founders not trusting you.