Results for tag "game-dev"

7 Articles

Bear Chuck learns Unity

Hey guys!

So Bear Chuck had been quite silent for a while, I’ve been learning Unity with the goal of ultimately porting Bear Chuck over to it because it seemed more robust, especially from the web build as well as cross-platform porting point of view.

If you prefer a TL;DR: Bear Chuck Unity web build! <—– click to play

My Unity learning experience started with me making Jack King to learn the ins and outs of how Unity works, and sure enough, it wasn’t simple. The C# syntax was certainly an entirely different beast from Gamemaker’s scripting. But the interface! What a pleasure to work in! It makes GMS’s interface look like movie hacker stuff – Impractical and blinding.

And then I worked with Loet on Rocket Blocks which became Rocketto, Loet offered to help me with porting Bear Chuck to Unity, so I suggested that we tried a smaller project to see how we worked together. Also it was supposed to be for MakegamesSA’s Comp E, but we didn’t have enough time to hit that deadline. Since then Loet’s gotten busy with other stuff (such is life!) and we’ve decided to put that on hold for the time being.

But that didn’t mean the end of my Unity learning! I took what I’ve learned from Jack King and Rocketto so far and started dissecting Bear Chuck to put it into Unity, also with an idea of a new control scheme (ultimately the controls seemed the most needing-to-be-solved part of the Bear Chuck experience).

What I’ve learned of Unity-fu while doing this:

  • Go with Unity instead of against it. In GMS I built my own simplistic Physics engine to make sure things conformed to a pixel-perfect system. When I tried that in Unity it was HELL. Unity’s systems are super intricate and Frankensteining my own system meant I ran into all kinds of problems one after the other (just look at the Unity General Questions thread and you’ll see).
  • The Unity 2D system isn’t quite complete yet. Unfortunately essential functions like IgnoreCollision() aren’t in yet, and that makes things rather dicey. There are workarounds but they’re complex and cause other problems, unfortunately.
  • Though it is already a ton better than trying to do 2D with Unity before the upgrade!
  • You can’t reference SpriteRenderer directly without GetComponent. Something to remember.

I had to do a few things to get it to work more like I needed it to – I cranked Friction way up, I adjusted the colliders to be smaller than the blocks were visually, I made the blocks round off to perfect positions at every opportunity possible, etc, and I ended up with something pretty close to the clean physics a block matching game needed. I like the bounciness of it, and I would never have been able to do that with my own engine.

May I present, Bear Chuck Unity web build! <—– click to play

Right now it’s more of a toy for the control scheme. The bear is a ninja. He can telejump anywhere he pleases (click), to pickup and throw blocks as he pleases (click and drag)

I hoped that this control scheme suits the game and mechanic much better and gives it a legitimate home on a tablet. Though I’m not sure if that’s entirely a good thing, to completely aim for touch devices only. I’ve ideas of making this work on a controller, but… one step at a time!

rAge 2013: 15 made in SA games showing!

rage_mgsa_2013

Every year, I think to myself I don’t need to go to rAge to gawk at the same AAA titles that you can see on Youtube and everywhere else. Every year I end up going because of one thing or another – if it wasn’t me judging the amazing Cosplay for Legion Ink for two years in a row, it was being a booth babe for Otaku Magazine, or organising booth babes for Asus, or whatever. rAge has become an ubiquitous landmark in the geek calendar, and for good reason.

This year’s rAge is gonna be a real special one! Well, every year’s rAge turns out to be special for, but this one will end up taking the proverbial cake. I just know it. I feel it in my bones. Why?

For starters, my game that I’ve been working on Bear Chuck will be playable and on display! And even better, I share the honor with 14 other made-in-SA games! 15 games!! FIFTEEN in total! Even as part of makeGamesSA for the last year, I never realised how quickly we’ve grown.

In no particular order (except of course the first one), here are the 15 made-in-SA games that you can come to check out and play at rAge 2013:

 

Bear Chuck

My page with playable build

Broforce

Offcial page with playable build

Desktop Dungeons

Official page with playable build

Viscera Cleanup Detail

Official page with playable build

zX: Hyperblast

Official page with playable build

Silhouette

Official page with playable build

Pixel Boy

Official site

A Day in the Woods

Official site

Death Laser

System Crash

Official site

Toxic Bunny

Official site

Wang Commander

MakegamesSA thread

Cadence

Official site with playable build

Blazin’ Aces

Official site

Death Smashers

Developers official site

rAge 2013 is going to be amazing! Come say hi and join us for a few games! 😀

Bear Chuck BEAR-SIZED update!

I’ve been working pretty hard on my game Bear Chuck to get it read y for rAge 2013, and I’ve got me a stable build! 😀

I’m gonna just leave this gameplay video to do the talking:

With a brief log of updates:

  • Super improved AI – it actually BEAT ME. More than once.
  • A new menu worthy of the Bear Chuck name.
  • A Brand spanking new gameplay video starring Bears!
  • Settled on the new name Bear Chuck! Just too adorable :)
  • Updated the animation and upgraded the AI a bit more
  • Added a few more effects
  • The combo system now works! Chains will add exponentially more attacks to the other side – e.g. a match of 4 will be an attack of 2, and match 5 will attack 3. Each chain adds a multiplier to your attack – so at combo 2, the attack will be multiplied by 2. E.g.: First match of 4 creates attack 2. Then another match of 4 is the result of a chain reaction – and that attach will be multiplied by the combo factor of 2 for an attack of 4 (2 x 2).

Get the playable build on the Bear Chuck page! 😀

A MAZE 2013

A MAZE is an indie games festival and convention from Germany, and last year’s A MAZE was in South Africa for the first time. It was also around the first time I got into this whole game dev thing. Fast forward to 2013, and A MAZE was back for round two. And now that I’ve been a part of makegamesSA for a year, I could well and truly appreciate the amazingness of A MAZE 2013.

As there was simply too much to ramble endlessly about, and my time is limited due to the urge to make more games, this is gonna have to be a condensed supernova of the awesomeness that was A MAZE 2013.

1. Speakers from all over the globe and of course SA

amaze_speakers

Guys from Nigeria, France, UK, the States, Poland, etc. I was particularly sad that I couldn’t attend the Friday sessions, what with work and all, but I’m absolutely looking forward to videos of those sessions. The full programme of speakers can be found here.

2. Meeting and hanging out with international greats

AMAZE2013

In particular, Vlambeer‘s Rami and McPixel‘s Sos was there, and we got to hang out a lot. Besides being really cool guys, they are also really inspirational individuals who’ve achieved tons. Rami’s keynote about how Vlambeer came about and the very existential musings around how we are all inter-connected (it’s like emergent gameplay! 😀 ) really made me re-think a lot of my own life. Sos’s energetic attitude to game making (his business card: Mad Scientist of Video Games. His credential? McPixel, Achtung Arcade with 600 games.) was super infectious. The opportunity to pick their brains alone were simply amazing.

3. Pecha Kucha!

At the closing party, we had a Pecha Kucha session. Pecha Kucha is a format of speaking where each speaker has 20 slides with 20 seconds to talk. Thatsitgo! Good thing Thorsten (The handsome fellow who’s the A MAZE event organiser from Germany) convinced me to participate – it was an incredible experience, thinking and putting together the material as well as running through it really leveled myself up. Simon Bachelier from France Vined them all, and of course I await full video releases of them from A MAZE :)

 

4. Inspiration!

Seriously, the best thing about A MAZE is the gathering of minds, and the palpable atmosphere of people doing what they love, how they love, and succeeding at it. The sheer force of will is incredible, and makes a great bit rocket behind your back propelling you to do what you should be doing – which should be what you want to be doing. And if that’s making games, then GO DO IT! NOW!

5. OK you can look at some photos first before going to make games

Unfortunately the gallery was obliterated in the Great Blog Crash of 2013. If I have time and energy I’ll resurrect it, but I’m sure you’d rather see new content rather than old stuff :3

Mechanical Proto Juice [My AMaze 2013 Short Talk]

I gave a brief Pecha Kucha (20 slides, 20 seconds each) talk at this year’s AMaze Indie Game Festival about effectively using Juice in Prototypes to communicate Mechanics, and was met with surprisingly positive response from everybody from Vlambeer‘s Rami to Nigeria’s SJ to Poland’s Sos, to our own Cape Townian heroes Danny Day and Evan, Ruan, and co of Freelives

It was a really humbling experience, even if it were only 6 minutes and 40 seconds. Here’s an even shorter Vine of it (big thanks to Simon Bachelier for making this and getting me to use Vine!):

I’ll post the full video of the talk when it’s available, depending on the AMaze organisers.

The full PDF can be downloaded here.

 

And here’s the full talk, without the 6 minutes, 40 seconds limit :)
(Kindly excuse the formatting, web code is not my strong suite and this was a wrangled template… >_<)

 

An introduction, I'm Steven Tu and I'm exactly one year into learning game dev since last year's AMaze festival. I've since then made about 6 prototypes and learned much, I hope this will help aspiring new game makers.

 

This talk is all about conveying mechanics in Prototypes by effectively using Juice.Because we're aiming to make a game (as opposed to a book or a movie or an artbook or a music album), the mechanics are the hardest part to test and refine, so we should be focusing on mechanics.

 

This popular talk "Juice it or Lose it" by Martin Jonasson & Petri Purho is super important for any game makers. If you haven't seen it, it's on YouTube and is basically set material for learning to make games. They defined juice and said adding juiciness makes your game better 100% of the time, guaranteed.

 

But prototypes and games are different! Prototypes are made to test concepts by rapid iterations. Thus, adding juiciness DOESN'T always make your game better 100% of the time! Repeat! Prototypes are not the same as games!

 

This notion came to me while I was making my own game Fling Fight. I had made it quite juicy - it was animated, things flashed, explosions were cool, there were awesome screenshakes, and blocks flew around spinning. It was juicy. Yet when I tested, player were constantly confused and asked "How do you win?" and "What're the scary Xs?" and other seemingly trivial questions. I had made the wrong kind of juice and did not help the players play my game, and thus had failed.

 

It might sound obvious, but we, as indie game makers, have to realise that we have chips in the denomination of time. Working on your game is betting your time on various aspects. If you bet wrong, you'll run out of chips. We can bet Time on things, we can bet More Time on things, but we should never spend More Time Than You Can Afford. So we must be careful where we bet our time and maximise their effectiveness!

 

A game progresses from its start as a bad prototype to a good prototype, then from a bad game to a good game. As you add juiciness to a game, there is a Zone Of Wasteful Juice. Adding more and more juice to your prototype is simply wasteful, as you get no real returns from adding that juice. What returns are those? The ability to test and refine your game further - mechanically!

 

The more frequent an event happens the less loud it needs to be. For example, when Mario's clock counts down, all it does is... counts down. There's no fanfare. When he gets a mushroom, the game pauses slightly, and makes the power-up sound. Notifying the player that it's happened. When Mario gets to the flagpole at the end of each stage, the music, and animation, and fireworks take up significant mind and timespace, because it's meant to be significant and rewarding.

 

In QCF Studio's Desktop Dungeons, they had this cool mechanic - the player healed from exploring undiscovered blocks. Players were having trouble understanding that concept, so eventually they made orbs fly from the dungeon to the players' health bars, and players were like "ohhhhh".

 

In my game Fling Fight, when players matched blocks to clear them, two things happened - 1, they exploded, and 2, they made blocks fall on the opponent's side. But people weren't getting that mechanic, so I added orbs that flew to the other side and turned into falling block indicators.

 

In both of the previous examples, there were mechanics that were not what players expected from other comparable games. That the players didn't understand them doesn't essentially mean that they were bad! It just meant that you need to communicate them better before you can *actually* judge if they were bad.

 

This screen came from Chris Bischoff's gorgeous game Stasis. He had used a disc with text around as his mouse pointer... But people didn't get that, and it was obscuring many things and made clicking difficult. Eventually we suggested that he stick to a more conventional pointer, and he seemed to have bought it. If the circle cursor was meant for an innovative mechanic, it wasn't supporting that by being harder to understand for the average player.

 

You (yes you) have one of the most flexible and sophisticated instruments known to man - your voice. You also have a million recording devices from your phone to your computer to everything in between. You should be making sounds! Adding sounds to your prototype is one of the most effective ways to communicate various things. Foley is the art of bashing things to make sound effects. Look it up! It doesn't have to be amazing, it just has to communicate.

 

From human experience, sounds can communicate good or bad easily. Sounds that go up are usually good sounds. Example Mario's coins, power-up, and 1-up. Also Sonic's rings. Sounds that go down are usually not good. For example, Mario dying, Mario's game over. If you were at the talk I would have voiced those effects for you :) These aren't the only conventions, but they're a good start. Think about what people know when making sounds.

 

Don't waste time crafting everything. Just steal everything from online - tilable art, backgrounds, explosions, whatever. Grab them because you're prototyping and not crafting for the next IGF. Don't steal when you're going for release!

 

This is one of my favourite up-and-coming games, Super Time Force. They do something quite cool - all of the enemies' shots are red, and all of friendlies' shots are blue. Usually, this is important, but much more so in this game since it can get VERY chaotic with a single player controlling up to something like 5 time-warped characters. It helps simplify the player experience, and reduces potential for twitch-speed confusion, which sucks.

 

Your prototype doesn't need raycast shadows when a blurred sprite will do. Don't do full vector art when you're not even sure how your characters will need to move. In my game, I was in a big bind trying to write some full blown basic (sounds like an oxymoron but it's not!) AI for people to play against... But it was super daunting... Then Travis Bulford suggested something - just make the AI pick a few random things and pick one of them to do. Done! No more existential crisis AI to build! Fake everything you can!

 

When people play your game, STFU and watch! Don't explain! Everything you say prevents you from learning about what players don't "get" about your game. Your game must work without you, unless you're shipping a copy of your mind with each copy of your game! Don't deprive yourself! Learn by watching, take notes, and listen!

 

Thanks Evan for this great graph! The more you test and fail, the more you level up. Investing your time chips in polish just makes you take longer till that point of failure, and failing is what makes you try again, test again, and get better!

 

When you're prototyping, you spend time in 3 ways: 1. Making prototype 2. Testing prototype 3. Re-iterate prototype and return to 1. The faster you can get through stage 1 the faster you can return to stage 1. The smaller you can make the lap, the more laps you can do, and the more your prototype improves! Make faster failures!

 

css.php