Tutorial : Unity3D remake of Pong using C# – Part One

There may be function’s in the code example’s that I don’t explain very well / thoroughly, be sure to have the Unity documentation open at all times when you are developing, it’s great to just search out a function and find out what it does. They even have small code examples showing how to use them.

Goals

  • Creating a remake of Pong
  • Remake a simple AI to play against you.
  • Adding a scoring and a high-score system.

Requirements

  • Limited knowledge of C-Sharp
  • A basic knowledge of Unity3D

Continue reading…

SMACJam – “Lets Be Friends”

SMACJam?

SMACJam was introduced to me by @SurplusGamer (Peter Silk). As far as I know the whole thing was because he couldn’t make it to the LD48 Jam in December 2010, as such he decided to choose a random theme from Ludum Dare. After meeting Peter I asked if I could be part of it as I missed the last Ludum Dare too and was very keen to get some jam time in before starting on my larger work on Thanatophobia.
Continue reading…

Work in progress: Level Editor

A level editor for Pocket Arena

Currently it features a mouse drag-and-create interface that allows the user to draw out rooms very quickly, along with placing objects (at the moment just a light) into the scene by hitting the brief case in the bottom right and clicking the light button. To extend this I will be adding features like:

  • More objects
  • Texture system, like the Sim’s where they click the texture and paint the walls/floor
  • Spawn points
  • A PIE (Play in Editor) mode
  • Placing objects / rotating them
  • A better UI
  • Many many more.
So this is it for now, check it out here – leveleditor.zip. Let me know what you think!

Easy as drag and drop

Ludum Dare 22, I’m in!

What is Ludum Dare?

Ludum Dare is a regular accelerated game development Event.  Participants develop games from scratch in a weekend, based on a theme suggested by community. - http://www.ludumdare.com/compo/about-ludum-dare/

Why I’m in

Two months ago I entered the August competition to test myself with making a rapid prototype for a game, and I managed to complete it. This time around though I intend to make it to the top 50 at least, not because I want to win but because I really enjoy the competition as a whole and would love to have that sort of impact on it.

What I intend to use

This time around I will be using Unity, it’s great for rapidly creating games along with forcing myself to actually do some sort of 3D art. Once again I will be time-lapsing so you can see how I made some stuff and the source code will be public at the end of the competition.

Thanatophobia Announcement


Thanatophobia is a Survival Horror game which started development in 2011 with John Pearce.

It features a detailed story along with several challenging puzzles and features a fully custom user interface, inventory system, dialogue sequences combat and various puzzles.

The game is a brand new entry into the forgotten world of old school, third person survival / horror, with focus on puzzle solving and storytelling over intense action. Delve into Thanatophobia’s immersive storyline, spanning across three elaborate episodes, told from the perspectives of three different characters.

Each episode carries its own unique style, portraying the characters’ deepest fears. Combine items, solve riddles and combat disturbing enemies to overcome your fears.

GOAP vs FSM – Day One

Finite State Machines vs Goal Orientated Action Planning

This project will compare and contrast both FSM and GOAP based AI in a series of tests designed to test performance, realism and dealing with unexpected events. Each system will then be ranked to gauge the benefits of one from the other. At the end of the project there will be a playtest of a game where the AI can switch between FSM and GOAP AI systems, this will allow the player to experience the difference in the AI and gauge the realism and immersion value the different AI allows.

Apologies in advance, this is really just a quick scrap for my notes so I can remember how I did things. If you have any questions though feel free to ask!

Rough Outline

After playing around for a while with the character controller for the Bootcamp demo, I decided that in order to interact with it, instead of re-writing the whole thing I would tie requests into it by using a blackboard system. The player controller asks if the player wants to shoot by default (Fire button pressed?) so I simply told the AI that if it wants to shoot to write in the blackboard (shoot = true;), the Controller then reads in the value and starts to shoot.

For Pathfinding I am using Aron Granberg’s amazing library to generate paths, this allows me to focus more on the AI than the Pathfinding issues.

10 Little things I’ve learnt while making games.

Over the past two years I’ve worked on a number of projects, many of which have never seen the light of day. This was mainly due to a number of short-comings in my planning and execution of the development, but having learnt from these mistakes I feel I have bettered my trade.

Most of these things are very little and if someone had mentioned them to me at beginning I wouldn’t have considered them even important but they have become more and more apparent in hindsight.

1. Write everything down

Even if it is something as small as changing a NPC’s name from John to Bob. One system I’ve picked up is using Post-It notes (they are really cheap to get hold of Literally 50p from ASDA), write a task down on it and once you’ve done it put it in a pile.

Something about seeing a stack of “Done” Post-It notes gives you enough energy to keep on task and actually feel like you are achieving something. This is extra important when you are working on your own on a project as it’s easy to slack off when it’s just you.

Another thing I’ve found myself in need of is a whiteboard, these things are stupidly cheap from pretty much anywhere. They are great for quick brainstorms and jotting down quick design plans if your showing someone else how something works.

2. Give yourself a break

This is one of my main points, for the first 6 months of working for myself I think I spent a grand total of 5 days with friends / my fiancée, it was a dark time indeed. The worst part is you just end up running yourself into a hole that seems to just get deeper and deeper the more you keep going. Take a day off here and there, have a weekend with your loved ones and get back to work during the week.

When it comes to working on a project as big as a game (Even “small” games are huge undertakings sometimes) you need to give yourself some down-time to just go over what you’ve done, get away from it all and then be refreshed and happy to work on it. I can’t remember the amount of times I’ve dreaded working on a project just because I’ve spent so many hours on it getting nowhere (Most of the time it’s when I’m not at the computer but walking around or on a train I figure out something that’s been bugging me for hours)

3. Start small, work your way up

We all dream of making the next biggest thing, the fact is that most project I’ve started have been grand scale projects (Aaarghmageddon for instance was supposed to be a zombie RTS / Action game…) but you so quickly get stuck down in the “details” and you find yourself reworking and reinventing the game so quickly you lose track of where you were.

When you have an idea for a game, write it down and expand it out so you can see the game-play features. What makes your game fun? Who would play it? Why would they play it? Now strip back everything about the game until you are left with just the core game features. Remove all the flash graphics, the complex systems for interfaces and everything that can be classed as “nice to have”, and if the game is still fun then you should start on making it. Remember you can always add to a game when its the bare basics, it’s harder to add things when you’ve made a mammoth of a project.

4. Design, Design, Design…

I know it’s drilled into us that we should design before we even touch a line of code but if your like me you can’t help yourself but think, “Oh it’ll only take a few hours to write the code to do XYZ” , then you need to stop for a second. Just grab your whiteboard/book/scrap of paper, jot down what it is you are going to make and draw out a quick little overview of how it should work, this may seem kind of pointless but it really helps when your deep in coding and can’t remember what it was you were making.

Of course if you are making something really huge you may want to think about sitting down with a notebook and drawing out a bunch of flow-charts to show what you are going to do and just assure yourself that you are doing it the right way, if you feel that you aren’t doing it the best way break out the internet (Google, Stack Overflow, Forums, Documentation, etc..)

5. Carry a notebook / sketch pad / scrap of paper and pen with you at ALL times

This might not apply to everyone but if you are like me you’ll be doing something completely unrelated to what you are working on and all of a sudden you’ll have a flash of information hit you. You can either A) Remember it and hope you don’t forget or B) Grab your notebook, write a quick note about it and forget it at your own content, then when you get around to working on it all you have to do is grab your notebook and the answer is sitting there for you.

Of course this goes for many things, if you are artistic you may have a character design pop into your head and you want to quickly sketch it down. If you are like Kris you’ll be sitting on the underground sketching strange things to scare away the people staring at your sketch pad.

6. Talk to like minded people!

One thing I love about the game industry is the fact that it’s so small, get out there and talk to other people like you, bounce idea off them and get their feedback. There is a lot you can learn from people who have been there and done it before, some of them will even offer really great tip’s that can further your idea or turn it around completely.

I was under the impression for a long time that developers are mainly shut-in’s who like to work alone and don’t generally talk to other people. I used to be exactly like that, I hated sharing my work with others in-case they ridiculed it or broke it in some way but the fact is in our industry we have to work with others every day, most of the people we work with are fantastic inspirations and you can really see their passion for being in games.

Just open up to people, enjoy what you do and have an occasional drink with other developers basically.

7. If stuck, carry on.

When I’m stuck on a problem, I take a step back from it and work on some of the easier tasks that need to be done. That way when I figure out the bigger problem I can come back to it and have not wasted any time getting stuck and frustrated.

You don’t even have to be coding when you work on other things, it could be simply writing a blog post, drawing up a couple of designs or just fleshing out your GDD. Just don’t sit there and stare a a problem hoping it will give you the answer, go grab a coffee and get stuck into some easy bits and pieces.

8. Stay away from making a HUGE GDD

A big GDD may seem like a good idea in the beginning, but remember to keep things small at the start. Make a simple one page GDD stating what the game is about, what it’s core features are and exactly the style you are going for, that should be enough for a simple game and you can always add to it later. The main thing is to get stuck into developing the game and not to get stuck into designing something that will never be possible to make.

9. Be realistic with your game


Making a game boils down to the basic project triangle, given infinite resources on any point and you would eventually create a game that no-one would want to play, not because it isn’t good but because it is so overly complex. Pick two corners and run with it.

If you set yourself realistic goals that you know are possible and pace yourself so you don’t burn out, you can get something released. Once it is released you can always update it and add features in later on, being obsessed with perfection is a good thing but it can hinder a project if you get too much into the details.

10. Stick with it

I once read somewhere that you should treat finishing a project as a skill, if you do start a project don’t start it unless you are sure you can finish it. At the end of the day a finished bad project is ten times better than an unfinished good project, at least you can polish a bad project into something decent!

Don’t get stuck into the trap of thinking that you’ve learnt so much and if you started again you can do it so much better, it never works out that way and you just end up going in circles and waste a lot of time. If you absolutely have to start again, look at why it failed and cut it out in the next version.

So, that’s just a couple of things I’ve picked up from making games. I wish I could say that was all you need to know but I’m pretty sure I’ve got a lot more to learn along the way to making more games. At the end of the day, I love doing what I do and so should you, keep at it and I look forward to seeing what people can make!

Creating a PHP Web-service to handle data for Unity3D Clients

[Warning: This is not wrote in an academic fashion in any way, this is just a brain-dump of what I've been working on to get things working. My final report will list the main reasons behind my choices along with why I decided to go about things in this way]

For the last two week’s I’ve been getting the design ready for our group project “Pocket Arena”. Within the game we will need to log the player in and retrieve the data related to the player, in this instance we need to get the player’s characters and items they have already unlocked.

I chose JSON to transfer the data between the web-service and the client due to its compact nature and very simple usage in PHP, the output that I was looking for is as follows:

{
  "type": "getUserData",
  "status": "success",
  "data": {
    "User": {
      "username": "test",
      "id": "6"
    },
    "Character": [
      {
        "id": "2",
        "name": "Test Character Two",
        "user_id": "6",
        "CharacterItem": [
          {
            "id": "3",
            "character_id": "2",
            "item_id": "1",
            "equipped": "1"
          }
        ]
      }
    ]
  }
}

The framework I am using for the Web-Service is CakePHP, there are many reasons why I feel that PHP is best suited for this environment  but the main one is that PHP is a free, commercial language that have been avidly tested in various situations and can be run on my current servers (As can C#, however MSSQL servers on my hosting can cost a significant amount!)

To track the users once they have logged in I implemented a token system using a GUID to be passed back to the client, this allows for the web-service to use sessions within a non-cookie environment simply by passing this token back to the web-service, IE.

http://www.somewebaddress.com/getUserData/token:{GUID}

In terms of security the GUID is randomly generated on each login and expires once the player logs out of the client application, the GUID is then SHA1 hashed which generates a 40-character alpha-numeric key which means there is 2^128 chance of it being generated coincidently.

Ludum Dare 48 Hour Game

For the last 24 hours I’ve been creating a game for the LD48. Ludum Dare announced the theme on Saturday morning (3 am here!) as “Escape”.

With the theme Escape the first thing that came to mind was a platformer consisting of various levels with enemies to get past / kill, however when I started on developing it I quickly became bored with the idea and after looking at a couple of other projects people had announced I realised that it was being done by several people.

Instead of continuing with the platformer idea I opted to create something different, I enjoy making procedural enviroment’s so I created a city algorithm that effectively created a maze which the engine then drew city buildings / decals and objects onto. On top of this it added guards and snipers to give the player something to fear while trying to find the exit (Which is randomly placed too!)

Anyway, makes more sense to actually see the game in action!

Links to Game and Source code:

Ludum Dare Source-code for CityRun

CityRun

Let me know what you think!

125

Ghostly

What is it?

Initially inspired by talking in the TIGSource IRC channel, the idea behind Ghostly is to quickly progress through the levels before your character dies. To avoid dying the player must “Possess” other characters to reset how long they have left to live.

At the moment there are only a couple of levels as this was a prototype developed to see if the idea was feasible however after several people enjoying the game I am starting work on making this into a larger game with multiple levels.

Technology Used

Ghostly was built using the Flixel Flash engine and the “artwork” was created in GIMP (Graphic Image Manipulation Program).

Demonstration

You can find the current version of the game here - http://www.dannygoodayle.com/Ghostly.html