Proving quite fun just playing around with it and testing different jumps:
Two jumps in a row using the same algorithm, but it aims your jump based on where you’re looking when you hit the spacebar. In this case, second jump I flicked the mouse up at last moment before jumping, giving a higher/longer arc:
Things I had to do to fix Unity long-standing bugs (that Unity has declared they’ll never fix). Most of these copy/pasted from my “Fix Unity Bugs” folders in other Unity projects ;)…
Customize GameObject to add: Find a specific Component on “the nearest ancestor that has one”
Customize GameObject to add: When creating a game object, always place it at 0,0,0, instead of “in the middle of nowhere, randomly”
Fix fonts so that they DO NOT render through walls (Unity makes everything in your scene transparent-to-text)
Auto-rescale all textures on scaled objects (Unity’s editor won’t allow you to scale a single object without scaling its fixed-size, tiling texture (and without breaking all your other objects) – but Unity source code strangely does allow it)
(if you like this idea, please re-tweet this to vote for it – I’ll decide which to do based on which one(s) people like most) Other ideas: “Runners”, “Follow”)
Premise: what makes an FPS unique/special among games is the visceral, immersive nature.
But our FPS’s today all project the same, boring, 1:1 flat rectangle as our window on the world.
What if we had eyes on the side of our head? (a la most herbivores – you can see to both sides, and halfway behind you – but have a blindspot dead-ahead. This is why some birds flick their heads left and right all the time – they physically can’t look directly ahead!)
What if you were a Beholder – with 360 simultaneous vision. Looking ahead, behind, up and down all at once?
What does the world look like when your camera is 2 inches off the ground? (a rat’s-eye-view) … or upside-down, attached to the ceiling? (a spider’s…)
In Metamorphosis, you start in a lab with one way out: a small mouse-hole in the skirting-board. A theft gone wrong, a wizard about to catch you “in flagrante”. You have only one chance: a giant bubbling flask labelled “Rat”. You gobble the potion, dive through the hole, and escape.
…but now you’re a rat, loose in a dungeon full of nasties. Absolutely everything out there is bigger, meaner, and (often) uglier than you. And sadly: loot won’t be much good, since you’re too small to wear armour, and have no hands to hold a sword.
It’s a dungeon-hack with a difference: you’re looking for magic potions that metamorphose you into new and useful creatures. When you metamorphose, everything changes:
the lighting (some creatures see by light, bats echo-locate and see only monochrome, other creates have infra-vision/heat-sensitive vision)
the viewpoint (high, low, upside-down)
the number of simultaneous “cameras” (one per eyeball…)
the “lens shape” of each eyeball (normal, fisheye, warped, 360-degrees…)
your strength/speed/vulnerability (heavy/light, low hitpoints / high hitpoints, regeneration…)
movement abilities (walk, jump (rats jump so high they almost fly…), fly, wall-walk, etc)
An old friend of mine wrote a real-time 360-degree FPS projection 15 years ago, and kindly dug out his original source code + demo app for me. With his permission, I’ll post it here ASAP, but suffice it to say: this stuff is doable, it may sound a bit crazy, but I’ve experimented with it (a little) before.
Upgrades and weapons
…entirely dictated by the creature you’re currently polymorphed into.
I like this idea because:
…polymorphing is fun.
…there’s historically been very little experimentation with FPS cameras – the best you can hope for is some post-processing screen effets (depth of field, over-saturation, blur, desaturation)
(I especially like the second clip – this is the point at which we first get proof that the film can’t quite be real; it’s the first leap down the rabbit-hole…)
Runners is simply an excuse to do desperate, death-defying, running jumps from rooftop to rooftop, while being shot at (and shooting back).
Challenges to the player
Moment to moment during the game, the player has the following decisions:
Big jumps require big runups; you get faster the longer you run (Super Mario Bros stylee). Better plan your run-up, and don’t chicken-out and slowdown at the last minute!
It’s easy to stand-still and snipe: so we make you invulnerable while in mid-air, and create lots of obstacles on the rooftops, that prevent “easy” shots from a distance
You can’t jump forever (remember the bad old days of deathmatch quake bunnyhopping? Ugh). You have a fatigue meter that forces you to periodically stop and hide while you get your breath back
“Guns. Lots of guns” – long distance, wide-open spaces, enclosed target areas? This is a perfect excuse for overblow weapons of insane destruction. Remember Syndicate’s supremely over-the-top Gauss Gun? Oh yeah!
Three conflicting tensions (no upgrades in this one! Just choice of weapons):
Movement: speed, jump-distance, acceleration (run-ups) … heavy weapons = fail
Accuracy: sniping and head-shots requires keeping still, keeping fatigue at a minimum (no jumping for a while!)
Positioning: is it better to circle round behind an enemy and catch them unawares (lots of jumping, weak weapons) … or go straight at them, guns blazing, and try to scare them into running while tired (they fall to their death)?
Premise: what makes an FPS unique/special among games is the visceral, immersive nature. Almost every *other* genre of game gives you 360-degree vision. This was originally to compensate for the way “a computer” fails to use most of your human “peripheral” senses (depth, perpheral vision, positional sound, etc). The most obvious difference with FPS’s: you can’t see what’s behind you.
In most FPS’s, you only have to worry about your own skin. You spin around frequently to check no-one is sneaking up on you. You strafe round corners so that a head-on enemy doesn’t get a chance to blindside you as you slowly rotate around the corner. Stealth games let you “lean” to make up for the danger of corners.
Follow is different: you are invulnerable, and you’re being followed by creatures you’re trying to rescue / lead to safety. Because they’re always behind you, you cannot see when they’re being attacked – you can gun down all opposition, then turn round to find out everyone’s been eaten behind your back.
But if you walk backwards everywhere, you’re bound to fall off a cliff, or run into an enemy and only notice it when your followers go down in a hail of fire.
Challenges to the player
Moment to moment during the game, the player has to compromise between the following tensions:
Avoid static obstacles/dangers (look where you run) … vs … prevent followers from wandering off (look behind you, at followers)
Takedown enemies (charge forwards, run around obstacles) … vs … lead carefully (avoid leading your followers into traps / fields of fire)
Hands-off (followers wander and get into danger) … vs … Hands-on (use non-lethal weapons to herd and cluster your followers, so you can keep them alive more easily)
Get to level-end / safety quickly (lose lots of followers) … vs … slow, stealthy “no man left behind” (slower and painstaking but higher success rate)
Three interwoven upgrade paths:
Relationship with followers: trust/obedience
At end of each level, you get cash in a virtual currency based on how many followers you rescued, how quickly – and how much they like you.
(if you got them to the end by bullying … they won’t like you so much as if you gently nudged throughout)
Potentially: various unique weapons only “unlocked” when you achieve difficult non-shooting things, e.g.:
Complete a level with 100% survival of followers
Keep followers at 90% or above happinness for 5 levels in a row
Complete a level in under 50% of the “par” time
Ideally, those weapons would be complementary to the achievement. e.g. for the “complete a level fast” award, you’d get something that made it easier to complete levels stealthily (you’ve already mastered “moving fast”, so this gives you something valuable).
…also: if you don’t like playing fast, this gives you a high cost/reward incentive to do so: you want to play stealthily, you want the uber-weapon for stealth … so you need to take a break from stealth-play to go earn it.
I like this idea because:
…it’s an FPS about protecting people, rather than slaughtering them
…it emphasizes the vulnerability of “people other than myself”
…it demonstrates that making yourself into a super-soldier may be ultimately useless and unrewarding
…it makes the purely-tactical parts of an FPS a lot more strategic, as core gameplay – rather than relying upon “map design” and/or “multiplayer team tactics” to provide all the strategy
It’s a well-written article, with some great illustrations. But the authors “Components” struck me as over-complicated and too behaviour-focussed. If you’re designing a game based on an ES, this isn’t a great way to do it – it feels too much towards old-style OOP gameobjects.
This is an opportunity to talk about good and bad directions in Component design. I really like the author’s idea of using Bomberman as a reference – it’s simple, it’s a well-known game, but it’s got a lot of depth. Read the original article to refresh your memory on Bomberman and how it works. Then come back here, and we’ll do a worked example on choosing components for a game. I’ll completely ignore the programming issues, and only look at the design issues.
OK, a completely different approach this time (based on the “new technique for Render to Texture” that I mentioned last time). And it works a lot better – lighting, shaders, etc is all there for free (but something is wrong with the side-to-side)
The total dev team for Skyrim (TES 5) is 90 people (less than normal for this size game)
Oblivion (TES 4) had a mere 45 staff!
They strategically embrace modular levels as the way to produce enough content in time
…Added together: explains the recurring Art problem in Elder Scrolls games, where after an hour or so everywhere starts to look very similar
…NB: while I resent that (and I know many people who won’t play the games, they hate it so much), the tradeoff is IMHO worth it: broad story-content in a huge world. So it’s a big loss, but a compromise I’ve always been willing to accept as a player
…in the article, they call this “art fatigue”
Allegedly only in Skyrim (but … I’m sure I saw this in Oblivion too), they put arbitrary-rotated wall segments inside rooms to break the sense of “rectangular” walls everywhere. They called this “Shell Based” building
“It’s common at the start of a project to strongly associate a particular setting with specific types of inhabitants or gameplay. You may want to only see soldiers in military bases, and zombies in crypts, for example. Resist this.”
…IMHO: obvious (it’s basic art-composition theory), but worth pointing out to anyone non-art background looking at game and level design
There was some pushback in the team against mix/matching modules from different kits: “The notion of [an artist’s] art being used in unforeseen ways could lead to bad intersections or lighting issues, for example.”
…Stupid of me, I’d never thought about how the team artists would react to this kind of mix/match (the only games I’ve worked on with modular art kits … were 2-3 person indie projects, so the atmosphere was very different)
…This also explains a *lot* of the geometry bugs in TES games (where you get stuck in angles of the wall, temporarily, or items drop in places you are blocked from reaching for no apparent reason): the combination of assets wasn’t designed-for / tested-for, so there were bajillions too many combinations to test!
“when you’re trying to identify somebody with the the aptitude and interest to be a great kit artist, you’re basically looking for a unicorn. They’re rare.”
The author initially cites this with respect to:
“the same rock or farmhouse or tapestry used again and again. And another two dozen times after.”
…IME, that’s not the problem at all. The problem is that every internal environment appears to have bought their walls, floor, and ceilings from the same branch of Viking Ikea ™. As demonstrated in the screenshot of “blatantly modular pipes” in the article:
…and when talking about Oblivion, it sounds like my experience was reflected in their testing with large groups of players too:
you’re more likely to pick up on repeated clutter first, then the repeated architecture. This is especially true in actual gameplay from a first-person perspective. To minimize needless repetition, we abolished the use of warehouse cells as they existed in Oblivion.
To be honest, I’ve long been surprised that Bethesda stuck with “square-based grids” for so long (other games were using non-square grids decades ago). As one of the commenters points out:
Square meshes and ‘cubic’ tile-blocks on naturalistic indoor environments (eg natural caves) can be a challenge – how about equilateral triangular meshes, or for 3d space rhombic-dodecahedrons? – Xu En
Common AAA art/design/level-design problem: handoff
This is rarely written about but the kind of thing that Leads, Producers, EPs and Project managers spend ages dealing with:
“They’ll do an art pass and make the level visually appealing Once they’re at a place they’re happy with, they send it back to design for final markup and scripting. Once design has done that, the level should theoretically be done – right?
Not usually. Level designers often inherit a litany of unforeseen problems when receiving final art for their levels. Cover along a street has been converted into poles too thin to take cover behind. A wall intended as a visual blocker is now a see-though chain-link fence. A bridge now has support beams which occlude sight lines in a major gunfight you had planned.”
Common level-design problem: reference sizes
Obviously, you need to know how “tall” your characters are. But how do you translate that into a practical measurement when working on a scene?
“One thing we’ve found very useful is to determine a uniform dimension for door frames. This has a few benefits. It allows us to transition from kit to kit without unique pieces, as well as allowing easy re-use of doors between kits. More importantly, it gives AI and animation a fixed standard to work from, which can be reinforced throughout the game.”
A little bit of the Agile/Scrum mindset
Some of their approach is inherently Scrum:
“we get our kits to a “functional-but-ugly” state as soon as possible”
“The level designer should be constantly stress testing throughout these stages. The artist should deliver pieces as soon as they are even rudimentarily functional, and the level designer should use them in non-ideal conditions. ”
They don’t go into detail, but imply that this has caused a lot of friction in the past with individual developers who found it emotionally difficult to work in this way. I would have liked some more info on that – dealing with this kind of “mindset” issue on game teams is a major challenge.
(unsubstantiated, but hilarious): “If the measurement is close enough to the surface, light rays can curve downward at a rate equal to the mean curvature of the Earth’s surface. In this case, the two effects of curvature and refraction cancel each other out and the Earth will appear flat in optical experiments.”
…”an increase in air temperature … of 0.11 degrees Celsius per metre of altitude would create an illusion of a flat canal, … [or if] higher than this … all optical observations would be consistent with a concave surface, a “bowl-shaped earth””
…”Ulysses Grant Morrow, … found that his target marker, eighteen inches above water level and five miles distant, was clearly visible he concluded that the Earth’s surface was concavely curved”
(the history of maps and globe representations of the Earth is full of wonderful things like this)
“Tomb Raider triggered me, sure. But it didn’t do it needlessly. It didn’t do it tactlessly. It didn’t do it for a cheap rise. It instead captured a real emotion and a real experience millions of women will encounter in their life. Some of them won’t be as lucky as I was. Some of them won’t be as lucky as Lara Croft was, either. Some of them won’t survive. Some of them will be silenced forever.
Some of them will die and some of their attackers will live.
Tomb Raider triggered me and that’s ok. Maybe that’s even good. I think it is because it means it’s the first realistic, non-gratifying portrayal of violence against women that I’ve seen in video games. It’s the first one I’ve seen that wasn’t exploitive.”
Carlo Delallana responds to the sensationalized report that “I think most game designers really just suck”:
“One of biggest problems that game designers face in their path towards mastery is respect. It’s easy to respect an artist with a demonstrable skill, no average person assumes they can do what an engineer does. But game designer? For one thing our profession faces a common misconception, that game design is coming up with ideas (as noted by Garrott’s comment on lazy designers). That all you need to do is clone, that you are no better than your competition (as noted by Mark Pincus).
We are a compromised profession, tasked at executing a formula to minimize risk. Unfortunately, executing on formula is counter to mastery of any skill. If the marching order is “status quo” instead of “challenge yourself” then how does a game designer grow?”
(NB: Gamasutra clearly did the IMHO scummy journalist thing of sensationalizing RG’s quote; and RG should have been a lot more careful – personally I believe he didn’t mean it the way it came across, but it came across … badly)
The students chose to focus on a game that would help other students revise the “Momentum” part of GCSE Physics.
In summer/autumn 2012, they learnt the basics of game design and development. We didn’t do any formal teaching – they simply had to pick up the skills they needed as we went along. YouTube videos, and “trial and error”, were our primary techniques…
By the end of 2012, they’d written their own physics engine, some basic gameplay, and a simple simulation of an exercise/problem in Momentum.
The big thing this month has been BETT. Pearson had a large stand, and asked the students along to talk about the project. They gave an excellent presentation to an audience of approx 30 people at BETT, covering the background and some of the things that went well, that didn’t, and what they’d learnt from it.
Leading up to BETT, they worked hard to squeeze in a new build of the game, with a rethink on the interactive sections and how they hang together. Unfortunately, we hit what seemed to be a major bug in Unity’s camera-handling, and none of us could fix it in time (nor could we get an answer from Unity support in time). But the students managed to invent a workaround at the last minute which worked fine for demoing at BETT.
The game isn’t finished yet – GCSE’s and schoolwork left too little time to complete it before BETT – but we’re very close now. The students are aiming to finish it off this month and next, and I’m hoping I might even be able to take a copy to the GDC conference in March (taking place in San Francisco, GDC is the commercial games industry’s main annual conference).
In the meantime … you can sign up now on the Quantum Games website (http://quantumgames.co.uk), and we’ll email you as soon as the game is ready – or sooner, with a private beta-test!
Unity’s QA dept needs a smack up-side the head. If you get this bug, you’re a bit screwed – the only “fix” is to go into system settings and wipe Unity’s crud.
type == kMetaAssetType && pathName.find (“library/metadata”) != 0
Thanks, Unity, that’s very human-readable and helpful. Not.
(appears to be an Assert written by a junior programmer – or a debug-only Assert that got left in the shipping version(!))\
Unity’s tech team wrote Unity 3 so that it would open projects BEFORE checking if there was a new version available
Unity 4 is NOT backwards compatible; it corrupts projects so that they will NEVER load in Unity 3.x
…also: Unity 3.5 will FATAL CRASH if it tries to open a Unity 4 project
Unity (generally) is badly written and auto-opens the last project, even if you don’t want to, and EVEN IF ITS CORRUPT
Unity (generally) DOESN’T BOTHER to offer any way of starting “safely”
Solution (OS X):
Force-quit Unity (not only does it crash, but it hangs forever) – RMB on the icon, hold down alt/option, and the Force Quit option appears
run Finder, go to (your user)/Library, aka “~/Library”. If you don’t know how, then do ONE OF the following (either works):
EITHER: Start at your username folder (it’s the parent folder of your Desktop folder, parent of your Documents folder, etc), un-break OS X (Apple ships it as broken-by-default): google for “enable see Library folder in Finder”, follow the instructions
OR: In Finder’s “Go” menu, select “Go to folder”, and type “~/Library”
Inside Library, find “Preferences” folder
Find *everything* that begins “com.unity3d.” and delete it (there are approx 20 files, of 2 different file types)
Re-start Unity, and it will open the default project
…And this time, Unity will offer to upgrade to Unity 4
For bonus points, the Unity 4 “upgrade” isn’t an upgrade: it’s a replacement. I expected it to download “the bits that have changed”. Nuh-uh. One gigabyte download! (try getting that in a hurry, when your project has suddenly imploded in front of you, because of the non-existent backwards-compatibility :( ).
Some idle thoughts…
I’ve seen similar behaviour before when writing very simple OS X apps. There’s some massive bugs in Apple’s code that have been around for 5+ years (and Apple shows no intention of fixing), which cause “startup actions” to happen in a semi-random order, depending on the NAME and NUMBER of recently-opened projects.
It takes very little testing to discover this. If it’s the problem with the Unity software, then Unity needs to seriously improve their testing on OS X – they should have discovered this easily.
But also … why on earth are they using the NSDocument loading system? Apple never finished writing the docs for it, they seem to have never finished implementing it (major bits of the API seem to be missing) – in general, OS X authors don’t seem to use it any more. Probably because it doesn’t work?
I noticed a few months back that Pat Wyatt has been blogging rgularly and in a lot of detail last year. This (IMHO) is big news: Pat is an awesome developer who held key positions in the teams behind many of the bestselling computer games (e.g.: Diablo 1 + 2, Starcraft, Warcraft) and went on to co-found Arena.Net (creators of Guild Wars).
I worked with him briefly in the past, and he’s friendly and full of advice and knowledge – but while he was happy to share, IIRC it was rarely in published form.
I’ve had a tough few months, but I’ve been dipping into his blog a few times, and it delivers in spades. Here’s a few hilights:
Assertions: enable them in live builds
(I’ve always felt this was the “right” way to do it for servers – where you don’t have to worry so much about frame-time, and assertions are more valuable at runtime because they help with the hardest-to-trace bugs … but it’s hard to get broad data on what the performance cost is) http://www.codeofhonor.com/blog/whose-bug-is-this-anyway:
“The bug was easily fixed by upgrading the build server, but in the end we decided to leave assertions enabled even for live builds. The anticipated cost-savings in CPU utilization (or more correctly, the anticipated savings from being able to purchase fewer computers in the future) were lost due to the programming effort required to identify the bug, so we felt it better to avoid similar issues in future.”
…and a great rule of thumb for any Programmer:
“After my experience reporting a non-bug to the folks at Microsoft, I was notably more shy about suggesting that bugs might be caused by anything other than the code I or one of my teammates wrote.”
“Mike O’Brien, one of the co-founders and a crack programmer, eventually came up with the idea that they were related to computer hardware failures rather than programming failures. More importantly he had the bright idea for how to test that hypothesis, which is the mark of an excellent scientist.
He wrote a module (“OsStress”) which would allocate a block of memory, perform calculations in that memory block, and then compare the results of the calculation to a table of known answers. He encoded this stress-test into the main game loop so that the computer would perform this verification step about 30-50 times per second.
On a properly functioning computer this stress test should never fail, but surprisingly we discovered that on about 1% of the computers being used to play Guild Wars it did fail! One percent might not sound like a big deal, but when one million gamers play the game on any given day that means 10,000 would have at least one crash bug. Our programming team could spend weeks researching the bugs for just one day at that rate!”
AI cheats to improve game balance in RTS’s, starting with Warcraft/Starcraft
In most Warcraft missions the enemy computer players are given entire cities and armies to start with when battling human players. Moreover, Warcraft contains several asymmetric rules which make it easier for the AI player to compete, though these rules would perhaps be called outright cheating by most players.
One rule we created to help the computer AI was to reduce the amount of gold removed from gold mines to prevent them from being mined-out. When a human player’s workers emerge from a gold mine those workers remove 100 units of ore from the mine and deliver it back to the player’s town hall on each trip, and eventually the gold mine is exhausted by these mining efforts. However, when an AI-controlled worker makes the same trip, the worker only remove 8 units of ore from the mine, while still delivering 100 units into the AI treasury.
This asymmetric rule actually makes the game more fun in two respects: it prevents humans from “turtling”, which is to say building an unassailable defense and using their superior strategic skills to overcome the computer AI. Turtling is a doomed strategy against computer AIs because the human player’s gold-mines will run dry long before those of the computer.
Secondarily, when the human player eventually does destroy the computer encampment there will still be gold left for the player to harvest, which makes the game run faster and is more fun than grinding out a victory with limited resources.”
NB: first half shows: “Collect the fish, avoid the dynamite, grow bigger!”
Second half shows: “if you hit dynamite, you shrink; when you’re tiny, if you hit dynamite, you’re fishfood :(”
For the love of … WHY?
Because I entered a voluntary “48-hour game jam” (you have one weekend to make a game), and last time I went to the Apple shop for a repair, they dislodged my network card. It fell out, internally, and it’s not user-fixable (believe me, I tried – even specialist screwdrivers aren’t enough :( ).
So I did something else with my weekend. But a few hours before the competition deadline, I figured “what the heck; what could I do in a couple of hours?” … with some encouragement from The Mighty Git.
222 lines of code, including comments, blank lines – and code that I commented out because I replaced it with other code.
That’s all it takes for a working, playable, iPhone game.
…and the art?
You can’t see it from the video, but the art is resolution-independent – as your whale gets bigger, it re-renders, so that all the curves ALWAYS have razor-sharp edges. No effort required on my part.
I did all the artwork in Inkscape (free image editor for vector images), and saved as SVG (web-standard for vector images).
Then, courtesy of the open-source SVGKit project (renders vector images on iOS, because Apple doesn’t add support to their libaries – shame), and the following few lines of code:
If that looks rather like using a built-in UIImage and UIImageView … it’s because it’s intended to. SVGKit adds a new type of image – SVGKImage – that’s almost the same as an Apple UIImage, except it’s better (it’s resolution independent). And the SVGKImageView does for SVGKImage what UIImageView does for UIImage…