The unfortunate truth about the AAA games industry these days is that it's completely controlled by the publishers and the relationship between publishers and studios is parasitic rather than symbiotic.   I don't think most publishers even think in terms of studios these days but only in terms of game franchises.  Once a franchise falters they have no issue with chucking the studio and all its employees out with it. 

Studios making AAA titles have huge upkeep rates and sadly most publishers simply don't think it's worth investing in those studios and paying those upkeep rates whilst they're between franchises in the hope they'll come up with another killer franchise.  It's simply less of a gamble to cut them loose and buy up another studio with an existing new prototype which has franchise potential.  The only way for studios to combat this is to attempt to develop new ideas and prototypes on the side whilst working their current project so they immediately have something new to show when one project ends.  Publishers will rarely give allowance for this though and the pressure on time and resources from the extreme quality bar, moving feature goals, and tight deadlines on the current franchise set by the publisher can be so great than many studios simply cant develop such side projects whilst keeping the publisher happy. 

Sadly it's also not viable to break away from publishers and still develop AAA titles since the cost is far too high, and even if you could raise the money I wouldn't recommend going 'all-in' which is what it would likely take since the industry is far too fickle to take that kind of risk on.

I guess what I'm saying is, I liked your article, but if you're a AAA studio it's probably all futile anyway.

The FabFilter EQ, compressor, and limiter have become staples for me, I use them all the time in everything, and I've demoed their Saturn saturation plugin and was very impressed by it, thinking of picking it up sometime.

Other util stuff that I've found very good and I use a lot have been Cableguys Volume Shaper and Pan Shaper.

I'm still in love with Ohmboyz for delay, it's pretty old now but still great, and SugarBytes WOW filter is highly recommended.

For synthesis I used to stick to NI Massive for sounds I wanted lots of modulation control over, and LennarDigitals Sylenth for virtual analogue and virus emulation.  I've now replaced these with XFer Serum and Reveal Sound Spire respectively, they fit the same role as their replacements but are much better modern synths.  The older two are still worth a look in if you're on a budget though, you might be able to snag them for a good price now.

The worst thing that can happen for you is to be trapped into a project without the funds to do it justice or the feeling that you're getting under-payed for your efforts.  Therefore don't be afraid to ask a publisher for too much money, they wont be offended and if they're interested in your game they'll make a counter offer. 

Work out how much you'll need for paying additional staff or purchasing all the resources you'll need to make the game to a quality level that you're happy with, then add on how much you'd like to be payed for your own time for the duration of the project, then triple the result and offer that first.  A little bit of simple back and forth with the publisher over funding can net you a lot more money for your work for a minimal amount of effort.  If the publisher is genuinely interested in what you're offering they wont be scared off by that, it's a process they go through all the time with other studios / developers.

I generally just go for a really simple state machine, something along these lines:

Code:

class State
{
public:
virtual void Initialise() = 0;
virtual void Update(float deltaTime) = 0;
virtual void Shutdown() = 0;
};


class StateMachine
{
public:
StateMachine(State* pStartState)
: m_pCurrentState(nullptr)
, m_pNextState(pStartState)
{
}

void SetNextState(State* pState)
{
m_pNextState = pState;
}

void Update(float deltaTime)
{
// change state if one is queued
if(m_pNextState)
{
if(m_pCurrentState)
m_pCurrentState->Shutdown();

m_pCurrentState = m_pNextState;
m_pNextState = nullptr;

if(m_pCurrentState)
m_pCurrentState->Initialise();
}

// update current state
if(m_pCurrentState)
m_pCurrentState->Update(deltaTime);
}

private:
State* m_pCurrentState;
State* m_pNextState;
};

I queue the next state until the next frame so that I don't end up potentially shutting a state down part way through an update which can cause headaches.  Obviously you'll need to manage the memory on your states but if you don't want them to be persistent then you could delete them after the shutdown.

That explains a lot.  Still love it though

OMG you put Voyager first???  The only good thing about Voyager was the emergency holographic doctor, the best startrek character ever btw (closely followed by Quark), but all the scenes he wasn't in were pants, the rest of the crew were weak.  Babylon 5 was the bomb, but what was the deal with them blowing their load on the big climax far too soon and then following it up with a really crappy plotline to take it to the end?

This looks really good, I'm loving the concept.  Do you mind if I ask you a technical question?  When you split a sphere up into hexagons you also end up with a few pentagons in places.  Is that an issue you're dealing with or have you found a way around it?

I was stopped in the street on my way to work yesterday by an old man with the morning news paper in his hands who started angrily shouting at me "This is bullshit, they're still going to be letting 'them' into the country" and so on after clearly having just read the report that free movement of labour would still be in effect.  That really summed the whole thing up for me.

I'd say the best way is a have a separate camera which renders your 2D snake scene to a render texture then use that texture on the screen face of your arcade machine in the 3D scene.  If you use a different layer for all your snake objects and set the culling masks appropriately on your cameras then the two scenes wont interfere which each other.  Doing it that way it also becomes easy to add scan-line and other CRT monitor effects to your arcade machines screen by using post processing effects on your 2D camera.

I'd try something like this:

1) Pick a random land cell and assign it an island index of 1.  Walk all joining land cells assigning them the same island index until all adjoining land cells have been visited.

2) Pick a random land cell that hasn't yet been assigned an island index.  Repeat step 1 starting at this land cell but with an island index 1 higher.  Keep repeating this step until all land cells have been assigned an island index.  You now know which island each land cell belongs to.

3) For each land cell calculate the closest land cell to it from a different island.

4) Pick the land cell pair with the smallest distance and bridge the gap between them.  You could use something like Dijkstra's algorithm for this (this algorithm would also be handy for calculating the closest distances for step 3).  Mark these two islands as being connected to each other.

5) Repeat step 4 ignoring any closest cell pairs belonging to island pairs already connected, or islands which are connected through shared connected islands.  Do this until all islands are connected.


If you want two bridges you can repeat the above for a second time but perhaps modify your distance calculations for step 3 by their proximity to an already existing bridge so the second set of bridges will be spread out compared to the first.

This is a really cool thread.  Thanks for the effort gimymblert 

First time I've seen this, it looks stunning, great work

[[survival]]

I used to be obsessed with Shmups, mostly scrolling bullet hell style ones but I played arena shooters too.  I still love em but don't play them quite as compulsively any more.  Anyway, in my opinion there's three things that really make shmups tick, usually experience in this order:


[survival]
You should constantly feel under threat of being killed and its only your skill and reflexes that are keeping you alive.  The game should be balanced to keep a continuous and increasing pace without lulls so that the player is constantly challenged (with the possible exception of adding a brief pause to build suspense before a big boss fight or something).  The player must also be given the tools to deal with this pace.  This means giving the player precise and instant control over their craft to allow for skin of the teeth dodges and squeezing though impossible gaps.  Momentum, non-linear controls, or interfering with the player's controls are a no-no.  Also important is having no cheap or unfair deaths, all causes of death should give the player a chance to avoid them before they strike.  Get the balance of threat and survival right and your players will feel excitement when playing.


[mastery]
The game should be build using a consistent visual and game-play 'language' that the player can start to understand through practice and repeated play which they can then use to improve and get better at the game.  For example each type of enemy should have their own attack pattern which they always use, certain enemy combinations should always appear together, powerful attacks should always be telegraphed first, etc etc.  Using a consistent language allows the player to improve their chances of survival by learning strategies to deal with specific enemies or situations.  This is what will over time bestow your players with a sense of achievement.


[risk]
Once players start to gain mastery over certain enemies or levels they can feel uninteresting when you encounter them again because they are no longer a threat.  By building an additional layer of risk vs reward mechanics on-top of your game you can give players the chance to take additional risk when facing elements they have already mastered for additional reward.  Many shmups deal with this using mechanics such as bullet grazing, chaining, ranking etc.  Not only does this improve the longevity of your game but can also be used to drive competition amongst players if scoring or some other measure of success is also tied into these risk / reward mechanics.  This is where for many shmup fans the real meat of the game lives.


The great thing about shmups is that you'll often take a journey through all 3 of the above during a single play through.  The early levels that you've played many times you'll start to take additional risk when playing to increase your score and maybe in the process increase your chance of progressing (eg if score grants extra lives).  Then you'll reach the level which you are currently trying to gain mastery over so you can consistently get to the levels beyond.  During this level you'll be paying attention to the game's language and trying to formulate strategies.  Finally you'll get beyond the level you can comfortably handle and you'll be flying be the seat of your pants relying on your reactions to survive for an exciting finish.


Wow that turned out quite long, I hope you find something useful in there 

This looks right up my street, I love a good board game.  I'm digging the hand painted look to the models and the motion of the dice when you roll them, I'll be following this for sure.

Wooo my first Ludum Dare is complete.  Good luck everyone still doing finishing touches 

Polymorph Ludum Dare

Looking good skaz, loving the transformations. 

I'm aiming for a dodge em up played on a shape-shifting world.  Think monkey ball meets geometry wars.  Here's what I got so far:

I've wanted to take part in one of these for a while but don't usually find the time.  Today though I've got the house to myself and no responsibilities for about the next 10 hours, minus an hour or two to watch the F1, so I'm thinking I'll give something a crack 

What you're after is known as swept collision testing.  There's an article on it at Gamasutra which describes the algorithm needed to do swept collision testing between spheres:

http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php?page=2

[TLDR version:]

Some quick thoughts based on my experience of things you should consider before committing to using Unity over your own engine:



Unity doesn't mix all that well with large dev teams due to issues with source control and asset/scene management.  If you have a dev team larger than a handful of people this is something you should investigate further.

If your project will require any special or out of the ordinary tech you should definitely prototype those systems first.  Given that Unity is a black-box which expects a certain work-flow there are some things that will require a much larger amount of effort to do than you might anticipate or that you just simply aren't going to be able to do at all.  Make sure your project wont run into a dead-end before you invest too much into it.  (NB: physics gets a special mention here since the Unity wrapper around PhysX is very limited and inflexible)

Be prepared for a very hard time getting help/support for anything but the most simple of issues through the free channels.  Unfortunately the forums and answers hub are massively overrun with beginners and hobbyists who aren't able to help with advanced issues and who's relentless onslaught of basic issues will quickly bury your threads.  It used to be the case that premium support was very cost ineffective for small teams / indies but it looks like Unity now offers a smaller scale premium support package although I don't know what the price is like or how good it is.

Once you've got your head around how Unity works it'll be a huge huge boost to productivity in the early stages of development compared to writing your own engine.  As development progresses productivity will start to drop a bit since it becomes more effort to maintain all the relationships and dependencies between the code and editor where as bespoke engines tend to improve productivity further into development since they are streamlined for the job at hand.  For anything but really the largest or most specialised projects however you're very unlikely to beat Unity in terms of development speed and ease by writing your own engine.

If you use Unity you will also benefit from the ongoing development and support for the engine which brings it up to date with modern techniques and hardware.  Having to continue to update and support your own engine is an ongoing job which for a small teams can be a serious time sink which detracts from the development of actual games.




TLDR version:

If you're a small dev team working on a reasonably sized project you absolutely cant beat Unity for speed and ease of development compared to writing your own engine.  If you're a larger dev team, or your game is very large or has specialist tech requirements then you should test the waters first before taking the plunge.

Your problem is you're assigning "done" as false in your 'if' statement rather than checking if it is false.

This:

Code:

if (done = false)

Should be this:

Code:

if (done == false)