When you're jamming on, oh, say, a 48-hour solo game competition, super fine-grained control over the movement of characters/projectiles is something you need instead of being at the whims of a full physics engine.
Unity makes this possible, but the relevant documentation page doesn't exactly spell it out explicitly enough for my tastes.
So anyway, if you're making a Unity game where 1) You're not using the PhysX engine and 2) You want to detect collisions, then here's what you need to do:
- Give rigidbodies to all your colliders.
- On those rigidbodies, set isKinematic to true.
- On the collider, set isTrigger to True.
- Detect collisions in the trigger functions, OnTriggerXXX(), not OnCollisionXXX().
That's it! I'm happy I figured this out during a Ludum Dare, and not on a more important project, but either way I'm glad I know what to do next time.
Joshua Topolsky has made a living out of breathlessly writing about tech trends that he and his teams don't understand, so this is really just the latest straw on that poor camel's back:
In case you didn't follow the original post days before Topolsky stumbled upon it, a designer decries a certain type of icon, claiming (without any evidence or citations) that they cause more work for the human eye, and are therefore bad design.
(Yes, of course that same author posts the exact kind of work he's decrying on his own Dribbble page. Would you expect any less?)
Good to see the insanity of lazy financial analysis isn't confined to Apple:
Nintendo will be forced to reform its approach to gaming and will start selling its software titles on mobile devices such as smartphones and tablets, rather than pushing its hardware as its sole avenue of distribution.
Spoken like a true outsider, with no clue how Nintendo is structured or what its internal teams are capable of making.
This is a post-series I should have started a long time ago. Kickstarter is a website that lets you invest in projects that are ambitious, daring...but might not be attractive to traditional investment channels (software publishers, VC, etc etc etc). However, the site is structured to make "backers" expect physical/digital products in return for their money, despite the fact that what they're doing is "backing the project," not "buying a product." Kickstarter is not a store, and various KS projects prove it all the time.
The Double Fine Adventure Kickstarter Project was, in my opinion, the first KS project to really set the standard of ridiculous goals for software development projects. The words "stretch goals" never even appear in the project's pitch/updates, but you can see in their blog that they didn't take their ridiculous overfunding seriously, and now here we are a year later with an over-budget, twice-delayed software project.
The sad thing about this is that the Double Fine Adventure could have been an on-time, under-budget $400K-$1M project, and everyone would have won. That's one of the poisonous things about Kickstarter; encouraging extra goals past what you've pitched. The pitchers haven't thought enough about these extra goals, or what they would do with the extra cash (hint: it should be "profit") should they receive it.
I tweeted out a (somewhat general, not targeted) complaint to @TimOfLegend on Twitter, and his response was understandable in a perverse way; since they're paying their own money to finish the game, and still fulfilling backers' promised rewards, isn't that okay?
But this is exactly what I'm getting at: If Double Fine had just made a game that could have actually been met with a $400K budget, there would be no stress in the budget, and the delays would likely have been much more tolerable.
Kickstarter is not a store, but is it too much to ask the project managers to just make what you pitched?
So many gems in this Gamasutra article (originally printed in GameDeveloper Magazine's final issue) about the opportunities afforded to game designers when planning your game's ending, but I'm going to stick to the wrap-up quote, as it really struck a personal chord:
It was the existence of this magazine that gave me my first glimpse into the murky, somewhat-secret society of game developers...It's much later now. We have internets, game developers are meeting with vice presidents, and 99.9% of people under 25 have played video games. It's a world in transition, and I cannot wait to see what happens next... Thanks. Thanks for that, and for all the other stuff.
...That is my truth on endings: I mark them, I use them to reflect, and if I can get away with it, I give thanks to people who have had an impact on my life...
As a college student, joining IGDA (and, at the time, thusly getting GameDeveloper Magazine) was my first "real" visibility into the world of game development. Suddenly, the code I knew how to write had more meaning. Suddenly, I couldn't just run a UNIX cluster or program a spreadsheet, I could make worlds. I couldn't just find cheap flights and detect credit card fraud, I could find the shortest path to my teammate, and detect visible enemies. Without GameDeveloper Magazine, I wouldn't have the drive and inspiration that took me to where I am today.
Thank you, GameDeveloper Magazine. You have inspired generations of game developers, and I owe a personal debt to the legions of artists, programmers and designers who have shared their knowledge with all of us.
Mattt Thompson's always-entertaining NSHipster covers the new MKLocalSearch, pointing out one of the great benefits to selecting it for POI search:
MKLocalSearch is a relatively straight-forward API (albeit perhaps worse off for eschewing a simpler single-class interface)... so what's the big deal?
API limits. Or rather, the lack of them.
However, he fails to point out a couple of huge issues with this API. Apple likes to say that it exactly replicates the search field in iOS Maps, but the real restrictions are:
- Results are limited to only ten POIs per search, and
- Empty queries are disallowed.
"All POIs around me?" Nope, sorry. "Nightclubs in San Francisco?" Can't be more than ten, for sure!
It's a useful API, no doubt, but creativity is required to present the user with any reasonable semblance of the actual world around them at any given point in time.