Imagine you want to buy a bag of noodles for your soup. You stroll into a shop and take a peek at shelves. At least 1000 different brands of noodles. How do you choose? Doesn't matter however you choose one, 999 others don't get bought by you. Similarly, when you want to buy something, there are 1000 different products and you're only willing to buy one or two. Again, the competition is choking each other.

Then when their sales fail, they blame piracy.

Avast, matey;  Prepare to be boarded by...  the noodle pirates!   

How is this thread STILL going? Some of you guys are really adamant about not wanting to pay for games.

This thread is still going because I accidentally necroposted to a two-month-old thread.  D'oh!

That would be a pretty cool system actually, haha. "You can only play my game for free on Tuesdays, but on Tuesdays you can play it as much as you like."

Puzzle Pirates used to do exactly that.  Maybe they still do.

Each day, one of their various puzzle minigames would be free for everyone to play, while the other eight or so would be subscribers-only. 

I'll just note that most professional C/C++ game engines already support basically these features.. though the "live code updates" would be restricted to scripting languages (from the screencast, it sounded like the live-update-supporting bit basically is a scripting language built around some underlying non-live-updatable system that handled persistent state and other such things;  did I interpret that correctly?).

In these professional engines, there will also usually be a direct network connection between the level editing tool and the running game so that objects can be moved around in the editor, and be instantaneously updated in-game;  you don't even have to fiddle with code to do these sorts of tasks!  Similarly, editing of variables via an on-screen GUI, or exposed via another external interface is also a very common feature.. though these tend to save final values out into data files, rather than to code.

Finally, live-updating of data assets is now a pretty common feature.. and a tremendously useful one.  The screencast only explicitly mentioned this for modified code, but in my experience this is most useful for data assets such as models and textures;  it lets you (for example) modify a texture and have the models which use that texture live-update to the new data without restarting the game.  Great for rapid adjustments to textures to cope with different lighting conditions or texture compression artifacts or just different appearances on different hardware.

when the camera moves, the characters lag in strange ways, creating a lag when the camera scrolls at a constant speed (not ideal) or even worse, a sort of "bouncy castle" effect when the camera is at a dynamic speed. the characters will be in the position that is approximately ((position they should be in) - (amount the camera has moved this frame)).

I don't know coding in Flash, but this is a common problem in any camera-based game if you have things happening in the wrong order.

In a regular game, you have two phases each frame:  an "Update" and a "Draw".  The update is responsible for moving things around;  players, monsters, cameras, etc.  The draw is responsible for actually drawing things to the screen.

When I've seen behaviour like you're describing, it usually means that the game hasn't separated its update from its draw;  it's smashed the two together, so that each object in the world updates its position and draws itself, then the next object in the world updates its position and draws itself, and etc.  If you do this, then you'll have things appear to 'lag' as you describe;  objects updated/drawn before the camera is updated will draw with the previous camera position, and objects updated/drawn after the camera is updated will draw with the updated camera position.

Assuming that I'm correct that that's what's happening in your case, the simple fix is to move the camera's update from the middle of your frame processing to the start of the frame processing.  Doing this will make your camera always be one frame out from where it really ought to be, but at least everything in your game will have the same one frame camera lag, so it won't look as visually jarring as it does now.

The correct (but harder) fix is to separate your Update logic from your Draw logic, so you can update every object in the world, and then draw everything.  If you do this, then you want to move your camera updating code to the END of the update process, so that the camera can update itself based upon where the player ended up moving to.

The Obligatory Introduce Yourself Thread.  It's stickied right at the very top of this same "General" category where you've created this thread.

And since you mentioned it, you might also be interested to read The Rules of Engagement, also stickied at the top of this same "General" category where you've created this thread, as it explains the baseline forum etiquette expected of TIG forum users.

One more awesome spot for using PID controllers is replay cameras;  they can give a very believable camera behaviour, as though a human operator was doing his best to point a mounted camera at (for example) a car driving past. 

For this approach, you would have a 3D PID which was trying to match the movement of the object being watched, and just always point the camera toward the position of the PID.  Most folks doing this will also have a 1D PID controlling the camera's field of view (this requires some trigonometry to figure out what the desired field of view is).

From what I've seen and played, the Princess Maker-genre seem to be basically a turn-based version of Diner Dash.  They're time-management games played without a clock.

As the player, you're dividing the use of time between building up stats and attempting challenges which rely on those stats, and you continue until you're strong enough to complete the end-game challenge.

One major reason these games are addictive is that they use a standard "space bar game" game design -- that is, have a visible number on the screen, give the player a trivially easy task to do, and when he does it, usually (but not always) increment the visible number -- accompanied by appropriate audio and animation fanfare, of course.  Look, Ma, I'm accomplishing things!  This is the same design that causes people to spend time fishing in WoW.. or for that matter, doing almost anything in WoW, and it's almost frighteningly effective.

When I first saw the boss-key-carrying mechanic at the start of PH I was imagining that by the end of the game there would be massive puzzles involving just getting the key to the door, since your speed and movement is restricted when carrying it. As far as I remember it never got more complex than just taking it down some stairs.

I do remember one non-completely-trivial boss-key-carrying sequence in PH.  But only one.  And one in Spirit Tracks.

But "get the boss key to the boss door" challenges certainly aren't the norm in either game, and I'll agree that neither example would ever be called "massive".

I guess my big complaint about the DS Zeldas is that they've been intensely casual-ised.  It's usually quite obvious what you have to do, but you can't actually do the obvious thing until after the game has explicitly told you to do it.  And at that point, you really can't do anything else.  Maybe the Zelda games have always been that way, and I just never noticed until the DS ones?

Santa brought me a RRoD on my 360. 

Also, gift certificates.

From what I hear the certification process for things like Wii Ware or XBLA is complicated, can involve long waits on the developer's end and can be very start and stop.

The game certification process for any console typically takes about 6-8 weeks.  Depending on the particular console, you may or may not hear back results before the end of that time.  (Some manufacturers are really good about warning you immediately if they find a submission-killer bug right at the start of testing.  Others wait until they've done the complete testing pass, and then send you back the whole set of results all at once.  But in general, No News Is Usually Good News.)

If they submitted Cave Story last month, then it'll probably still be a week or two before they'll hear how it went, and there's really nothing that they can do during that time;  if they made any modifications to the game during this time, then they'd have to start the certification process all over again.

I've played through Ultima 1-3 (after 7) and only because of a perverse sense of "duty". But just from playing the games I didn't really get any sense of story or adventure. Maybe I needed to have read the manuals beforehand. (I had the ultima collection so no manuals)

Ultima 1 was the best for that..  no story hints at all, unless you happened to give a really large tip to a barkeep, in which case there was a small chance that the barkeep would belch out a several-paragraph wall of text labelled "The Quest of Ultima", which basically told you the backstory and what you were supposed to be doing to win the game (in fact, it explicitly said that if you defeated the particular bad guy, you would complete the quest "and win the game".  Fourth wall?  What fourth wall?   )

Far more frequently, though, the barkeep would just say something brief and not particularly useful, such as "This is a great game!" or "You had best watch the wench".

On the other hand, how many fantasy RPGs are there where you can sneak behind a shop counter and steal a "phazor"?  

Pew pew!

What serious alternatives are there to OOP? I've always been in web and games so I'm not very aware of the scientific research side for example.

It's true that in the games industry, OOP seems to have recently begun to make a very slow decline (though I imagine that it'll never be totally gone;  it's much simpler and easier to hack out OOP code than what's arising in its place).

That's not to say that the games industry is slowing in its use of C++ or objects;  just that there's currently a slow shift towards not having the objects represent "things", as is suggested by classical OOP design.  Instead, trends seem to be moving toward setting up individual processes as objects, and passing them large blocks of data.  Some call this "component-based programming", but I like to call it "Process-Oriented Programming", or POP.  Or, since the processes are implemented as objects, you could even get away with calling it "Process-Object-Oriented Programming".  If you really wanted to.

Anyhow.  In POP, you don't have objects representing each individual enemy on the screen;  instead, each enemy instance has a blob of AI data that sits in an array with the AI data of all the other enemy instances, and that array gets passed to an "AI" object to work on, and the results of that get sent in an array to an "EntityMovement" object, the outputs of which get sent to a "Physics" object, and so on.

The big advantage of this approach over OOP is that you can gain some surprisingly large performance wins due to data locality (no cache thrashing as each process advances through its array), and code locality (not jumping around wildly through code), and because each of these bits have defined inputs and outputs, it's much easier to put game code onto the different cores of modern multi-core CPUs, than it is with traditional "one monolithic object per entity" approaches;  if you were really gung-ho about it, .you could probably make the engine calculate and implement optimal multithreading automatically, just based upon timing data and the movement of data through the various processes.

Of course, this approach is harder to think about (or at least it is for me!) and harder to implement.  But it's difficult to argue with the performance gains on modern multi-core machines like current PCs, XBox360s, and PS3s.  And if it means that I get the benefits of multithreading without ever having to think about mutexes in my game code, then sign me up!  

I don't believe that it's a case of "nobody thinks that it should be themselves" is true at all. There are people out there who are specifically trying to do things differently whilst making it work. Some fail, some succeed. That's part of why the comment about innovation being pushed out to the independent fringe was relevant. Commercial companies may be doing it as well, and that's great, I just think people are noticing the independents doing it more.

Sorry, I guess I misinterpreted your earlier comments.  My whole comment thread was in objection to LemonScented's comment:  "What's sad is that very little seems to be changing for the better as time goes on", I was intending to explain why companies choose to make the games that they do.

When you said "I just think you need to keep always providing a whole lot of games that aren't those games as well, for everyone else", it sounded like you were back-seat-driving the industry and nebulously suggesting that it was something that somebody somewhere ought to do, even though you were agreeing that there's no financial reason for anyone to actually do it, because those other types of games don't sell (as implied by the initial claim that very little seems to be changing for the better as time goes on).

Apologies if we've been arguing at cross purposes.

I forgot where, but I believe somewhere on these forums (or it was a random article I was reading) the writer said he had a game running at a constant 30 FPS, and game that was around 50FPS, but was not perfectly constant. He asked people what they thought the framerate was, and most people guessed the constant 30 FPS was 60FPS, and the choppy 50FPS was 30FPS.

Necroreply.   

That writer was me.  TL;DRers, feel free to skip the rest of this comment.

It's worth mentioning that the test was done on a game console where the rendering was locked to vsynch (as most console manufacturers require), so there was really no such thing as "59" fps;  when you're locked to a 60Hz refresh rate, you can render at 60, at 30, at 20, at 15, or at 10fps;  if you miss 60, you drop straight to 30.  This is because when you're talking about the timing frames being displayed on a screen, you're really talking about the number of vblanks which occur between each frame.  The 'vblank' is the moment in between frames;  traditionally, it's the moment when the CRT's scanline begins to move back to the top of the screen, so it's ready to draw the next frame.  With a screen that has 60 vblanks per second, if there's a new image ready to be displayed for each vblank, you get 60fps.  But if the image isn't quite ready for display when the next vblank comes, then you have to wait for the subsequent vblank, an extra 1/60th of a second later.

With a 60Hz refresh, my tests were these two situations.  One situation went like this:

1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 2...

That is, there was a single vblank between each frame rendered, except occasionally I'd allow a second vblank would go past between frames, simulating that the 1/60th of a second wasn't quite enough to draw the whole frame.  If you divided the number of rendered frames by the amount of time that had passed, then you'd have gotten a number around 58-59fps.. but from a different point of view, you could argue that the frame rate was occasionally dropping to 30fps from 60fps, just for a single frame.  Regardless, people saw this variation in the time between frames as being "choppy", and so generally assumed that it was running at 30fps, even though most of the time it was actually running at 60fps.

Anyhow.  The second situation was the same game, with its frame timing running like this:

2, 2, 2, 2, 2, 2, ...

That is, there were two vblanks between each frame rendered, which gave 1/30th of a second per frame, which meant 30fps, solidly.  People saw this consistency as being "smooth", and so generally assumed that it was running at 60fps.

With that said, anyone who saw both versions at once could correctly identify which was 30 and which was (nearly) 60.  And all the graphics programmers I showed correctly identify which was which.

On a PC, where many (most?) users have their video drivers set to force vsynch off, you don't have quite the same variation of frame timing, when you don't manage to hold frame rate.  Instead, you get video tearing (where the video image being drawn by the scanline changes, while the scanline is midway through drawing the screen.  Means you get the top part of the screen showing the previous frame, and the bottom part showing the new frame).  Personally, I think this looks extremely messy.. but PC FPS players love it, because it lets you maintain a smoother frame rate, even if you can't quite hold 60fps (or whatever Hz your monitor is running at).  Regardless, I didn't test this, so I don't know what the results would be between 30fps frame-locked and 59fps-with-tearing, and I don't know whether flash even attempts to synchronise its drawing with the vblank, so this whole discussion might be entirely moot, in this situation.  Plus, of course, some PC monitors have faster refresh rates;  anything from 70Hz up to around 120Hz.  Trying to render at a frame-locked 60fps on a 70Hz monitor will lead to exactly the same stuttering as in my first test above, as the game tries to evenly divide up 60 frames across 70 vblanks.

It's also worth mentioning that it's easy to get confused if you're calculating fps by dividing the number of frames drawn by the number of seconds which have passed;  floating point maths can be very inaccurate, and what's actually rendering at a solid 60fps can often show up as 59fps or higher or lower.  It's much more accurate to simply count the number of vblanks, and compare that against the number of frames rendered.  However, many APIs will not tell you this;  they'll only let you wait for the next vblank, not tell you whether you've missed one.  Personally, in my home stuff I do the floating point "number of frames divided by number of seconds" approach, and just keep in mind that the calculation is likely to be slightly unreliable. 

Mewse, "you" is a plural statement with how I wrote it, referring to everyone. I'm not specifically saying that anyone needs to be doing anything, just that someone needs to always be providing alternatives.

This is the heart of the issue, though.  Everyone agrees that somebody should be doing new stuff, but nobody thinks that it should be themselves.  As long as each individual company knows that they personally will do better financially by making a brown FPS than by making something else, then no individual company has it in their best financial interests to do anything other than make brown FPSes.

This is why in order to make companies change their behaviour, you have to make brown FPSes not sell so well, and make more novel games sell better.

As far as your comment mewse about getting people to stop buying L4D2 and MW2, I'm not sure that that is the case. I just think you need to keep always providing a whole lot of games that aren't those games as well, for everyone else. Which is exactly why the indie scene exists. People get tired of normal games and go to the indie scene to find their next game. The music genre, for example, was new and interesting at one stage, because it was different to everything else, but because it became so money driven, the market has been saturated and sales are down.

Who do you mean by 'you', when you say "you need to keep always providing a whole lot of games that aren't those games as well"?  Why, in your mind, would that particular person or company do such a thing when they can reasonably expect to make far more money by making a new brown FPS than by making something innovative?

Regardless of which bits of the rant you agree or disagree with it (I probably agreed with 75% of it, and took issue with the rest, for what it's worth), isn't it sad that these rants seem so familiar? His main beef seems to be the conservative nature of publishers, and the quashing of innovation in favour of cliches and stereotypes, and people have been complaining about that for years. What's sad is that very little seems to be changing for the better as time goes on.

At the end of the day, the video game industry exists to make money, and they do this by selling games.  When particular types of games sell, the industry makes more of them.  If you want the industry to stop making cookie-cutter games, you have to somehow get people to stop buying Modern Warfare and Left 4 Dead 2.  Rants really make no difference, as long as people keep buying the games.

It's really cool that the indie scene has taken off in such a big way in the last 5-10 years, and it's definitely currently working towards filling the creative void left by the big-budget games, although sometimes the cynical part of me wonders if, in another 5 or 10 years, the scene will have fallen into its own set of cliches, or that the signal/noise ratio would mean that even if there are still earth-shatteringly brilliant indie games being made, it's impossible to find them (it's very difficult to keep track of them even now).

What, are you suggesting that in five to ten years, the indie scene will perhaps be stuck in a loop of mostly just making endless match-3 puzzle games, Diner Dash-clones, hidden object games, and metroidvania platformers?  Gosh, I find that very difficult to believe.   

[Prefers to make games using glowing vectors, to mask the complete lack of any sort of artistic talent.]

INTP.

Thought the description was needlessly mean, though: 

"INTP:  Logical, original, creative thinkers. Can become very excited about theories and ideas. Exceptionally capable and driven to turn theories into clear understandings. Highly value knowledge, competence and logic.  Often willing to doctor quotes for comedic effect. Quiet and reserved, hard to get to know well.  Prefers to make games using glowing vectors, to mask the complete lack of any sort of artistic talent. Individualistic, having no interest in leading or following others."

 

I think this is pretty neat!

I was just thinking about Mega Man 9 and whether or not it was profitable for Capcom or not.  I guess it was...

Mega Man 9 was a "gimmick" game.  The concept of a big-name company making a sequel to a big-name franchise, in the style of the original games within that franchise got the game huge media coverage and a lot of word of mouth.  Meant that the game was able to sell to lots and lots more people, solely based upon its novelty factor and its presence in the media.

The problem with that approach is that it only works once;  make another game in the style of the original Mega Man games, and it won't get nearly the same media coverage and it won't get random members of the public purchasing it solely for the sake of curiosity nearly as much as they did when it was a fresh concept;  they've already seen what the game is like.  Unless they happen to be in the target niche of people who like difficult old-school platformers, I'd imagine that they're unlikely to buy the sequel.