It's pretty poor to simply quit on something that isn't a disaster. Make it work.

it actually takes huge balls to bail on a long term project that isnt obviously a disaster but has some unfixable flaws that prevent it from being truly great...

(again, never played SD, this comment is more in regards to shadow physics / goo / 3D marian / etc)

Yeah, you either have to bail or pivot and completely rework the game.  In the case of Shadow Physics and Goo, the core concept of a "game about shadows" or a "game about fluid" are solid, but the way those mechanics were utilized and implemented was flawed when it came to supporting actual gameplay. A pivot could have solved those problems, but at that point we would have basically had to make a new game.  This is what Marian ended up doing.

Glaiel, you're making it sound as if Shadow Physics' development has been discontinued, is this true?

Has been since July.

(I didnt play SD so I'm not gonna comment on it)
(edit: steve is giving a shadow physics talk right?)

Steve and I are giving a talk at the failure workshop.  Will probably be mostly my talk though.  I have different thoughts than Steve about a lot of key points as to why the game went wrong, I also promised myself not to really hold back during my section of the talk.  Should be interesting.

Someone should seriously make a strategy game where you play as all these different factions and the goal is to stop everyone else from getting popular and winning at GDC. Weapons could be replaced by marketing tools like tech buzzwords ("procedural generation") or 8-bit nostalgic 30-year-old appeal, and when you get enough money you could step it up a Notch by hiring hitmen or bribing TIGSource moderators to edit out negative criticism of your game and give you frontpage publicity instead of your other indiependent opponents. Trade and diplomacy could also be changed thematically to forming social connections at conventions with big-name developers so you can gain perks in art, programming, etc. which help you meet deadlines and raise your popularity meter. The game ends when you win at IGF, get picked up by Steam, and recieve your first 10/10 IGN review.

Hah, this is awesome.  Indie Game Dev Story. This should be the next TIGSource compo, make a game about making indie games.

Doesn't teach you to do pixel art, which in my opinion is way harder than vector art.

Hah, classic TIGS .

i think ea is gonna buy everyone eventually, they already bought like 100 game development studios and own like 40% of the market share for games sales

http://en.wikipedia.org/wiki/List_of_acquisitions_by_Electronic_Arts

And then Zynga will buy EA completing the cycle of life.

as for unity games, there's fatale and the graveyard by tale of tales, desktop dungeons, feist, max and the magic marker, etc.

Yeah, there have been a lot of substantial games made and released in Unity, but nothing so far has impressed me as much as games I see made with Flash, GM or C++.  This is purely my own personal opinion based on stuff I've played.  Haven't played Graveyard and I'm not a huge fan of Tale of Tales, having played Feist or Max and the Magic Marker either (although they look pretty good.)

Desktop Dungeons is great, but the Unity version is quite finished yet and it started in GM.  They're also mostly using Unity as an "easy" way to get a cross platform support, and not really taking advantage of it otherwise.  I'm been impressed with some unfinished Unity games, Interstellar Marines and Warsoup could be pretty good first person shooters. Maquette is an awesome prototype but really early so we'll have to see how it develops.  Aztez also looks awesome but is really early in development.

another difference though though is that pygame is a lot older than unity -- unity has had a lot less time than pygame to build up a library of games

Unity has a lot more users and a lot more momentum.  Pygame is much lower level as well, basically a Python wrapper for SDL with a little bit of extra high level functionality (collisions and shape drawing).  Python is a great language but Pygame isn't so great of a framework.  I like Pyglet but haven't really done any thing with it, so I don't know how good it is.  I think I might code my next game in Python, but probably using low level OpenGL\OpenCL or DX11 wrappers.

python is too slow (there've been tests and python's actually slower than GM) and i don't like the format of its code -- i don't like that it requires indentation for instance. i've also never seen a good game made in pygame, but i've seen hundreds of good games made in gm, and i tend to judge something by its results

Dangerous High School Girls in Trouble was in pygame.  I think that's generally regarded as a well-made game.

Plus Ren'Py runs on top of Python\Pygame.  Not everyone is into visual novels but there have been a ton of great ones built with Ren'Py. Digital a Love Story, Don't take it personally, babe, it just ain't your story, and Air Pressure have got some coverage in the larger indie game community though.  In the early days of Ludumdare there were a lot of good entries made with Python, Galcon probably being the most successful.

I think you see more good games made with GM than other engines or frameworks because GM has reached a critical mass and its been around for a while, not necessarily because GM is a high quality tool. Seems like Flash (with Flixel or Flashpunk) is over taking GM now anyway. A lot of new and old indie game developers that would have been using GM a few years ago are developing their games in Flash.

I'd make the same argument that you made about Python about Unity 3D, I haven't played a really good finished game made in Unity, but that's no fault of the tools, Unity is a pretty high quality engine and probably has the most user friendly interface\pipeline of any game engine available.

Hey guys basketball is still cool right
Especially when it's arcadey two player flashy basketball I guess?
I hope so

Thought I'd never see a clone of Jetpack Basketball...

I always forget to comment my code.  I'll make something, then when I have a bug I have no way of knowing what anything does anymore and what's causing the problem.

Probably means you need to write better code instead of better comments .

I'm not familiar enough with Xcode to know exactly how to do this, but in Visual Studio under debug settings you can change the working directory of your application under the debug settings.  When you launch your app from the IDE it will use the overridden working directory. So you could mess around with your project settings and get this working that way as well.

There is no explicit jump height in that code.  If you want to change the character's jump height then decrease or increase velocity.y. If you want the character to fall faster or slower change acceleration.y. There is also a fixed fall velocity (1200 in the example) that is applied when the player releases the key or after the player has been jumping for longer than 0.25 seconds.  Adjusting that will cause the player to fall slower or faster.  Honestly that code seems a little buggy.  Seems like the last "velocity.y = 1200" should be "acceleration.y = 1200".

If you absolutely need an explicit jump height its possible to calculate it using equations of motion or just keep track of how high the character has jumped and cap it (although that might feel a little weird).

My worst habit is that when I want to fiddle with a block of code, instead of just changing it I copy the whole block twice, comment out one block, and edit the other. That way if I decide I want to go back I can just delete the new block and un-comment the old one.

I have this habit also, part of my generally bad habit of copy and paste coding.

This comes up all the time in both the game industry and the larger software industry (mostly among proponents of agile). In some ways (usually performance related), the game industry is ahead of the software industry, in other ways it is generally behind, but software engineering practices on the whole are much better.  The comment about developers not using "proper source control" or backups for multi-million dollar projects is ridiculously.

Regardless, this guy is speculating about an industry he knows nothing about.  He's also probably assuming game development is 15 years behind because he's heard things from game developers 15 years ago.  Individual studios might be 15 (or more) years behind, but the industry as a whole is probably roughly in step with the greater software industry.

There are some great gems in the comments like this "It's still run by those garage hobbyists. They have *no* idea what they're doing. Most game shops won't let you develop in C++ for current consoles because they imagine it's too heavy."

Many game developers do not write unit tests, but there are large game developers and game technology developers that unit test or use TDD (Crytek, Bungie, Unity3D, Highmoon, one guy in the comments mentions EA studios that use it, etc.)  I disagree that unit tests don't work for games, it's hard to unit test rendering code, especially code that runs on the GPU, but it's not very hard to test gameplay code.  I doubt many, if any game companies have 100% test coverage.  This presentation by Crytek (http://www.crytek.com/cryengine/cryengine3/presentations/aaa-automated-testing-for-aaa-games) and Noel Llopis' series on TDD for games are both good examples that game developers do (or at least think about) unit testing and TDD in a pragmatic way that works for games.

I haven't worked on at studio that did unit testing, mainly because Unreal 3 is difficult to unit test, people do it but its not very common. Both AAA games I've worked on have had code reviews (on Shadow Physics we do informal reviews, but there's no sense in formalizing the process with such a small team), and used source control, bug tracking, had back ups, continuous integration and automated crash dump uploading.

I agree with everyone. It has pros and cons, my main reason is I dislike writing getters and setters for everything when 90% of them will look like:

Code:

Something const& getSomething() const
{
  return m_thing;
}

void setSomething( const Something& thing )
{
  m_thing = thing;
}

Making everything public is good for small and midsize projects, but can potentially cause problems in larger projects. I've worked with million+ line code bases that do it and in practice it wasn't too much much of an issue, outside of programmers that don't agree with it architecturally bitching .

If C++ had AS3 style get/set or C# style properties (and read only variables) this would be a non-issue.  In C++ you can emulate this functionality but it's not really worth the effort. I usually use private or protected variables and getters and setters if a variable is internal, read only or requires non trivial assignment, but not always.