Mac hardware:

I see I can buy very cheap some MacBook Air or MacBook Pro (Intel CPU, I know, I see PowerPC (or Motorola) I shall not buy ). Would these be sufficient?

I'm concerned with OpenGL version available, I would love to have at least OpenGL 2.0. What is the lowest OpenGL version these laptops support? And maybe some list of supported OpenGL versions based on laptop model?

I assume these all come with OS X 10.something preinstalled and that it would be sufficient?

Should be fine, if you're mostly testing compatibility you won't need too much beef in the machine.  Minis are good 'n cheap, but if you want something portable a used laptop will likely be fine.

As for OpenGL support, this chart could be handy! https://developer.apple.com/graphicsimaging/opengl/capabilities/GLInfo_1075_Core.html

If you somehow find a computer whose specs don't appear on the chart, I'd investigate the graphics card, but I think this will cover most any Mac you're going to stumble across.

My mortal blood pounding furiously through my ears.

I've never seen an MMO that allowed for investment, but it would be an interesting thing to consider.

Indeed, you can consider "real economic growth" to be counter inflationary - you can let your money supply grow (source/sink imbalance) as long as something is growing. It doesn't have to be prices, it could also be net standard of living, or number of players. But short of that, you need to keep the money supply constant or you get inflation.

But I don't see why you worry about it. In a virtual game, you have near total power, I don't see any difficulty in balancing the money supply.

Yeah, plus it's way easier to be like, "Repair bills cost 10x more gold suck a dick players" than to try to model a real economy.  Having god-like powers over the economy lets you do stuff that doesn't work in the real world.

So is the only way to prevent it is balancing sources and sinks?

Well, that's a swift conclusion.

What you're making is a sink, but you're just not calling it that.

Sources -> Add money to the economy.  They are mints.
Sinks -> Remove money from the economy.

What you're proposing removes money from the economy, and is thus a sink.

There is a third route, things that soak up money but don't remove them.  What matters more is not so much how much money exists, but how much is actively being circulated on the market.

Virtual Economies tend not to do this as much, but in real life people put their money in things that don't destroy their wealth, but also ties it up.  Investments are an example, as are savings, or the purchase of durable goods.  Sometimes you can liquidate investments or possessions, or smash open the piggy bank, but those funds are less accessible, and thus, not as influential in the liquid market.

Things like bonds are also able to soak up excess money in an economy.  If the government wants to remove a ton of money from the economy, it sells bonds with good yields.  If it wants more money to circulate through the economy, it makes bond yields crappy to force that money into private investment.

I've never seen an MMO that allowed for investment, but it would be an interesting thing to consider.

automated memory management is probably the best part of moving from a compiled language to managed

Ehhhhh sort of.  I don't think it really changes that much since you're still going to have to control the lifecycle of your objects in C#.  Memory can still leak, and you can still clobber available memory if you just allocate objects all over the place.

Programmers are lucky in that nobody sees their code after they deliver their product

I'm a plebeian programmer, the salt of the earth variety who cares only for a few simple things

1)  Does it run stably at my target framerate?
2)  Can it be reasonably maintained in the future?

Beyond that, I don't care how artistic my code is because, you're right, no one who plays my game will see my code.

Singletons are not particularly hard to read, they don't make code unreadable, and they can totally be useful and appropriate.  I've never been totally mindfucked trying to read someone else's code that used Singletons.  I was always just like "Oh hey yup that's a Singleton".

You like something?  Pfft.  Be prepared for a deluge of hipsters that hate things with opinions.

Yeesh, that's cheap.  The place I'm staying at is way more expensive.

There's that IndieCade thing that's coming up pretty soon.  Don't see a thread for it yet, so...

Any of you cats going?  My roommate and I are!

Awwwww yeah.

Started working on a game for PSM (Playstation Mobile).  The SDK's pretty alright, but there's just not a lot of tools that exist for it.

I couldn't find a way to do easy, optimized, sprite sheet driven rendering out of the box, so I coded my own today.  All you have to do is drop sprite sheets made by TexturePacker into a directory, and you can construct sprites by their name.  It handles the sprite sheet lookup, batching, caching and object pooling all behind the scenes.

You can also do standalone sprites with it (not on a sheet) if you really feel like it.

Now I can start making a game...

Yup, that's what motorherp means.

You won't need to do anything special.  One you reach the right "edge" of the noise map, start sampling from the left side.  Modulo will do this for you, even.  The player won't be able to detect the switch, unless they're picking up that it's just a repeated landscape.

candy corn icon in the UI looks like shrooms

Agreed.

Maybe try drawing it sideways, or at an angle?

On the technology note, UDK operates on very old programming concepts where you just have base classes that you inherit from, but this is unwieldy and inefficient.

EVERY game engine(modern game engines at least) operates this way! even Unity3D. Maybe you don't see the base class, but it is there! You MUST oparate this way, because if you want a list(or "vector" if you prefer), the items must be descend of the same class.

I haven't been following your posts that well throughout this thread, but have you ever looked at the UDK?  It contains MAD inheritance hierarchies that are deep deep deep.  Like 15 classes deep.

He's not griping about having any inheritance, just that the UDK's usage of it is arguably a bit over the top.

Unity's inheritance hierarchy is considerably more shallow, relying more heavily on components to add complex functionality to a specific class.  This trends toward horizontal relationships in code rather than vertical ones.

I hope when you release the game, you release all the strange occult concept art along with it.  I really dig that sort of stuff.

Hoho!

I'm moving to a new apartment on Saturday, so I'll be absent.  Have fun, kids!

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Then why aren't people using them?

People are, you really think Unity is the only engine people use?  

Besides anyway, my point isn't that other engines are better than Unity, I use Unity plenty enough myself and really enjoy it, just check out my blog, so dont take offense.  What I'm getting at is that different engines are more suited to different workflows and different tasks.  Why go to all the effort of writing your own engine within Unity just to circumnavigate most of Unity's main features and try to force it to fit your workflow when all of its design works against it.  Alternatively there's likely another engine or framework out there that you could use out of the box that is much more suited to your desired workflow and still has the features you wanted from Unity such as cross-compatibility etc.

I apologize, I didn't mean to sound so attacky in my post.  I'm just tired of the "Hurrrr Unity is terrible" hipsters (which you are not).

Yes, there are other engines that people use, lots of them in fact.  No engine is a magic bullet, they're always coded to make a certain sort of thing, and they do have their own workflows and limitations that must be taken into consideration.  I would certainly not use Unity for every project, but I do think it's still a pretty compelling engine even if I have to do some non-trivial customization to get it to do what I want.  It does depend entirely on what you want to do with it, though.

I finally fixed a bug that's been haunting me for weeks which would cause this iOS game to stop responding normally to touch input.  Basically, every touch had to be upgraded by 1 finger.  Double touch became single touch, triple touch became double touch, etc.

Another engineer had been working on this windowing queue that would display any sort of UIViews in succession when the app started.  Two of the windows destined to be displayed were already made, but he created a third one himself.

Inside of this he did a thing that I'd glossed over.  He was creating an empty Cocos2D menu and situating it so it sat between the game layers and the UI layers.  It did nothing, was just sitting there gobbling up touch events.  The intent, I believe, was to make it such that while this particular UIView was active, you wouldn't be able to interact with anything behind it.  I thought this was just being added to the OpenGL view of Cocos2D, but it was actually being added somewhere else.

Long story short, whenever the game was resumed after a pause, if that window had been displayed, then cleaned up, the reference to the parent view of the empty menu was being lost.  It would never be removed, and would sit there consuming touches until you killed the app and loaded fresh.  This was really annoying, because if you closed the window normally, that view was released fine.  It was only if the window was displayed the first time you ran the game, then it changed to not be displayed on a subsequent run, and you sent the app in the background while it was being displayed.

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Then why aren't people using them?

Also on the note of "Make a game in engine X and it feels like an X game."  That is simply not true.

Didja know that Dark souls and Flower were built in the same engine?  Can't think of many games that are further apart than those two, but they were.

It's more accurate to say that engines are highly tempting rather than limiting.  They offer a big ol' toolbox of nifty things that you can plug into a game.  Want smoke?  There's a particle for that right in Unity.  You don't even have to configure anything if you don't want to, just drop in an emitter and bam!  Smoke.

The asset store for Unity makes it very easy to acquire tools that others have written, prepackaged solutions for a problem.  This means it is very tempting at times to use these solutions, in their basic form, to achieve a certain goal in development.

These are tools that are publicly accessible to multiple people, and it's very possible for multiple developers to use these tools in a very off-the-shelf manner, which can result in similarities between titles.  It's not the fault of the engine, however, but moreso the developers themselves.

A game that feels like a "Unity game" doesn't do so because the engine is so incredibly crippled and limited that it can only produce that sort of game, but rather because it offers a lot of readily accessible tools to make that sort of game.  If you don't care to modify things, or don't have the technical skill to, then yeah you'll end up with a samey feeling game, but not at the fault of the engine.

(An engine can be a terrible, limiting pile of crap but I do not believe Unity to be such an engine)

I've always just used version control for code.  SVN or GIT, don't matter to me.

For other assets, dropbox works well.

I get super distressed when I find out that something I wrote in objective-c is leaking.  I was looking at a bug report today and had that sinking feeling.  Sure enough:

self.blah = [[Blah alloc] init];

What an idiot I am.