Steven Tu / @Tuism Indie Game Maker, Designer, Illustrator

Results for tag "makegames"

6 Articles

Bear Chuck learns Unity

2 Comments
tuism

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!

0 Comments
tuism

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!

0 Comments
tuism

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! 😀

Mechanical Proto Juice [My AMaze 2013 Short Talk]

0 Comments
tuism

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!

 

MakegamesSA.com Comp B: 100% Gameplay, Keep It Simple, Stupid!

0 Comments
tuism

MakegamesSA.com runs these cool little competitions to encourage and kickstart interested game makers into making something cool. No prizes, no just the backing and feedback from a passionate community of cool peeps and UNTOLD GLORY on offer. The RGB paint hasn’t even dried on Comp A: Pixel Art yet (well, deadline’s over, entries are all in, but we haven’t had the feedback session yet), and Comp B has already kicked off.

 

Take it away, take it away, take it away now

[quote]A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.[/quote] - Antoine de Saint-Exupery

What a cool theme it is again! It’s all about keeping things simple, concentrate on one really really simple gameplay element, and simplify it yet some more.

 

Inspirations

This spirit has been seen in a few games, this one called Divekick was something I hadn’t seen but so Oh Em Gee:

There are other games which I know that simply defy the world with their simplicity in awesomity:

 

Super Hexagon, the most beautiful and DIFFICULTESTEST left-right game ever:

 

Canabalt, the first and still probably the best one-touch runner ever:

 

Pixel Towers, one touch tower-building at its finest:

 

Orbit1, a one-touch, four player multiplayer feast of iPad spaceship fun:

 

Passage, a game telling a story of a life in minutes (or so I’ve read, gonna give it a play now :P)

 

Do you know any inspirational minimal games? Get over to the competition thread and check it out! There’s a lot more info and inspirations to be discovered there!

Thanks to @dislekcia Danny Day for setting this up, let’s go think simple, but big!