Draw Something is basically Pictionary. It gives people an excuse to draw, to socialise, and it's incredibly easy to pick up; any five year old can finger paint. It encourages people to do something creative and share it without worrying that it's crap, and that's huge for most people (who don't consider themselves "creative" and are scared of looking like failures). It has serious immediate value outside of itself as a game.

There's no point in being bitter! Getting attention for your work is hard, for sure; there are a lot of games out there and it's a hit-driven industry (with something like 1% of the games getting 90% of the attention). It's something that will come more easily with every project you do as your games get better and you get a handle on what makes people go "whoa", so you've just got to keep trying.

Speaking of eye candy... making your game look nice may feel like a distraction but it's sending a quality signal to people through screenshots, telling people it's been well executed in at least one area so is likely to be well executed in others. It doesn't have to have cheap flashy effects and so on... it just needs to look interesting, different and well-made. There are enough games out there that you probably only have the game title and one screenshot to make an impression, so you need to make it count.

If this project's sapping your energy and you don't really feel like it's going anywhere I'd suggest dropping it and taking a break from development until you feel inspired to start on something new. Once you're feeling inspired again take a hard look at this game, figure out what you could do better and outdo yourself in every single way on the next one. You've already got this far - build on this experience and your work will just keep getting better

A* will find the shortest route unless you implemented it incorrectly. You've got some bugfixing to do. Don't worry about optimisations until you've got it working - it should be finding the path you've indicated.

If a unit has a movement range of 6 then that's 6 squares in every direction which is 168 squares (if I'm not mistaken?) to each run A* on.  Is there a better way?

You don't have to run A* for each square. You just have to do something like A* once, flooding out to touch every square within six steps of the starting position. Use a flat heuristic (so the 'distance to the goal' is always assumed to be 0), ignore all nodes with costs greater than 6 and you'll hit every single node the unit can reach in a single pass.

Self-balancing systems would go a long way - counter systems that punish predictable behaviour focusing on the same few combos, stuff to prevent air juggling and so on.

It would also seem smart to set things up so that you can nerf common features that show up a lot in 'strong' characters found by players. No competitive game survives contact with the player base.

Beyond that one approach would be to, first, set things up so that matches can be run without rendering at many times normal speed. Then develop a suite of characters who encompass the range of possibilities within the system and attempt to balance those.

Then, write AI which can learn how to play a given character optimally. Try to introduce human-like reaction delays, enemy prediction and so on. Confirm that the AI playing the 'balanced' characters against each other produces broadly balanced results (or rebalance those characters as necessary, if the AI shows up interesting possibilities).

Finally: when generating a new character, train an AI to it and test it in a few hundred AI matches against the preset suite of characters (using seeded randomness, avoiding floating point etc so this process is entirely reproducible on different machines). Nerf any moves it uses too heavily and weaken it overall if it's winning too much. (If it's losing too much, don't touch it; the AI might miss something which, if it's strengthened, could really be abused.) This might take a while, so I'd set this final step of character generation up to run in the background while the player's in menus and so on and pop up when it's done.

That might be a bit high level if you never did physics at school.

This set of lecture notes looks useful as a (quite thorough) introduction to classical mechanics. If you can make it through this you'll have a fairly good understanding of movement, inertia, acceleration, vectors, rotation and so on and how to tackle it all mathematically.

http://farside.ph.utexas.edu/teaching/301/301.html

If you find that heavy going, I'd recommend seeking out an introductory calculus text and working through that first (or at the same time). Just for differentiation and integration, you don't need to worry about differential equations and so on at this point.

After you have a solid understanding of mechanics, you should be capable of doing the physics for most 2D games and be fairly comfortable working with physics engines. Real-Time Collision Detection is a great place to go from there, to learn how to tackle the messy problems (or write your own physics engine).

Failure in this feels rubbish. I want failure to be something that builds, a gathering sense of impending doom that instils panic and incites adrenaline. I want to start out feeling like I'm in control and be taken on a journey through my limits to total catastrophic failure.

I want failure to *mean* failure. Massive tailbacks. Cars overheating. People running red lights. I want the screen to be full of cars, with indicators showing dozens more waiting at each entrance, and no-one able to move because the tailbacks from every junction run right across every other junction. Total gridlock. Possibly several things on fire.

When failure finally hits it needs to arrive with hilarious, intractable chaos and a screen-shaking bang, not helpful Traffic Trivia.

Maybe it'd be worth having 'junction stopped' as a third state, so you need to tap twice - to stop the junction and then start it again - to change the junction's state. Cars might take a second or so to react to the lights going red. Change too quickly and you might cause a crash, which blocks the entire junction for five seconds or so while it's cleared up. That'd complicate the game nicely.

Alternative: allow cars to turn left or right at intersections, and give junctions four states: one for a green light in each direction. It's adding more things for people to stay on top of, but it lets you complicate things in interesting ways by adding traffic surges from certain directions with increasing frequency.

Maybe add more complexity as the level progresses. I'd love to see roadworks spring up that take up one lane in the middle of a two-lane street, so you need to control lights on that to allow traffic flow in one direction or the other. I'd love to see a new road blasted through the city adding more intersections.

Finally I think it'd benefit from work on the sound design. It doesn't sound a damn thing like standing next to a street right now, the music's quite a short loop that doesn't really fit the game imo and the 'car reached destination' ding sfx is obtrusive and repetitive. The sound design I'd go for is something soothing, like calming birdsong or (for example) Pachelbel's Canon, overlaid by realistic street sounds like cars passing. This calming auditory experience would be periodically interrupted and then completely drowned out by beeping horns, shouting and so on, underpinned by rising tense/horror/stress music as the screen begins to shudder, corrupt and darken.

All part of the several-minute journey from 'in control' to 'catastrophic failure'.

Sorry - you just have to break it down. That said, a face/face test covers everything - all of the others are just specialisations of a face/face test.

For what it's worth I'm fairly sure the face/face test can be implemented as 8 edge vs. face tests, which can be broken down further as 8 corner vs. face and 16 edge vs. edge distance tests plus 8 edge vs. face intersection checks. Those are fairly simple and I think cover all possible complications.

If the cuboids intersect, just pick an intersection point from an edge/face intersection check. There'll be at least three.

It's a good candidate for a PRNG if its output feels sufficiently random. There are statistical tests for this you can apply, if you like. That's all there is to it.

The magic numbers should have been chosen to make sure the generator cycles through a good fraction of possible 32-bit integers in a non-obvious way without repetition. Large primes are obviously good for avoiding repetition.

You "seed" most PRNGs by starting them with a different value. I assume you're calling something like

Code:

IntNoise(0)
IntNoise(1)
IntNoise(2)
IntNoise(3)

to get a bunch of different random numbers, right? Well, do this instead:

Code:

IntNoise(0+seed)
IntNoise(1+seed)
IntNoise(2+seed)
IntNoise(3+seed)

...and you'll get a different result for each seed. That said, depending on your algorithm you might have to pick quite different seeds to avoid having the same sequences pop up and cause identifiably similar patterns.

Usually you'd use the system time. Create a Date object and seed with Date.time.

Similar initial values shouldn't matter for any worthwhile RNG

edit: maybe run the RNG for a few steps after seeding it if the values take a while to diverge?

Behaviour trees are a form of scripting. They're just particularly efficient/easy to work with for writing AI because they have these flow structures built in that let you consider and reject actions really simply.

Have a look through this, it's a little less abstract.

You can break down actions in three ways:

• as one-off scripts that define the action (eg. a Melee Enemy script which finds an enemy, points towards them, plays an attack animation, yields, tries to do damage a fraction of a second later, and yields until the animation's over)
• by using a generic, parametrised script (eg. playAttackAnimationTowardsEnemy(MeleePunch))
• by breaking the action down into a Sequence of other actions... something like this:
  

Sequence
    FaceTowardsNearestEnemy()
    StartAnimation(MeleePunch)
    Yield(0.4)
    DoMeleeDamage(30)
    YieldUntilAnimationFinished(MeleePunch)

Ultimately the value of behaviour trees is that they make expressing the notion "try something, then try something else if that fails at some point" really simple. The actual execution of actions still comes down to scripted function calls and so on in the same way as usual.

Here's mine. Spent the weekend on it, though I did play around with some advanced mechanics to make things more interesting and use this as an opportunity to play with Pixel Bender. Sorry - I got into it and ended up polishing it a fair bit!

Playable SWF and source code (source code in .zip at bottom of page)

It's in HaXe, not AS3, but they're very similar languages. It also uses some basic engine code I use for all my games.

This queueing discussion wasn't here when I started. I queue one move ahead because pulling off intricate manoeuvres makes people feel awesome, and I want my players to feel awesome. Precision moves in Snake are hard enough. I think it's always worth facilitating awesomeness where you can.

I switched to interpolating the snake's head and tail between movement frames because it felt better and made it easier to time key presses. It's pretty easy to add this just as an interpolation step in the rendering without changing the game logic.

On the design side: My play field's only 18 x 13 and there are five apples, to get people doing lots of tight manoeuvres even when it's easy early on. If the play field's too big and empty there's no urgency to anything and the game becomes a grind to get to the hard part.

Heh - if you wanted exact circular section turns from full speed, you could do something like this:

Code:

maxvel = 10 // maximum velocity
c = 0.1 // acceleration/deceleration per frame

if ( key pressed for accelerating in +x )
  xvel = sin( min( 0.5*PI, asin( xvel/maxvel ) + c ) ) * maxvel
else if ( key pressed for accelerating in -x )
  xvel = sin( max( -0.5*PI, asin( xvel/maxvel ) - c ) ) * maxvel
else if ( xvel > 0 )
  xvel = sin( max( 0, asin( xvel/maxvel ) - c ) ) * maxvel
else if ( xvel < 0 )
  xvel = sin( min( 0, asin( xvel/maxvel ) + c ) ) * maxvel

And likewise for yvel.

Velocity along each axis would follow a sine curve as you accelerate or decelerate, so if you're moving at max. speed in one direction and you let go of that key and start accelerating at 90 degrees, you'll curve round along a perfect 90 degree circular segment.

That'll feel quite "floaty", though, since deceleration from full speed is slow at first.

What are you trying to achieve, exactly?

You should store a camera position somewhere and update it based on the player's position. When drawing anything, draw it at its position minus the camera position. The camera position can lag behind the player, anticipate where the player's going to go, etc; being totally locked to the player makes for a dull camera.

Slicing up the world into columns may be worth doing. See how the size of the world affects performance first. Disabling game entities a distance from the player (or rather, the camera) is sensible regardless.

Your roads will almost certainly need to be higher res meshes than your terrain. The smoother your track is, the easier decent vehicle handling will be. A low-res mesh means every vehicle needs to handle like an off-road vehicle.

I'd suggest generating high-res roads from splines laid along the terrain (as in the third example), then cutting and stitching your roads into the terrain mesh, removing all terrain triangles the roads touch and generating new ones to fill the gaps. Being able to edit the heightmap whilst seeing where the roads will go will help you get everything lining up. Tunnels are a bit more complicated but they're doable.

As for calculating collisions against both the terrain and the road: you'll need to test collisions against buildings, street furniture and other cars as well. Why not just use an existing physics library?

Parking is in short supply in the area. There are often, but not always, one or two spaces somewhere around the Sturton St/Ainsworth St/York St area east of CB2 (though half of Sturton St is residents permit only). This is around half a mile from CB2 and half a mile from the hostel.

The nearest place for easy free long term parking is probably the Rustat Rd/Coleridge Rd area south east of the train station - the southern halves of those roads, and the roads between them. This is around 1.5 miles from CB2 and 0.7 miles from the hostel, both via the foot bridge over the railway.

If you want console development experience, don't bother with XNA. The main issues in serious console development are console-specific APIs, console-specific hardware quirks, inadequate tools, hard memory limits and TCRs. An XNA game uses XNA APIs, probably won't push the hardware very much, has different tools to normal console games development, requires different memory management techniques (since it's in a garbage collected language) and isn't subject to TCRs... so while it's nice in principle, it's not really the same thing.

Similar issues with PS3 linux games... I don't think you even have access to hardware accelerated graphics there.

All you really need to do to support porting a game to consoles (besides working in C++) is, firstly, be careful about memory usage; and secondly structure your game so it passes, or can easily be adjusted to pass, TCRs. As far as TCRs are concerned, you need to be an approved developer even to find out what they are. You'll just have to try and enjoy the surprise when you get there.

If you have a few decent games out, you could contact Sony's Pub Fund - they're generally on the lookout for cool stuff for PSN and Vita. If approved they'll give you access to devkits and the cross-platform PhyreEngine. A PS3 devkit these days is $2,000, so not crazy money. I think Vita devkits are around the same. I know that's more than you'll want to invest, but it's not a huge barrier if you get to the point of making games for a living.

The Unreal Engine supports PC, Mac, 360, PS3, Vita, and these days Android and iOS. If you've made a game on Unreal and you get a console devkit and want to port it later, it'll be about as easy as it would be with any other engine. The main thing is support scaling down to the capabilities of console hardware, most importantly RAM. Unreal 3 is free for non-commercial use and you can get a commercial license currently for "$99 USD, and 25% of all income above $50,000 USD".

If you just want to see your code running on a console for fun times though, XNA or PS3 linux is your cheapest bet. They just won't teach you much that's useful for porting a game to consoles later.

But... you know, porting successful indie PC games to consoles isn't something that really happens. It's a huge amount of hassle and the platform holders aren't really interested in indie games that have already come out. Consider that even Minecraft isn't available on a console yet (though it's planned to come out soon) and you start to get an idea of the barriers in the way. The two most likely paths to console development are either joining a console games development studio or establishing yourself as a competent indie developer and pitching a *new* project to a console manufacturer which will be made primarily for that console.

I've known gameplay programmers to end up spending all their time writing Lua, but they still needed C++ knowledge to get the job. Big studios are mostly C++ shops. If you can't hack C++ you can't do "general programming work" there when necessary and that means you're much less useful.

Python and SWIG can do what you want. You can even create a class on the Python side that inherits from a C++ class, have it override virtual functions etc and (with the 'directors' feature enabled in SWIG) it'll all work nicely. There's support in there for all kinds of magic.

It's messy to implement, sure, but there's plenty of documentation. If you go down that route I recommend just making time and reading for a while before diving in.

[Simulate at 40Hz.]

Whoa. Your physics is a bit strange. If you'll have to work with this for a while in future, I seriously recommend picking up a few books on calculus and learning integration (the science of "approximating piecewise linearly as we step forward in time") so you can get this stuff right. Then you'll have to work out formulae for framerate-independent physics which are compatible with how it was acting before, which will be fun.

Anyway, here's an example of basic integration for ya:

x = x + v*dt + 0.5*a*dt*dt;
v = v + a*dt;

I don't care how many timesteps you use or how big or small they are, in the case of "0m/s at 1 m/s/s over 1s" you will always get x = 0.5m and v = 1m/s after a second by repeatedly applying those two lines in that order.

Of course, maybe you just need to get this rendering in a framerate independent way and don't really want to go into overhauling the physics to achieve that. If so, here is what you need to do:

- Simulate at 40Hz. Every time you cross another 25ms boundary, simulate another frame. However, keep the positions of all objects from the last frame.
- When rendering, interpolate linearly between the old position and the new position.

Something like this:

Code:

timestep = 1/60;
simulation_timestep = 1/40;

while (1)
{
    time += timestep;

    if ( time > latestSimulationFrameTime )
    {
        previousSimulationFrameTime = latestSimulationFrameTime;

        simulateNextFrame(); // Run the old simulation code.

        latestSimulationFrameTime += simulationTimestep;
    }

    // How far are we between simulation frames?
    frameInterpolation = (time - previousSimulationFrameTime) / simulationTimestep;

    for ( each object in scene )
    {
        latest_pos = object.pos;
        previous_pos = object.previousPos;
       
        interpolatedPos = frameInterpolation * object.pos + (1 - frameInterpolation) * object.previousPos;

        object.renderAt( interpolatedPos );
    }
}

If it's a portfolio site to accompany job applications, make the Games page the main page. The News page isn't really relevant.

Run spellcheck on everything. Also be more careful with grammar. The very first game listing has two errors - "Developement" and the space between "hours" and the following period. This may seem petty, but people will notice attention to detail and ability to communicate clearly.

Why are game screenshots colourised/desaturated until you mouse over them? It certainly isn't tying them into your page's colour scheme. Use the full colour version of the image all the time.

Some of these were team projects and some of them were individual projects, right? You need to say how many people worked on each and what your role was.

The second button to the right of "Hero Battle Arena" - what the heck is that? A button that says "Images" would be a great deal clearer.

It's not at all obvious that you need to click on the image to get information about a project. Add an explicit "more information" link or button for each project. I'd also suggest putting a one- or two-line summary for each on that page detailing what it is exactly and what you did on it.

What are your most important and impressive projects? Put them at the top. I'd also suggest removing any project which you aren't willing to show off yet with a playable version, trailer or similar.

The "Play" link for "Sand is Everywhere" leads to a page where the game doesn't load.

Given that your portfolio site is in English, the "Play" link for "Viskan" should lead somewhere where you can start it running without having to be able to read Swedish, even if the game itself requires Swedish language skills.

If you respect your team-mates, you'll know that an idea isn't a good idea unless it's obviously a good idea to them, too.

When you're collaborating, you need to make decisions and act as a team. If you've got a disagreement about design direction, you as a team clearly need more information to make a decision. So mock up both options. Implement them. Playtest them with various people. See which people engage with more and go with that.

Or talk it over and discuss variations on each idea, or combinations of both, until you come to something you all like.

It's perfectly possible to have multiple designers on a project with no friction if they're willing to learn from each other, able to put aside their own egos and okay with being proven wrong. If you believe in something, try it out - and be ready to throw it away if it doesn't work.

Assigning a design lead to make decisions may be quicker, but a way of working which lets you use everyone's design sense and assess the merit of different concepts objectively will make your game better. Team members who have design input are also more likely to stick around than team members who've just been told "we're not using your idea, because I say so".

(If someone wastes a lot of time pushing the team down dead ends, that'll rapidly become apparent. Either they'll notice it too and ease up or you can drop 'em.)

This is not abstract stuff. I've shared design responsibility with collaborators on a few projects recently, including one entire game start-to-finish, and we've always been able to resolve these issues through discussion, prototyping, and trying things out.