• Subscribe Comment
  • Subscribe Posts

Red Forest – Procedurally Generated Pod Racing

Red Forest: Procedurally Generated Pod Racing -is the current working title of what was previously known as X-Speed and Red Forest.

It is a pod racer with a difference! You won’t see “With Six Tracks!” in our feature list, because upon release, Red Forest will feature INFINITE tracks. That’s right- The tracks are generated at runtime much like the levels in Worms.

Now add hover pods to that, and weapons, and upgrades, and speed! ON TOP OF THAT, Add the fact that even though we’ve not released it yet, you can still play it.

Output0 (2)

That’s right, we’re giving everyone early access for free. It is our view that the best feedback comes from the users, and it seems daft that most games miss out on this crucial feedback prior to release. This means that YOU have control over how the game improves at an earlier stage- and hopefully, you’ll enjoy the game far more for it. This is a bold risk, but we hope you choose to support your favourite games.

Right now, Red forest is limited to 10 tracks and four fully upgradable pods. The pod count will increase over time, and upon release we will remove the track limit.

This page will always contain a link to the latest Web Build of Red Forest. This will be periodically updated during development (Red Forest is Free to play during development- we are, after all, getting your feedback!)

 

Click here when you are ready to play!

Alternatively, if you have a recent, powerful Android device, Grab a copy of the current Android build from the play store

 


Red Forest update – Greenlight, Re-re-re-relocation, new team!

It’s about time I wrote an update for everybody involved. Recently, we got greenlit. It was amazing!

I haven’t been fantastic at keeping everybody updated, so here it is- this is the first proper

Project Update!

Red Forest is going to be my first desktop game in four years. It’s a much much bigger game than my previous desktop game, Mash ’em Marbles. I’ve probably learned more since starting it than I did in the decade of PC development before it. This was no Super Mario clone, or a Match 3, or a minigame prototype. It’s also not an application. It’s a full on desktop game.

It’s not gone to plan so far. Life always gets in the way, and it has again recently- Four moves in two years, and I just found out I’m going to be a father. Along the way we’ve dismantled and rebuilt the project twice, and we’re still not done.

Getting greenlit caused me to re analyse the game, and audience, and reconsider if it was worth completing. The answer is, of course, yes- it needs to be finished. But not the same “finished” that it would have been without Steam.

As a result of everything, I’ve got some help on the artwork- two new team members who will help out when they can, providing pod meshes and 2D art. I’ll introduce these guys shortly.

Here’s the state of play regarding the Steam version:

  • It’s now ported to Unity 5, with my custom Unity 4 shaders being upgraded to Unity 5.
  • We have some new artists modeling new pods, so we can remove asset store bought pods and have unique designs, as you deserve. We’re aiming for 20 pods by December but that’s quite optimistic. I’ll be happy with half that initially.
  • Track generation is now stable (previous versions have been notorious for spawning impossible tracks) but remains in heavy development.
  • UI system is being updated for a third time. Daikon Forge became unstable, and NGUI too slow to use. We’re moving over to the new Unity UI system. This is quite a large job!
  • Multiplayer is being tested with the new Unity networking system. The game was unstable with the old networking system, though admittedly this is likely to be because it was our first implementation. We want this to be as best as possible.
  • We’re considering dropping the number of pods from 128 on track to 64 (in Ludicrous mode) simply because above 64 or so, you don’t really notice there are that many. This allows the game’s AI to perform almost double the calculations, bringing back the character in the AI that I did not notice had started to disappear.

Broken Promises

I made a lot of promises about game content. As time went on, it became obvious that I can’t do everything I promised. I’ve mentioned that in previous posts too. I do feel awful for that, but it’s important we get to a release state. I’ll do everything within my power to make this game something the players want. I may not be able to hit every point promised on the Greenlight page, but I’ll be transparent about that, and I’ll be listening to everybody as we go along. That brings me to the next point:

Early Access

I’m discussing an early-access release, using the funds to complete features that haven’t made it in yet. I won’t take a single penny of steam income until I’m happy with what was promised is delivered. All early access funds will be spent on artwork and features to bring the game forward.

Up until now, the game has been low budget. That means I’ve just saved and spent my own cash on what was required. For a self published game, that’s fine, but it shows, and I do not consider it good enough for Steam. Early Access will allow me to fund some serious visual updates.

In short

In short, we’re still working on it, it’s a much bigger job than I thought, there’s lots left to do, but we’re doing it!

..Oh, Here’s a quick screenshot.

Unity 5, Nov 2015

Unity 5, Nov 2015


Blast from the Past: Flow3D and FlowED

FLOW (Flexible Lightweight Ogre Wrapper) was a powerful, easy to use 3D engine for BlitzMax, one of only a handful available at the time, and certainly the most powerful. It focused on 3D and Physics, tying Newton Game Dynamics with, you guessed it, the OGRE rendering engine.

FLOWED was a scene layout editor with some crazy features.

We began writing an Ogre wrapper in 2005 for LokBlox but it wasn’t until 2007 we settled on a system that worked. It was the third iteration of FLOW.

I could go on for hours about FLOW, I loved it, it’s a project close to my heart. But FLOW needed more than just a renderer. So we build FlowED. The best way I could describe FlowED is a Three-Man-Team, early version of Unity. It gave you the ability to lay your scenes out, modify materials, test physics in real time, and it had an awesome ability to automatically plug into any game running that was written with it, allowing you to modify that game. I had planned to include scripting, but it never made it into the final build.

Sadly these projects ultimately failed because BlitzMax had a total userbase of around 3000 at the time, so we had failed to select a market we could thrive in. We decided to release Flow for free.

Flow is still available (unsupported) from http://www.flow3d.org/

 

flowed1 flowed2 flowed3 flowed4 flowed5

 

You can see FlowED’s mod capabilities in this video of MazeMonkeys:


Blast from the Past : MazeMonkeys

MazeMonkeys was a game I started with a couple of friends back in 2008.

It was a simple FPS. You’re a robot, rolling around, shooting other robots. When destroyed, you fall to your components, which can fly all over the place as you explode. It’s a simple but awesome looking effect. Levels had simple puzzles that you had to solve in order to progress. I’ll confess though, shooting at and blowing other robots up was just so much fun that’s mostly what we did in game.

If you had FlowED (a 3D, Unity-like editor we wrote to extend Ogre) installed, the game allowed you to edit/mod it in realtime using FlowED.

It was written in BlitzMax and C++ with Ogre3D as it’s rendering engine. The game never quite made it to completion as life took over and we moved on, but it’s a project I’m fond of to this day!

 

MazeMonkeys

These guys were having a dance until one got grumpy and blew the other up with a grenade.


Red Forest – We’ve been GREENLIT!

Yes, that’s right! We got Greenlit! Players want the game on Steam!

 

Stay tuned for more news- We’ve not got much time to update this site right now because we’re busy going nuts with paperwork, getting a bigger team, and planning everything! Once we’re done, I’ll create a new post outlining the plan.

 

…Well how amazing is that!?


My experience of Global Game Jam 2015

On January 23, 2015, an amazing thing happened. Tens of thousands of developers joined forces for 48 hours and produced a huge number of games for Global Game Jam 2015. It was easily the best weekend I’ve had in a long, long time and I recommend anybody who loves to design or develop in any way to take part.

When I arrived at Stafford University, we were quickly grouped with 6 other talented people and then lead to the keynote presentation.

The annual event always revolves around a given theme, and this year was no different. The chosen theme for 2015 was “What do we do now?”

Immediately thousands of ideas involving zombies were thrown around- my first thought was a zombie car, so somewhat more imaginative than an apocalypse game, but still not good enough. We bounced back ideas for a good hour or so until I mentioned that whenever I cook the kitchen ends up on fire. This led fellow team mate Dave (also Team Lead I may add- a role he took so naturally nobody noticed it happen.) to think up our game idea:

Before It Burns.

‘The thought may have crossed your mind.. “If my house was on fire what would I save?” Well now you can find out! Because we’ve simulated it!’

More information on the game itself can be found here– I won’t talk about the game itself too much here- the important thing was we had a full team, and an amazing idea. Time to make a game!

At this point, 8pm on Friday, I am usually starting to get a bit snoozy. This was an understatement this time, because I’d been over-excitedly coding a network library for the preceding week and had slept a total of around 8 hours during that period. That was nothing, though, because we had 45 hours left to go and I’d heard nobody sleeps at these things.

Dave- who had been to the event for the previous four years- had already organised everybody into roles before I’d managed to organise my own thoughts, and away we began.

The next 9 hours went really well for me- I managed to stay focused, and get a heck of a lot done. I coded the inventory system and some simple UI bits. The gameplay was working. Next to me, Dave was making some odd sphere-like beings shoot scary rays across rooms but I was too focused on my own code to pay attention. What was he working on? I must remember to check it out.

Everybody knows that if you use computers, you must take a break. Dave and I bought our quad-copters for just those occasions! We captured footage of a few of the rooms in use and uploaded them to youtube. We also had a few accidents and my quad was damaged, but it was worth it in the end!

At 4am, we break. we hit an invisible wall so hard it knocked our coding teeth out. Most of the team had flaked away for sleep- who can blame them? As a developer there are two things you can do here- 1) Continue to try to code- and regret it the next day, and 2) Get sleep. I correctly chose sleep, so off I went for a nap.

Oddly,  I was awake again by 7, felt great, so I took a bus to the local city centre and grabbed breakfast before heading back and beginning work.

I’ve not mentioned the artists yet, but they were all hard at work behind us spitting out nearing 100 assets, something that was quite amazing to see from aspiring artists/designers. They took breaks too- by drawing questionable things on our drawing board. It felt like the offices at Matmi where freedom is given and really odd things appear on whiteboards.

The second day though, was quite quiet. We all had our tasks and got on with them. There’s not a lot for me to talk about. I sat down and got the UI’s in and a menu system running. Dave was hacking away at his yellow ball things. I remembered to check what he was coding at this point- He hits play and suddenly flames fill the room. It was a fire-spread algorithm! This system is the heart of the game. When the flames came to light the project suddenly felt alive, like real progress was being made, and it was.

That evening, I took a break to work on the audio.  I didn’t expect it, but I hit on the perfect track almost immediately, and had people in the room asking me to turn it up. Now, I’m out of practice. I’ve not done any professional sound design since 2010, and my confidence in my abilities there are far from great, so this was an amazing reception. Two tracks and about two/three hours later and the music is complete.

We continue right into Sunday morning. At 2am, with almost 19 hours without sleep, I behind to hallucinate. I’m not kidding. First, I imagined I was in a hallway with lots of diagonal tables. Then, my brain whisked me back to a hall in primary school, then I thought I was in a train station and Dave was a strange black woman. I am NOT kidding, this happens if you don’t sleep.

It became obvious that I was experiencing micro-sleeps where you uncontrollably sleep for a few seconds, but your eyes may be open.

Dave and I continue to dribble into our keyboards coding various bits and pieces (and creating mundane object “prefabs”) until about 6am Sunday, when we finally get around to doing a Git Merge. (For those who don’t know, that’s where we take our work and slam it together until it becomes one bit piece of work.)

We reach 8am. I’m feeling great, but the team lead has had to rest.  I take charge of coding for the following few hours and things start to really come together. Until, that is, I go absolutely insane.

I’ve not slept for 29 hours at this point.

Dave wakes up, somehow sharp as a knife, and starts preparing for the final build. He needs me to fix a few issues, which I do.

To explain just how out of it I am at this point, I’ll explain one of the things I was asked to do:

“Can you fix the look up/look down thing?” – which needed 3 seconds of work to change two numbers. What I did, however, was open my software, zoom out to the top of the map, point the camera down, and then look confused. I literally had no clue what I was doing at this point, everything was going over my head. I needed sleep. Badly. Sleep never came, though.

We were a little late submitting the game because my final quick fix completely broke something very important, and we had to revert it. We got there eventually, and submitted the game.

After submission, we saw videos of all games submitted at Stafford University. There were some really good ones, but we felt ours was right up with the best. I’m proud of the team and their achievements.

I don’t remember a lot about Sunday to be honest. After going to sleep, it was like a dream. I felt like I’d had far, far too much to drink the night before!

Will I be partaking in 2016? Absolutely, YES.

 


Low cost development is possible- and you can do well from it!

Today I’m going to talk a little bit about how it *is* possible to produce low cost games. Red Forest has cost less than £500 so far!

Not all of the information within comes from Red Forest; A lot of this information comes from data I’ve gathered by watching those who do find success; Many success stories come from low budget games. I also cannot claim to say I am entirely successful yet. I’ve successfully pulled off several points within this article, and others are points I know to follow but have not yet had the chance to do so; Points that others who have found success have actioned.

 

Are you new to the scene? Are you looking at creating your first game but don’t want to run through your savings? Or are you just a financially challenged  developer?

All of these things- and many more- will mean you won’t want to spend money, and cut back where possible. Many will experience resistance from the scene when trying to make progress on a low cost game, so here are some points to argue against common misconceptions with regards to low cost/ zero cost development:

 

1)  Your game doesn’t have to suck.

This is simply not true. Some of the best games today had low cost. Many come out of game jams (look up Thomas was Alone, which unexpectedly launched Mike Bithell to Indie-Fame.)

if you have a vision, thrive on it, build on it. It doesn’t matter if it takes a while to do so, just get on and do it.

Red Forest started as a fun prototype, but it never sucked, even when we created textures in MSPaint (Yep, i did that.) – and from the moment we implemented decent keyboard controls, it grabbed attention. Get your gameplay right.

Another important thing: If you get this far and the game just doesn’t feel good: Consider dropping it. Don’t be afraid to try, try and try again; Your game doesn’t have to suck, likewise, not every game is a great game. Kill it early and move onto something better.

To demonstrate this, I’ll briefly mention Gravity Ed, which I spent a year or so developing. People liked it, but it never crossed the line from good idea to good game. After gaining feedback, it was decided to end development and pick something better.

 

2) You CAN be a respected developer.

It is true that other developers will be cautious to get involved with you until you have proven yourself, and this is a key part of gaining respect. How do you start? Network! Go out and meet local developers. Many such groups exist and i’ve met many great developers at these meet-ups. I honestly felt overwhelmed by the community until I started networking, and once I started I wondered why I hadn’t done so earlier. You’ll realise the community is much smaller than it seems; My friends know my other friends by pure chance; not necessarily through me. They’re all great devs/artists/musicians/whatever-they’re-skilled-in.

Get a prototype built, prove the gameplay works. Once you start networking and showing off these prototypes, you’ll gain confidence in yourself (if you lacked it in the first place) and will start to find getting attention a little easier as more people join in. From there…..

 

3) You CAN find people to work with!

Well, it may be difficult to get people in on your idea, but once you’ve got your head around point 1- and have faith in what you are doing, and point 2- and have people playing your prototypes, you will have met people who are much more willing to help as they have seen your project and know that it’s worth something. At this point, people who are really in to your project may even offer to help!

Red Forest has so far cost less than £500 to develop due to the amount of people willing to help. There’s no way I could just turn up on a forum and post a thread with a subject such as “Hey! Who wants to help me make a pod racer. I can’t pay but” – Nope. These will be mostly ignored or ridiculed. People on the internet have been burnt badly over the past and as a result a lot of these people have become jaded. You’ll need to try harder. You’ve seen post 2? Go and network and meet the people who can help you first hand.

I’ve got two people helping with music on Red Forest, and two designers giving their input. Mad.Array jumped on board early on just from the prototype and has helped shape the game as it is now, but I’ve not got the funds to pay these people much, and I’ve made these people aware of that early on; face to face. If they can see your product, play it, interact with it, they’re going to be much easier to get on board. Respect others and don’t push your luck.

 

4) You CAN do some basic marketing on low budget, (and you don’t need to pay for media coverage.)

No doubt you’ve met some lovely people from the media during your networking- They’re all over the place, and they’re typically *Really nice People* – Games media are not The Sun. They’re not out to get you, they need their stories as much as you need visibility- so, speak to them. Send an email to your favourite contact, ask some magazines to review/preview your game.

An important thing about the media that was not immediately obvious- and is being exploited by low-coverage publications- You DON’T need to pay the media to cover your game; you are providing them with content that ultimately keeps them their jobs. If they want you to pay, they aren’t going to get you any visibility; they’re just gathering money.

One thing we’re finding really difficult with Red Forest- Marketing on a low budget. It is absolutely possible.

  • Create a twitter account for your product;
  • Create a website for the product and link it to twitter;
  • Post updates daily- these will feed through to twitter;
  • Retweet product updates from your personal accounts;
  • Join Thunderclap and SPREAD THAT AROUND LIKE CRAZY;
  • Join IndieDB and list your product and updates;
  • TALK ABOUT YOUR PRODUCT. Share details, tutorials, show how you did a specific feature;
  • Get the media talking about it. An RT from a friendly media contact is a godsend!
  • Use cross-promo based advertising if possible and if relevant.

 

5) You CAN succeed.

If you apply everything above- along with anything you learn along the way- you’ll massively increase your chances of success. However, you may not get there on your first go, or even your second. A very important thing in Indie development is: Do not give up. It’s your dream, so keep fighting for it.

Don’t give up, keep coding, and succeed. It’s not easy, but it’s fun and you should give your project all of the effort it deserves. Most importantly, if you do sadly fail, learn from your mistakes, then turn around and give it your all. You’ll only be even better at it!

Good luck, fellow developers! Keep doing what you do best.


Red Forest update

Things have been quiet for a little while here at Sturdy Games- and I thought it was about time we updated everyone!

Development of Red Forest is going very well. Things have not been perfect, however, as we realise that with just the two of us and the time we have available to develop, the game as planned was going to be delayed until 2015 or even 2016.

Simply put, we have attempted to put too much into it given the constraints life has thrown at us.

So what does this mean? You’re probably getting a bit of a negative feeling from all this- well, not really. The game is going to be released shortly, but it doesn’t have everything we envisioned for it- it lacks some of the extra features: the tracks don’t quite have the variation they could have, there aren’t as many pods as we anticipated.

HOWEVER:

The core engine did get that long required rewrite. The features we planned for are entirely possible, and some are actually implemented in a simple form but are not exposed to the user yet.

Ludicrous mode still exists,
Survival mode still exists,
Tournament still exists,
Multiplayer: This needs to be in, but so far it is unusable. It’ll go in- but after release, after extensive testing and after settling on a final solution.

There will be only a handful of ships on release- but we will add to these after release in an update.

Track-wise, the game can produce unlimited tracks, but the level select currently allows around 3,000. On release, it will be around 15,000, and we may think up a new method of level selection if that isn’t enough! 😉

There will be five pickups on release- again, these will be added to after release:
Laser, Missile, Shield and the Mad Array

The Mad Array is a satellite driven attack, producing up to 4 laser beams to shoot down and destroy opponents in front of you. It will be dropped very, very rarely due to the damage it causes. As an example in a standard race, if you are 5th, and you get this, it could knock out all four pods in front of you. In Survival mode, the damage is reduced, but it’ll still take out a pod or two if their shields are reduced.

So yes, the game is nearing a state where we will release it, and although it doesn’t have everything we had hoped for it, it’ll have everything it needs to begin with- and just because it’s released doesn’t mean we’re going to be done with it.

…But We still want to give you more!


Unity3D – Accessors are bad- Caching is good!

Unity3D is an amazing tool; It makes development a dream. It introduces coding to novices without limiting their capabilities. It removes the headaches from coding the core engine, 3D renderer, sound system and all of the components required for a good, stable, usable 3D engine by having them already there ready for you to use.

However, Unity is not perfect.

Whilst Unity provides all the basics, and has an integrated scripting system that is actually less scripting than you might think- and more true programming- some of it’s ease of use features contain surprising bottlenecks.

During the massive upgrades required to bring the old Red Forest prototype to where it is now, a very surprising issue was discovered. Here are two surprising bottlenecks in Unity:

1) Accessing the transform member.
2) Accessing the rigidBody member.

OK so strictly speaking, these are the same- they are accessing what Unity have called Accessors. You would think these are just predefined members pointing to the objects transform and rigidBody, however, my theory suggests that:


  RigidBody rb=rigidbody;

is the same as


  RigidBody rb=GetComponent<Rigidbody>();

[update: Actually Unity themselves have said that the exact code execuded is:


  RigidBody rb=UnityEngine.Component.get_rigidBody();

which is exactly the same.]

I’ve done significant tests- now, take a look at the following:


  Transform cachedTransform;
   Vector3 velocity;
  Rigidbody cachedRigidbody;
  void Start() {
    cachedTransform=transform;
    cachedRigidbody=rigidbody;
  }
  void Update() {
    velocity=cachedRigidbody.velocity; //This is ~ 18 times faster than...
    velocity=rigidbody.velocity; //this.....
  }

Those two should in theory be the same- however the top line is 18x faster.

Here’s the test class. Simply create a GameObject and attach a Rigidbody to it- then attach this script, and run.

Start us an IEnumerator to allow a few seconds to pass before the tests begin- just in case there’s any startup lag.


using UnityEngine;
using System.Collections;

public class AccessorTester : MonoBehaviour {

  // Use this for initialization
  IEnumerator Start () {
    yield return new WaitForSeconds (1); //remove startup lag.

    Transform cachedTransform = transform;
    Rigidbody rb = rigidbody;

    float endTime=0;
    float startTime = Time.realtimeSinceStartup;
    Debug.Log ("Reading Transform.");
    Debug.Log ("Start Time: " + startTime);
    Transform temp = transform;

    for (int x=0;x<5000000;x++) {
      temp=transform;
    }

    endTime=Time.realtimeSinceStartup;

    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 accesses.");

    float uncachedTime = endTime - startTime;

    startTime = Time.realtimeSinceStartup;
    Debug.Log ("Reading Cached Transform.");
    Debug.Log ("Start Time: " + startTime);

    for (int x=0;x<5000000;x++) {
      temp=cachedTransform;
    }

    endTime=Time.realtimeSinceStartup;
    
    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 cached accesses.");
    float cachedTime = endTime - startTime;

    Debug.Log ("cached is " + uncachedTime / cachedTime + " x faster.");

    Debug.Log ("Reading RigidBody.");
    Debug.Log ("Start Time: " + startTime);
    Rigidbody temp2=rigidbody;

    for (int x=0;x<5000000;x++) {
      temp2=rigidbody;
    }

    endTime=Time.realtimeSinceStartup;
    
    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 accesses.");
    
    uncachedTime = endTime - startTime;
    
    startTime = Time.realtimeSinceStartup;
    Debug.Log ("Reading Cached RigidBody.");
    Debug.Log ("Start Time: " + startTime);

    for (int x=0;x<5000000;x++) {
      temp2=rb;
    }
    endTime=Time.realtimeSinceStartup;
    
    Debug.Log("End time: "+endTime);
    Debug.Log(endTime-startTime+" seconds taken for 5,000,000 cached accesses.");
    cachedTime = endTime - startTime;
    
    Debug.Log ("cached is " + uncachedTime / cachedTime + " x faster.");

  }
  
}

On my machine, running this code shows that accessing existing Unity accessors is around 18 times slower than using a cachedRigidbody. This was the difference between 128 ships running at 5fps, and 128 ships at 60fps in Red Forest.

So: Think about it- If you’re using a Unity ease-of-use accessor- consider switching to caching.

If you are starting a new project- or have the time to convert- consider extending MonoBehaviour and doing something like this:

First- the new ‘MonoBehaviour’:



//CoreBehaviour.cs

using UnityEngine;
using System.Collections;

public class CoreBehaviour : MonoBehaviour {

  [HideInInspector]
  public new Rigidbody rigidbody;
  [HideInInspector]
  public new Transform transform;
  [HideInInspector]
  public new Camera camera;

  //etc
  public virtual void Awake() {
    transform = gameObject.transform;
    if (gameObject.rigidbody) rigidbody = gameObject.rigidbody; //Overrides the slow rigidbody reference! (Thanks to Fabien Benoit-Koch for the tip)
    if (gameObject.camera) camera = gameObject.camera;
    Debug.Log ("Caching complete.");
  }

}
  
  

Then an example script that extends from it. Note that Awake() is now a public override.



//CachedBehaviour.cs

using UnityEngine;
using System.Collections;

public class CachedBehaviour : CoreBehaviour{    

  public override void Awake () //Awake needs to override.
  { 
    base.Awake(); //does the caching.
    Debug.Log ("Awake called!");
  }
    
  void Update ()
  {
    //Now you can use transform / rigidbody as normal and still gain your speed boost!
  }
}

Personally I like to separate the caching from the Awake function- so I do not use Awake() in my scripts, instead, I do the caching in the Awake() method of CoreBehaviour and have that call Init(), a virtual method which I use in all of my scripts. This is preferred as it feels cleaner, however if you already have a large project the method I have just shown is going to save you a bit of time!
You need to ensure you call base.Awake() otherwise no caching will occur and you’ll get a load of null references.

How’s that for a nice performance boost and minimal interference!

Unity have posted an update about Unity 5 explaining that they are in fact removing these accessors: Unity 5 API Changes and automatic script updating

Screen Shot 2014-06-24 at 14.12.53


Stage fright: Talking to an audience

On Thursday, 30th January 2014, I decided, last-minute, to stand up and talk about my game, Red Forest.

Anyone who knows me knows that I am an introvert. This is not a bad thing. I do not dislike socialising, in fact as two months worth of living alone without any entertainment in Manchester proved that I am quite fond of it. I merely like my time to recharge to be alone in my own mind, thinking about whatever interesting things popped up that day. Usually, it’s a GUI bug, or a new way of managing systems.

Introversion naturally causes me to feel uncomfortable in large crowds. Again, there’s nothing wrong with this, it’s just how I am wired. However, it does pose a problem when it comes to attempting to market a product. I should be out there, showing it off, and comfortably giving talks saying, Hey, this is what it is, this is how it works. Instead, I typically stick to my safe zone and keep quiet.

On Thursday, this changed.

You see, at Manchester Unity Users Group, the theme was Procedural Generation. This very theme was very, very relevant seeing that Red Forest is a procedurally generated game. I forced myself to talk to the organisers, and then I did not let myself back down. At this point, I knew it was going to go wrong, but I didn’t care.

Maybe to everyone else in the room this wasn’t a big thing. Anyone reading this who remembers their first talk knows what I am talking about – You have a room full of people staring, judging, waiting patiently to hear what you have to say. This turns your nerves into jelly – and not the wibbly wobbly nice-with-custard jelly, but cat food jelly. It’s still wibbly wobbly, but it’s not nice. and you really don’t appreciate getting it on yourself.

Normally, the first thing you would say would be “Hello, I am Damien Sturdy from Sturdy Games, and I am here to talk about Red Forest.”

What I said: “Ummmm…. So I’m showing off my racer. It’s kind of like Wipe.. I was going to say F-Zero but Wipeout works”.  About 5 minutes of me talking about how it procedurally extrudes a solid mesh along a spline and textures it, I say, “Now, this is actually available for free whilst I develop it”. Then, someone asked the first question: “What’s the site address?”.

Internally I panicked. I think I hid this well actually. I realised I had failed to give the website and that these people had no idea who the rambling fool in front of them was. I’m not particularly ashamed of embarrassment. If someone dared me to wear a dress, I would probably do it. At this point, I said, “Oh, yes! I suppose that would be really helpful for you to know! It’s DamienSturdy.co.uk, and I am Damien Sturdy. Nice to see you all”. A few people giggled. Moment saved? It didn’t feel like it.

Mistake 2, although nobody would have noticed, was that my site is SturdyGames.co.uk, not DamienSturdy.co.uk, which simply points here. It didn’t matter, because at some point that day, something funny happened with the server and I just this morning restored it. It was offline.

After around 5 minutes of internal panic, I had enough, and said, “And well, that’s my game, and it’s procedurally generated. Thank you!”

Something very bizarre happened at this very moment. Everyone there received applause, so that didn’t surprise me, but the audience seemed to pick up on my severe nerves and I got an absolutely massive applause. I walked off buzzing. People told me it was really good, and although I had decided I didn’t care if I was judged up there, it was really nice to know that it was enjoyed.

 

So, what advice would I give to other first time talkers?

Firstly, if you have stage fright, this is going to be hard no matter how you look at it. I found that although the fact someone I knew was there initially caused more anxiety, their indirect support made me feel more at home front of house. Take a friend for support if possible.

Secondly, you’re going to be nervous. Don’t try not to be. The audience is far more forgiving than you think, so just be as comfortable as you can be with those nerves. This may sound daft, but it is true. I sat at the back before I stood up and instead of thinking “Cack cack cack cack cack! I’m going up! Oh no, Oh no!”, I successfully forgot about the audience and thought about the content. The audience came back to mind when I realised the room was staring at me, by which time it was too late to back down! Also, be comfortable knowing that it will not be perfect. Your nerves are going to show. You will overuse “errr, umm….” but it is far more important to get this one task done.

Then, introduce yourself first. I didn’t. It was silly, and I recovered t later. My talk would have been far, far more professional had I introduced myself calmly at the start. So much so that it is likely the slip ups in the rest of the talk would not have been noticed!

Thirdly, since you are reading this, you have time to plan. If you are talking about a game, try to keep some form of dialogue going as if you were to talk about the game. Get used to talking about its positive traits. I did not know I was going to be up there until 5 minutes before it happened. Hopefully you have more preparation time.

I’ll talk again, and since stage fright doesn’t vanish overnight, I am likely to have the same nerves.

I will, however, be better prepared!