Thing is, some cutscenes have to be scripted.

Like:

Me: Hey, how's it going?
NPC_1: Fine, and...
*NPC_2 RUNS INTO THE SCENE*
NPC_2: *Huff* *Huff*.
Me:What's up, NPC_2?

This requires some more advanced scripting that I do ATM I guess. Or can it be done somewhat easier?

you can implement a npc creation function into your scripting language.

Code:

function onTalk
    message(me, "hey, how is it going")
    message(npc1, "fine and ...")
    npc2 = new NPC("name", characterset, x, y)
    npc2.runTo(me.x, me.y)
    message(me, "whatsup, npc2")
end

Why script your NPC dialogue when the script can BE the NPC dialogue?  Think of the possibilities.

http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html

Couldn't you just check their signs to see if they're pointing in the same direction or the opposite direction?

I apologize if this was already mentioned, I kind of breezed through the thread, but what platform are you developing for, with what tool and what are you attempting to deliver (exe, swf, ipa, etc)?

There are tons and tons of utilities that already exist to help make the whole spritesheet process easier for you.  I'd definitely recommend you investigate pre-existing sprite sheet utilities before you set out trying to make your own sheets by hand.  You'll save a lot of time and heartache.

TexturePacker is one, it's pretty widely used on mobile devices.  I think there's a new thing floating around called ShoeBox that seemed pretty cool.

Anyway, yes, it is possible to have sprites not aligned on a grid in a sprite sheet.  TexturePacker supports this natively, and I'm sure many other utilities do the same.  I'll talk about TexturePacker for now, but the method should be pretty similar no matter what you use.

The basic way it works is that you drop individual frames into TexturePacker (or an entire gif, I think, and it can bust out the frames, but I don't recall for sure), and it will lay them out on a spritesheet.  If you have trimming enabled, it will remove excess whitespace from the frames as it places them on the sheet.  Now bear in mind the original frames you import into the sprite sheet must be uniformly sized, otherwise your animation frames will be off.

In addition to the sprite sheet, TexturePacker generates a data file to describe each individual frame on the sheet.  It contains information like the name of the frame, its position, and offset (if you've enabled frame trimming).  Using the offset information, it can reconstruct the original frame with its uniform positioning when your sprite rendering library loads a sprite from the sheet.  This means your animation frames will load as if everything were laid out on a grid, without resorting to doing so.  This also means you can mix and match different sprite sizes within the same sheet.  You can have 64x64 sprite coexisting alongside 128x256 sprites no problem.

tl;dr:  I would not manually lay out my sprite sheets.  That's far too much work.  Find a sprite sheet creation utility that has a good feature set and write (or find, someone may have already written it) some code that will load sprites from the data file it generates.

Taking a peek at a few Jobs listings for various development studios, I notice a ton of listings for such positions as 'Senior Programmer' or 'Chief Environmental Artist', with the qualifications to boot. These being prime leadership positions that usually entail tenure, wouldn't it make more sense for a studio to promote an existing employee to that position — one who's already familiar with the project and work environment — thereby creating a lower-tier, easier-to-fill job opening at the bottom, instead?

With the dev cycles for a typical game I understand the importance of new hires having the expertise to hit the ground running, but it seems to me that entrusting these types management roles to someone from outside the company is quite risky. Can anyone with more industry experience speak to this?

The "always looking for senior/lead developer" problem is an interesting one.  Honestly, I think the big problem is that there simply aren't that many people in the world who can do those jobs well.  It's tough to find really excellent programmers, for two reasons.

Problem one is that the skill of a programmer does not scale linearly, unlike other professions.  Meaning, the difference between an excellent programmer and a good programmer is gigantic.  It's not like the excellent programmer is 2x or 3x better, but more like 10x or 20x better, and can simply solve problems that less skilled programmers cannot.  Having 5 mediocre programmers on staff is way, way worse than having 1 really good one.

Problem two is that there is not a strong correlation between time spent programming and how good someone is at programming.  A lot of people muddle their way through programming and never really get better at it, others can be very dedicated and improve their skills, but they're rarer.  Given this, it's tough to train people up internally to become better programmers.  Certainly not impossible, but a bigger gamble than one might think.

I've also heard that some larger sectors of the industry suffer from a kind of brain drain, where they can't entice or keep really highly skilled developers.  The game development industry competes with the conventional software development industry, which can pay exceedingly well, and that tends to attract a lot of top engineering talent.  I imagine the indie market, with its allure of greater creative freedom and ownership of a company, also pulls people away from bigger companies.

I have been using the yield in coroutines only, but they are all basically there to fit in with the weird and uninformed way I've coded the whole game,
i'll often have

Code:

for(i=0;i<50;i++){
//do something, eg;
thing.x += 1;

yield WaitForSeconds(0.02);
}

These will be in functions called once when needed
Where now I realise it would have been better to have funtions repeatedly called while needed which look something like

Code:

thing.x = Lerp(x,y,Time.deltaTime);

but yeah, it's kinda too late now, next time

Ahhhh I see.

I've used coroutines a couple times in my games, but I only use them for things like "Do X, then Y seconds latter, do Z."  Sequences of events.

If you're trying to mathematically interpolate between values, definitely stick to a tweening library or something.

hmm, yeah -- racing games are sort of evidence that this system can work in a different context. i wonder if it's been done in shmups before?

If ever there were a time attack mode wherein you had to hit score milestones to add bonus time, then yes.

Yeah, I am curious, what are you using all these yields for?

Hooooly crap.  Unity decided all of a sudden that I'm trying to change the splash screen graphic on a basic license.  I am not.  As a result it's refusing to run on iOS devices.

This was a known bug in 3.5 when running Xcode 4.3.X.  I was aware of this and had updated Unity to 3.5.1f2 like a million years ago and the problem was resolved.  Now, without me updating anything, it just up and stops working today.  I've tried reverting back to Xcode 4.3.0, which should not have the bug, but even then it's still bitching that I'm trying to alter the splash screen, and is bitching about this on older (pristine and untouched) projects that were compiling successfully not even a week ago.

Something somewhere has somehow changed and I have no idea what it is and it is ruining every holiday known to man.

I am very mad.

Edit:  I fixed it, and I am even angrier now that I figured out how to fix it.

You know what the solution was?

I had to delete the app from my device before exporting the new version.  That's it.  Apparently something got fouled up, and for some reason Xcode is just incapable of cleaning the installed app from my device (the app which I presume it's entirely replacing, because you know, I'm exporting a new build), so I had to go in and remove it myself.

I don't know whose fault it is, mine, Apple's or Unity's, but just to cover the bases.  Fuck Apple, fuck Unity and fuck me.

To the bottle.

Hey forum,
I've just added many interchangable graphics levels to littleDragon and now I'm wanting to rig them up to change based on the games performance.

So I'm wondering if unity has in built measures/variables for game performance/speed?

something like Application.ProcessorLoad or Application.FPS perhaps ?

thanks,
-Jackson

Just concentrate on overall FPS, it will be your best indicator of system-wide performance.

Ok, so Update and FixedUpdate behave in different ways.

First off, they're only present on MonoBehaviors.  MonoBehaviors have a big set of functions that you can override that will be called by some big MonoBehavior scheduler when appropriate.  Many of the components you run across in Unity are MonoBehaviors.  If you're ever unsure whether or not something is a MonoBehavior, you can look at the documentation for that class (just search google for "Unity className reference" and it'll pop up) and it'll say what it inherits from.

http://unity3d.com/support/documentation/ScriptReference/MonoBehaviour.html

That's the documentation for a MonoBehavior.

Update gets called once every frame that is rendered.  This means the amount of time between Update calls varies with your current framerate.  If you're running at 60 FPS, you'll get 60 Update calls per second.  If you're running at 10 FPS, you'll get 10 update calls per second.

FixedUpdate gets called at a regular time interval, no matter what.  It does not depend on your framerate.  You can set the interval at which it is called by going to Edit->Project Settings->Time in Unity.  You'll see a value there called FixedTimestep, which is how often the FixedUdate function gets called (in seconds).

So if you set it to 0.02, that's means it'll be called 50 times per second, which means your FixedUpdate is running at 50 hertz.  The important thing to realize here is that it is ALWAYS called 50 times per second.  If your framerate is chugging along at 10 FPS, FixedUpdate is getting called 50 times per second.  If it's blazing along at 60 FPS, FixedUpdate is getting called 50 times per second.

This means you have to be careful what you process in FixedUpdate.  If you make FixedUpdate really heavy, it can have a huge performance impact.  Typically, you only want to use FixedUpdate for things that need to be processed independent of the framerate.  Rule of thumb, purely visual stuff should stay in Update, since it's only going to change once every frame.  Things involving physics, collision, detection of motion, should be in FixedUpdate.

...you're using Unity to make a 2D game?

It can work better than you'd think once you get things set up.

Passing your state around rather than keeping it in globals ends up being a lot easier and simpler once you figure out how to do it nicely.

This is dubious. Why is it expedient to play pass-the-parcel with states, as opposed to just storing them in one place and reading/writing as needed? Otherwise, additional error-prone constraints (ensuring that the states are consistent wherever they're stored & that everything correctly passes them around) are introduced with no obvious benefit.

I can see how it makes programs unpredictably complex if global states are abused, but if you're not doing simple, repetitive tasks over big chunks of homogeneous data, or any other structure where writes to data are manageable, you've already fucked up your design.

One reason to avoid global state is that it is easy to mess up memory management schemes and garbage collection with them.  Say you transition levels, but have a global state that keeps track of certain elements.  If any of those references to level-specific objects remain in the global state, they won't be garbage collected and can cause a leak.

You can work around stuff like this, lord knows I use global states for things, but it's a risk to consider.

An alternative, if you could accept the overhead, would be to have a single entity that keeps track of state and dispatch events to request information about the current state.  That could introduce a whole new host of problems, but it does eliminate the network of state passing without maintaining a global state.

While we're posting Shmups links, I'd like to draw everyone's attention to austere's topic "Scoreless shooting mode: 'Scoring' for survival", which essentially serves as an application of the theory mentioned in icy's essay.

Huh.  I don't get it.  Whether or not you make the point cheesing play style the default play style, you're still playing the game in a specific way.  Score comparison would simply be replaced with "how long did you live" which is precisely interchangeable under the proposed system.  Like, literally, you could write a formula to convert between the two.  Dudes would still gather around and try to break records of how long you've played, which is the same as how high your score is.  So what's the real difference?

The only thing I can think of is that score does not tickle his pickle.  He simply cannot be bothered to care about score.  Instead, he wants a different feedback mechanic, just a cosmetic swap.  Replace that score counter with a health bar and he's pleased as punch.  Sounds to me like the dude has a weird complex about score, and the people who like to pursue a high score.

My gut tells me that cheesing a high score originated as an emergent behavior that designers took note of and started deliberately designing into games.  It's not always obvious, but it's certainly a part of the game.  Much like how competitive fighting games revolve around esoteric maneuvers that do not very well align with the player's natural assumptions, some scoring systems require you to play the game in a way that's different.  I think that's pretty cool, though, because it gives you a game within a game.  Speedruns are really similar, and I love seeing the crazy tricks people come up with to shave off a few seconds, things I would have never thought of.

Accessors in C# are an excellent solution to the ugliness of individual getter/setter functions.

Still, you have to keep in mind that you are your worst enemy while coding.  You will be tempted to do shit that is both dumb and stupid out of laziness, stuff that will cost you later on.  It's not a matter, it's a matter of WHEN, and irresponsible coding practice is a ticking time bomb.

Using best practices and good style are preventative measures, to make sure you don't find yourself in a bad but totally preventable situation.  Yes, most of the time you "won't need them", but when you're driving you won't need airbags most of the time.  The cost of really bad coding can be extreme, however.  We're talking like months of effort gone if you invest a ton into a project then things change all of the sudden.  I've personally witnessed entire projects having to be scrapped and rebuilt because of bad coding practices.

Besides, it makes you look better to other people.  People will take you a lot more seriously if you can write code that's clean and smart.  It's one of those things where even if you think it's dumb and pointless, everyone else doesn't, and contrary to what people told you in elementary school, the opinions of others do matter, so sometimes it's best to cater to them.

Pointless iconoclasm at its finest.

Score is a wonderful tool.  Part of the learning process, which is a big part of games, is providing feedback to the player on their performance.  Not all games need an explicit rating system to do so, but some can benefit greatly from it.  Score is a simple, direct, yet often effective way of doing so.  It can be used poorly, but it's certainly far from being bad.  I would venture to say it can be difficult to mess up a halfway decent scoring system implementation.

It's not so important that a person be able to know whether or not a score of 560335 is good or bad the first time they play your game, but rather that they're readily able to track their performance trajectory over time.  They should be able to tell if the actions they're performing are better or worse as per the scoring system, and see themselves do better or worse, and know if what they're trying works or not.

Lots of things can be used in conjunction with score to shore up its weaknesses.  Big, flashing, thumping letters when you kill an enemy going "+10000" very clearly tell the player "Ya did good, champ."  A rolling score counter that is just going absolutely nuts feels rewarding.  Other elements can give context to raw numbers, and thus greatly enhance their effectiveness.  Leaderboards can give players a very good comparison mechanism to see how much a point is really worth.  It's foolish to cast aside a useful tool like score just because it's not a complete, out of the box solution.

Also don't ignore history.  Score is part of games, and has been part of games, and was featured very heavily in arcade games.  If you want to make an arcade-style game, including a good scoring system with an arcade-style presentation could be an extremely good idea.  Playing with expectation and precedent can be a powerful design tool.

Lastly, my favorite thing about score is how it provides a soft way to add different layers of gameplay into the same game.  Thief II used gold stolen as a score, and you could do hard mode challenges where you had to steal a LOT of stuff, which led you to explore levels more thoroughly and enter riskier areas.  Unless that challenge was plunked in front of me, I wouldn't have really considered it.  SHMUPs in particular use score as an incentive for tiered gameplay styles.  There's your standard "shoot everything and try to survive to beat the game" style, and your "cheese the point system" style.  I would have never felt compelled in Radiant Silver Gun to only shoot enemies of one color.  The scoring system introduced the concept through rewards, and I like the challenge.  The whole scoring system was built around that playstyle, and it was cool to explore playing the game in that way.

For working part time, 1.5k/mo would be reasonable.  Granted, an experienced coder would be able to make way more than that, but you could probably net someone with decent chops who wasn't super experienced for that amount of money.

"Krug make soup.  Krug frend."

Starting with the themes is a bad idea. You'll feel constrained, and it will probably be a lot harder to make your enemies feel interesting.

Themes, are sort of important. It's a good idea that at some point you can say something like, "the essence of this level/world/game is <blank>," because that creates cohesion - cohesion is good. However, choosing the theme first will produce tired results, and here's why:
  1. The most interesting enemy is one that reflects something that reflects your own unique inspiration.
  2. It's impossible to know what enemies like those will be until you've experimented designing some, iterating on them, and iterating on them some more.
  3. You won't know how your enemies relate to one another, and thus their potential for grouping, until you've made a bunch.

If you'd like to, pick a few themes that seem interesting, then try to design enemies for them. But be prepared to throw those themes out, because there's no way they'll be good enough the first time through. Keep doing this until you have interesting enemies, then make interesting themes.

The schema for an interesting enemy:
  1. Behaviour/appearance(/sound/etc) reflects its function in the mechanics system.
  2. It's function in the mechanics system drives the player to do things rooted in the basics of your gameplay, but is uniquely interesting compared to everything else he/she has to do.
  3. Creates a gameplay experience that you find compelling.

Think about what your player can do, then think about what else can be done with that to make it more interesting. Then start making an enemy that pushes the player in that direction. Go anywhere for your inspiration. The more sources you pull from - and push into your "design" prototyping - the more interesting your enemies will be.

Once you understand how an enemy makes the player feel through the mechanics alone, you'll have way more insight about how it should appear, then theme ideas will follow. If you need to prototype appearance ideas first, just to get some ideas rolling, do that - it doesn't matter. Just expect to redo them once you understand how the gameplay works.

I think really locking yourself into a theme early has the potential the be limiting, but is not inherently so.  Sometimes those limitations can even result in innovations.

I've had game mechanics inspired by the appearance of a specific enemy, or the entire theme of the game.  It's definitely important to understand why a mechanic works, and how it works separate from the theme, but that doesn't mean the appearance can't be a driver in how you select mechanics for a specific enemy.

I know Riot designs a ton of the champions in League of Legends straight from the concept art, rather than trying to design a champion in term of abstract mechanics and figure out art based off of that.  They collect concept art from the artists, run them by the design team, who then picks one and builds mechanics for it.

Point being, art->design or design->art are both viable, and one may work better than the other depending on the person.  You should also be open to the flexibility of revisiting art as the design evolves, or design as the art evolves, so you end up with design->art->design->art->design->done.  Prototyping, and being willing to throw away themes that don't work, is also a good idea.

Thanks for the advice you guys. This is a lot to chew on, I'll be sending these off to the other members. I had suggested that we do game jams as a social activity as well as getting used to developing ideas. Anybody have any jam experience or tips?

Advertise them aggressively, and keep the door open to people who aren't just club members.  In my personal opinion, the more people you have at a jam the better (within reason, don't exceed your capacity to host).

Also, try to do them pretty frequently, especially if you get people who are actually coming to them.  If you start canceling events or changing the schedule on people, they'll get frustrated and lose interest and stop coming in a heartbeat.  It might work to give them a solid, predictable date like "First Saturday of every month."

A really easy and effective format for jams can be to literally put some words in a hat and draw them.  You can format it such that you draw a couple words, like adjective + noun or somesuch.

In college, some friends of mine had a really cool jam type thing they'd do once every month called the 5 second game club.  They'd meet and try to make a micro-game meant to be played in 5 seconds around a random theme.  It was fun, and the 5 second design rule kept people from trying to make games that were too complicated to finish.