Ruh roh.

Ok, I'll bite.

It can be very fast to make games/prototypes in Unity.  It does offer a lot of useful tools that are packaged well together, supports multiple languages (C# is a pretty fast language to code with, I will fight anyone who disagrees), and is multi-platform for little effort.

The base license is also free, which does allow for a substantial amount of development to be done on it.  You can release a complete game with the base license, but if you're going to release a commercial product it is quite likely in your interest to plunk down the like grand and a half for the pro license.

The UDK is a great, comparable tool, but I think some people don't like the workflow as well.  Plus, while free, it does have a royalty system attached that may not be what someone wants.  Unity is royalty free, but has its licensing cost.

Like many engines, it abstracts away a lot of the harder, more tedious parts of development.  For some, this is simply a time saver, for others it lowers the technical overhead to the point where they can perform the work they wish to perform.  Depending on the project, it could be a hindrance.

If you're a Linux humping nerd who thinks only the best things in life are coded in C/C++, then you will probably not enjoy Unity.

After applying damage the spell would continue to apply visual effects to the character. However during damage the character could die, which would prepare the spell object for destruction and remove all references.

This could slide by unnoticed due to Flash not reporting errors unless you have the debug player installed. But it would also prevent any code running after the error fired - skipping chunks of code until the next loop. Which may cause no harm, or crash the game in an untraceable way.

I'm pretty lucky to have found it.

I had this exact same bug happen in a game once, but with effects on the enemy's death animation.  It was pretty darn annoying.

Okay, sounds like I should get iPad too before or later. Though I have 4g Touch which I think I could use first for general testing.

The 4th gen touch is an excellent test device since it has a retina display but half the RAM of its phone counterparts.  Often you'll find memory issues on the touch before the phones.

The number of devices can be a bit overwhelming on the wallet.  If you just want to test for compatibility, consider borrowing devices from friends/family occasionally.

Edit:

Oh, some more mini advice.

If you want to use it for your main development box, then I'd suggest having 4gb of RAM on it.  If you're only using it to make builds, you can have 2.  I've always done my iOS work on a mac, and haven't done much cross-platform work outside of Unity.

Upgrading the ram on a mini yourself is actually quite easy, so I wouldn't stress out over it.  One of my coworkers did it himself, and he's not a hardware guy.

I just meant that the eyes were really sharp, like they were separate 3D objects and not just textures. Is that how you did it?

The belts help. You could do a little ambient occlusion where the belts meet the fabric.

Those colors are a bit better. Maybe brown or white would do well for the turquoise areas?

Pretty sure he makes the eyes separate objects.  There was a thing he posted, probably somewhere on this thread showing all the eye parts separated from each other so he can do effects like having the pupil move within the iris while a person's eyes look around.

What's going on with their feet? Are they wearing really saggy pants or are they just really short?

I think I prefer the first one. Apart from the feet.

Drop crotch pants, obviously

Problem here is that a sufficiently large pool of players does not, in fact, know what is good or bad.  In fact, a large pool of players can be horrendous at balancing a game.  Also, just because a design decision is unpopular amongst testers does not mean that it's the wrong choice.  Nerfing, for instance, is rarely popular with the playerbase but often completely vital to balancing a game.

Play test, yes, and play test with a sufficiently large user base, but don't expect it to offer up bounteous nuggets of wisdom.  And definitely don't expect a democratic process to create balance.  If it was that easy you wouldn't need game designers.

Thanks. I'll wait for updates on Mini and perhaps iMac before making any decisions since I still have couple Flash projects to finish first anyway. I think current Mini would handle the job fine, but if there is a new one around the corner I think it better to wait for that.

randomshade, could you elaborate why you hate the simulator? So far I have heard people to praise it so I'd interested in hearing another viewpoint

The simulator lies to you, viciously.  Its performance profile is radically different from an actual device's, and sometimes things will work in the simulator that do not work on devices at all.

It's an ok option for very quickly testing or tweaking something, but you can't use it to definitely say "Yes, this works."  For that, you need to run the program on an actual device.

I use it extensively, but I would not consider it "good".  It's a useful tool, but an often misleading one.

I started playing with some of the examples listed here... i absolutely love this post!!

The following results are from an algorithm that attempts at generating mountains with a simple height-map. It starts off by defining a highest peak and a few random child peaks. Then it builds outwards. I'm trying to refine the search outwards to make it less circular looking.

Mountains...or tree stumps viewed from above?

This system works fairly well, except that when that big, glowing orb lands onstage, it has to push the player away if they touch. We can't have the enemies spawning right under the player, after all.

Does it have to?

What if you made the enemies not damage/interact with the player for a half second as they're spawning in.  Could be some kind of animation where they're expanding from the orb of light.  They're stuck in a spot, the player knows where they are, but they won't hurt the player for a half second, giving them a chance to move away and avoid taking damage.

Or...

Why push the player?  Why not reposition the enemy?  How about if the player is moving left, and they intersect an enemy who is spawning in, it teleports that enemy to the right side of the player?  Personally, I'm not a big fan of this since you'd have a lot of enemies popping around everywhere with kind of poor feedback for the player (WHY ARE MY ENEMIES TELEPORTING AROUND I AM SO CONFUSED).  It would keep the player from being forcibly moved, however, and prevent an enemy from ever spawning ontop of a player.

My personal preference is for my first suggestion.

Net code is really hard to do right for an on-line fighting game.

Fighting games are primarily a two-player genre. While there are means by which they can be made more single player, they have always focused on multiplayer as the primary draw.

With multiplayer moving more and more into the on-line realm, rather than local multiplayer, the interest in indie-developed fighting games has decreased significantly. Personally, I would love to see more indie developers attempt local multiplayer titles.

Also, limited access to consoles is a fairly large issue with indie fighting development. No one wants to play a multiplayer fighting game on a PC, and certainly not with two players on the same keyboard.

Well most serious fighting game players have their own sticks they can hook up to a PC, so this is a non-issue.  It's not like pad play is fighting game heaven either.

While online play is certainly a larger component in the fighting game scene than it was just 5 years ago, I don't think it's at all unreasonable to release a game that does not have online play.  Online does not hold the indie fighter back.

Getting the fighting game community behind an indie fighter?  That's a toughie.  I think fighting games require what indies are often bad at, polish polish polish.  The game needs to be darn playable in a competitive sense for anyone in the fighting game community to really care about it as more than a novelty.  This can be really hard to achieve for even a big studio, let alone an indie who has far less resources to work with.

Now, it might be possible to do something very different from your typical Street Fighter setup and bank on the differentiation being a driving force in its desirability.  Smash Brothers, while not indie, presented a very different take on fighting games, for instance.

Toribash is an indie fighter that I consider both innovative and pretty darn successful.  It became fairly well known in gaming circles, and attracted a good cult following.  It too took a really different take on fighting games, but that served it well.  Is it polished?  God no, but it doesn't need to be.  In fact, the lack of polish makes the game better by really keeping the field open for players.  Much of the fun is watching hilariously improbable feats of physics that make no sense whatsoever, not necessarily the fighting itself (although that is very interesting when people actually know what they're doing).

I'm not saying don't do an indie fighter, but if your dream is to have it be beloved by the fighting game community and widely played, you'll have some work cut out for you.  If you want a SF-style fighter, you've got to have an astoundingly deep and accurate knowledge of how those games work.  Otherwise, you'll need some seriously fresh ideas that depart from the norm in an interesting way.

Thanks. That indeed takes Cocos2d out until I could buy mac.  

Buy a Mac.  I'm a hardcore PC guy and I am telling you to buy a Mac.  There is no painless way to do iOS development without a Mac and I will fight anyone who says otherwise.

Save yourself the pain and buy a Mac.  A mini is good, but make sure you have at least 4 gb of RAM.  At least.

Anyway, you can safely mix Objective-C and C++ code within the same project.  Objective-C++, as it were.  This is not even a hard thing to do, it's an officially supported feature.  If you're very dedicated to using Cocos2D-x, then it would be pretty easy to accommodate, and I have heard of developers basically using C++ throughout the project with a fairly thin Objective-C layer in choice places (where C++ would be either impossible to use or highly inconvenient).

Edit:  Forgot to mention, I do iOS game development professionally and I use primarily Objective-C.  I have done development with Unity on iOS, and it is not the gloom and doom machine that people make it out to be.  It was not without its flaws, but I rather liked it (especially if your goal is to deploy on several platforms).  I do use C++ sometimes, but usually only when I'm interfacing with a C++ library from Objective-C.

I live out here too!  Between SF, southbay and Oakland there are quite a few people in the area.  I mostly find out of events through TIG, but I have noticed that there is a lot of other stuff that happens around here.  Lots of mixers for professionals and developers happen in the area, so if you keep your eyes peeled you'll find plenty of opportunities to meet people.

HUD looks good overall, but that music button seems off.  The eighth notes are a tad squished.  Maybe try a single eighth note instead of two?

Pretty much.  A big revelation for me was that I had to work on stuff even if I wasn't particularly interested in working on it at the moment.  I'm not inspired 100% of the time, and if I only work when I'm like, "Golly gee I could sure go for some programming right now!" I'll never get things done at the pace I want.  Having a rule like "I will work on this every day" really helped me.

Another big thing for me was learning not to feel like the whole schedule's ruined if I skip a day.  Try not to skip days, but it's gonna happen.  Don't get bent out of shape about it, just go back and work the next day.  Too many negative emotions, even if they're geared toward making you work, are just going to sap your will to work.

Usually once I get past that inertia of not wanting to work, I find that I have a decent time working.  At the very least I get to feel productive and avoid that "I'm a sack of crap why haven't I done anything for two weeks I'll never achieve anything like this" feeling.  I think I was really afraid of working too much and making myself hate development, but that ended up not being the case.

Going through old code, saw a file named 'Two-Dimensional TMap.bmx"

"A two-dimensional map? That's something I could really use!"

This is the entirety of that file:

Code:

'=============================
'Two-Dimensional TMap.bmx
'=============================
'lol, you wish

Fuck you, past me.

I wish past me was that much of a badass.

Nothing major, but I looked at something I'd hastily coded using a bunch of parallel arrays to store some related sets of data.  Looking at it now I'm like, "Hur dur this is dumb" and replaced it with a N-dimensional array.

My favourite bosses require mastery of some sort. I like it when I have to peel back the correct strategy in layers. You start off just trying to stay alive, then you focus on achieving particular things, then you master the basics... then you realize your current strategy won't work at all so you have to evolve it.

My favourite memories with FF6, for example, had that pattern. I'd go through many runs of one boss just to test out particular angles of my strategy. I'd pick a losing strategy specifically to lose, and explore a critical element of my potential setup or the boss's patterns.

I want to be able to play it again and again. My least favourite bosses are the ones that are over in a flash. Dark Souls is interesting because bosses are very fast, but extremely dangerous and overwhelming. Most of your time is spent getting to them, again, and again.

Mega Man makes a critical mistake I think in tying level progress so closely to the boss's difficulty. I mean, you have to beat a level then beat a boss, using the same set of lives. The bosses are an order of magnitude more challenging than the levels, so if you're going to need a few runs to beat it the chip-tune music and smashing the Y-button may get on your nerves, depending on how you feel.

Dark Souls matches the boss difficulty with the level's, so it's okay that way. I'm thinking about Mega Man X (in the series), which was the one I grew up with. I'm not so familiar with the earlier ones, so I can't speak for them.

Kingdom Hearts had some decent bosses, though magic meant nothing. Like in many RPGs, the best strat is to hone-in on mass cure. The whole game after getting cure is about wracking up magic points by dealing damage, and being in the clear when you cure so enemies can't interrupt it.

I have yet to see a single RPG that uses a wide-array of spells in real-time for deep tactical variety. Smash Bros has some depth. Fighters have depth. Where's my deep, real-time, RPG combat? I haven't played Witcher 2. Maybe that's a partial answer, I don't know.

I don't understand your gripe with Mega Man.  All the games design the vast majority of the bosses to have an exploitable strategy, or horrendous weakness, that can be used against them.  Usually both.  They might throw a couple bosses that are just plain hard into the game (Yellow Devil springs to mind), but for the most part if you figure out the right strategy a boss can be trivial.

Just make the Thunderdome.

Big arena.  Walls are crazy weapons.  Some number of men enter, one man leaves, that whole thing.

Are we seriously critiquing Finn's arms for being too crazy?  Finn?  From Adventure Time?

Do we watch the same show?

The buzzword for the whole "I take my turn then you take your turn sometime later" is "asynchronous multiplayer".

There are a lot of non-real-time multiplayer mechanics that have been popping up lately.  Turn based strategy/puzzle games do async really well.  Something I personally haven't seen much is simultaneous asynchronous multiplayer, where everyone sets up their turn during a planning phase, and then once everyone locks in the game resolves their turns simultaneously.

The model you describe is pretty common in the social-mobile-gaming sphere.  Often there is "non-interactive" PVP, like all those crime games that are popular (Crime City for example).  In these, you can choose to attack other players, and combat is calculated by comparing your character's stats and equipment versus the other player's.  One person is declared the victor, the other is declared the loser, but there's no direct involvement by the players, and no consent on the defender's side.

This pretty much matches your put forth scenario, but there are some things you could consider.  For one, does the defending player lose resources by being attacked?  Do they have health, money that's stolen, troops that are destroyed, equipment that degrades?  In most of the social-mobile-games, the defender doesn't lose anything.  If you're going for a more hardcore approach, then you could let someone lose resources by being attacked.  Would certainly raise the stakes of combat a bit.

This does raise some problems, though.  Say a player logged in and saw that they were in 50 fights over the night and just got hammered, destroying their whole army.  If that army is tough to get, then they'll be pissed off.  I don't think anyone is going to enjoy having significant effort being wiped out without the chance to intervene, so you'd need some way to control this.  Some options are...

1)  Make the resources that can be destroyed cheap and replaceable.  Maybe having your army wiped out isn't that big a deal, and in fact quite routine.  Maybe it's not even persistent from day to day, and will be destroyed come tomorrow anyway.

2)  Limit the number of times a player can be attacked.  Say a person can only be attacked once per X amount of time, so even if they suffer a crushing defeat they won't be totally gutted by it.  It could be once a day, or something that resets every time the player logs in.

3)  Make PVP opt-out, so a player can toggle themselves out of it if they don't want to be attacked.  This may not be a very good choice if you want PVP to be a big focus of the game.  You run the risk of a huge portion of the player base opting out and the PVP community shrinking.

4)  Have the player set up their counter-attack beforehand, which flags them as available for a fight.  The gameplay is still asynchronous, but it would give a bit more thought and interactivity to it, and makes victory less of a sure/easy thing.  Someone attacks them, and based on the attack commands and counter-attack commands, it calculates who wins and removes the defender from the PVP pool.

You could divide the gameplay up into two phases.

1)  Simultaneous Preparation
2)  Simultaneous Execution

For example, a samurai dueling game where you have a pre-combat phase where both players can only change the stance they're currently holding their weapon in.  You can do this as often as you'd like, and can see the other player doing it.

After some length of time, there's a signal to start fighting, and then you're stuck in that stance.  Maybe changing stances takes time, and it's hard to do while someone's beating the shit out of you, or maybe you can't change at all.