• About
  • Gallery of Images
  • Archives
  • Categories
  • Archive for the ‘Game’ Category

    Looking for feedback on branching narratives – Trapped in a Box

    2012 - 05.17

    My quite random afternoon spent making Trapped in a Box has resulted in me spending quite a lot of time thinking about the game. I want to add a branching narrative to it – the overall story will remain the same, but as you spend time dodging slime, I want to enable the player to explore different aspects of the story. I want the core gameplay to remain the same, trying to read while dodging slime. The question is: how best to do this.

    My first thought was too keep it completely hidden from the player – basing it upon the length of time they spent on either side of the platform ( or amount of time they have been in the air or close calls or some other metric … ), the branches in the story would be triggered by this metric. Also, after adding time dilation I debated rewarding the player for not using it by giving them positive aspects of the story. Alas, the story that I have so far for the box doesn’t really have good and bad parts, so feel this would be pointless – I’m also trying to avoid getting to Lovecraft about it – but not sure I can :)

    So I put together three mock-ups of the game, which would allow the player to choose a branch based upon a key phrase. The first two are simply putting the decision above the platform, meaning the player has to jump to activate it. The third way is to use the Q and E keys to decide.

    Option 1 : fairly simple, just the words appearing

    Option 2 : very similar to option 1, but with boxes around the words

    Option 3 : Using the Q and E keys to decide

    Option 4 : Keep the choices the player makes hidden

    I think the primary goal with the multiple branch technique is so that the game play isn’t so repetitive – I’m not very good at it and tend to die a lot :) It would be interesting to explore other parts of the story by picking a different way to go through it every time I die. Also remembering the paths I have taken already to view bits of the story adds to the game itself. So anyway, feel free to aid me with my quest or add any suggestions your have :)


    Pretentious game is pretentious

    2012 - 05.13

    So, it was a nice sunny day outside and I have a pile of gardening to do. So instead of doing the sensible thing and tackling the nightmare jungle outside, I decided to write a game. And I’ll admit it – it is a rather pretentious game, but thought it would be quite an interesting concept. So, presenting to you : Trapped in a box

    It’s simple enough to play – A and D move your box left and right, space is the jump key. Avoid the slime, and see how far you can go. I’m quite interested in the narrative, which is where the pretentious bit comes into play. There isn’t a full tree yet and depending on feedback I may change things but there is a bit of dialog in there. Once the ‘story’ has stopped, the text changes to a raising count in meters. There is nothing after that – yet ;)

    No gameover screen, and not totally happy about the slime drips and the collision system, but its robust enough to give it a play. Still early days with it, but not bad for six hours work :) If you haven’t already clicked to play it : CLICK HERE and give it a go! Comments/tweets are always welcome :)


    Update + A quick prototype

    2012 - 05.11

    Wow doesn’t time fly? Seems that I’ve been having some quite serious hosting problems, and have had to restore an old back-up of the site, meaning that the last few months posts have vanished. Annoying. Having said that, while I bring the site back online, I thought I’d post a quick update on what I’ve been up to. Incredibly I am actually working on two games in a RL work ( i.e. professional ) scenario – a Facebook game and an iPad game. Very exciting times :) Not sure how much I can actually post about them at the moment, will need to check, but thought some generic prototyping would be ok. These screenshots where rapidly put together as a mini-game for the Facebook game. The Facebook game itself is written in AS3 – however to rapidly prototype this mini-game I used the Unity flash deployment. The Unity to flash button in the corner is a test script used to communicate variables back to the main AS3 application. AS3 opens the unity flash as an object, and that button sends AS3 the message to close it. All pretty simple stuff, but nice to see how easy it is to implement these things in Unity. The game is game complete, and basically features the player on a side of a building collecting boxes of test tubes. Overall with the AS3 deployment, took about 5 hours to put together.

    As for the iPad game, I should have some pretty cool screenshots to show you next week :) Think I’ll be spending the weekend pulling the site back together – let this be a lesson to all, no matter how experienced you are – always back up, and more importantly, always backup to more than one location! ooops! :)


    Slime Dungeon : A game made in a weekend

    2011 - 11.06

    It has been a while since I have released a game – everything seems to be complex prototypes at the moment. So I decided to give myself a challenge. Similar to the
    19 hour challenge
    that spawned SpaceOreMiner but slightly more concentrated – complete an entire game in a weekend.

    On Thursday night I came up with a simple prototype idea for a cell based game. Clearing as much of my weekend as I could, I set to work coding a game based upon this prototype idea. The goal was simple : I wanted a playable game, with sounds and music, as well as non-place holder artwork and a menu screen.

    One of the things I had to avoid a lot during this process was feature creep. It was so tempting to fall into the ‘lets add everything and make it awesome’. But I knew if I realistically wanted to complete a game within the weekend, I had to keep everything as simple as possible. But, to be honest, for around 12 hours work, I think I have something that fulfills all my major goals within my allotted time frame.

    There is plenty I will add and change to Slime Dungeon in the coming weeks ( it says version 1.0 but probably a good idea to take 0.99 off that value ;) ). One of the most important of these being an option screen. The music is great and all, but gets annoying after a while ;) Secondly the AI REALLY needs beefing up – currently it just randomly picks squares and tries to group it’s slimes together. There are some minor ( non-game play altering ) bugs also that need squashing.

    Thanks go out to Inko, who provided the amazing slime model and animations ( also an upgrade that is needed, he has provided three animations in total with it but time-constraints have prevented me from implementing them this weekend). I’d also like to mention freesound.org for the fantastic slime sounds and also the incredible offering of No Soap Radio which provided both the music pieces to the game. If you are an indie developer, I’d really recommend checking them out!

    So without my usual large amount of blog text, GreenSlimeGames is proud to present :

    Slime Dungeon


    Papertesting the prototype card game

    2011 - 10.30

    As regular readers are aware – I am a very strong believer in play testing a game before the game actually gets to a serious code level ( papertesting heh ). The original card prototype ( see here for youtube video ) was very much a proof of concept – to see how quickly it took to work out the physical game challenges ( capturing, placement on board, blank ai loops etc; ). Now that is in place – it is time to test the gameplay mechanics themselves. And I’ve found the best way to do this was with lots of squares of cut a paper, very many brightly coloured paper clips, a supply of beer and some willing volunteers to help.

    After a few games, it became very apparent that playing on a four by four grid always favored the player who moved second. Changing the game to a five by five grid removes this advantage to a degree. It also means that the game can’t be a draw, as there are an odd number of cells to be played upon. This, I feel, would have never come to light without this papertesting until the game had reached a certain stage of complexity of code. Knowing the grid plays better as five by five, means that I can code the game with that in mind, and I’m not going to have to change anything major down the line.

    Grouping cards into levels, based upon the total sum of their attributes also helped to balance the game. It was very apparent that cards of level 1 ( who added up to 8 ) and level 3 ( who added up to 10 ) were very clearly inferior. However, by altering the cards, removing some attributes and giving it a big boost in one direction, meant that in certain situations the level 1 cards were useful under different circumstances.

    Another major factor that came into play was playing blind, compared to playing open. E.g. the difference between seeing the other players cards, and your own cards. When your opponents cards were visible, it gave the game a very different feeling to when playing blind. When playing blind, the only fair way of playing it wasn’t with random decks, but with both players using the same level cards. Both ways of playing were fun, but had very different feelings to it. So I’ve decided to add this as a selectable option in the final version of the game – two different game modes. First one I will develop will be the open game ( as I preferred that as it allowed some form of strategic planning and removed any luck element ), the second one will be the blind mode.

    For card trading, we tried a couple of methods. The first method was allowing the winning player to select one of their opponents original cards and getting it. The second was allowing both players to take whatever cards were they had captured in the game. Both had very interesting feels. The first capturing method seemed more logical, and allowed the players to strengthen their decks quite quickly. It seems to be the perfect way of playing the game vs an AI in a single player mode. The second method was brutal. A badly lost game means that your deck is very quickly reduced – but thankfully due to plenty of paper and a pair of scissors, it was possible to replenish your deck with level 1 cards again. It also lead itself to a very different play style, people grabbing sides and corners and building up strong defensive positions to avoid loosing their cards. Again, the difference between this two methods were quite enjoyable. Which suggest to me another gamemode :) Beating an opponent by a large amount, and going home with most of their cards was a pretty good feeling, albeit slightly sadistic at times.

    So now that I have a lot of the mechanics actually sorted, it is time to pick a theme for the game :)