#ggj15

My first IRL game jam!

I have done a couple of game jams in the past, but they have always been just me (in my PJs) at home in front of my computer. Sometimes I’d team up with my sisters, sometimes I’d team up with my friends and we’d work through Google Hang Outs (since we are in different countries).

But I’ve never tried actually showing up to a venue and working on the spot with a bunch of other people.

I went to Global Game Jam’s Taipei venue, and I’d have to say the organizers did a very good job. Thank you organizers!

The location is big enough for the amount of people (there were 70 of us!), and there was enough tables, chairs, and most importantly, enough bandwidth, and extension cords for everyone. Oh and they had a free soda machine, and gave us free coffee stubs for the 711 next door (no water though, apparently game devs don’t need water to hydrate). They also provided snacks to keep everyone’s brain functioning. And pizza after demo sessions! (Yes, I was just there for the food :P) And their official photographer takes very pretty pictures, which I grabbed and will repost here.

What I liked about the jam is, that there were demo sessions, where you can see what every other team is up to. However, our jam venue didn’t have any fun awards, or audience voting for best game. It would have been fun to fight for some prize, even if it was just a paper certificate.

Another reason I never been to in real life jams before, is because I’ve never had enough game dev friends in real life. I know, I know that you should just show up and meet new friends and stuff, but I’m not really sociable, and my language skills are limited (everyone else speaks Chinese!)

So thank goodness, my current colleagues agreed to join this year’s jam with me. And thank goodness there was 5 of us – enough to form 1 group with no additional strangers (at the Taipei venue, we were all paired into groups of 6). Actually, we were supposed to be paired with a stranger but she didn’t show, so, oh well.

The theme for this year’s jam is “What do we do now?”.

We spend Day 1 coming up with an idea for the theme, and we decided to make a game to raise awareness about Shark Finning. And we also decided to go for a more childish approach, and do all our art assets using origami.

Since everyone in our group agree that dinner and sleep is important to us, we all went home to rest (even though we did spy some other team’s plans to spend the night).

Since most bookstores don’t open until 10 AM, most of us arrived late on Day 2 (around 11, which for me, shouldn’t really considered as late, but all other teams were already there by 9ish), so our only early member Jack had to present our game idea by himself (he even made a powerpoint).

We bought a lot of art papers and spent a lot of time folding stuff based on YouTube videos and instructions.

Arrive at 11 and go out for lunch at 12, since our team loves eating and we had ramen for lunch and took our team photo.

And we got started coding after lunch.

And as usual, we used Unity as our game engine hashtag #madewithunity.

Around 5 PM of Day 2, every team had to present the Alpha of their games.

I lost our game of Rock Paper Scissors (or as I like to call it jack en poy), I was tasked to present.

Only 4 hours of coding in, I was admittedly very nervous to show our alpha. And when I get nervous, I forget all my Chinese and start making shark chomping sounds (our eventual game sound effects were also us making shark chomping sounds – in a bathroom cubicle though, quieter).

I think I have sufficiently portrayed our group as the ditzy lazy group.

But hey, at least our game was playable.

And after everyone’s demos, PIZZA!

We asked the organizers what time we should show up on Day 3, and they advised us that in order to finish by 3 PM, you had to at least get started around 9.

So we worked for a bit more, but around 11PM we decided that we were sleepy, and we wanted to sleep in our beds, so we went home and called it a night.

I had a dream that I woke up around 4:44 PM, so I woke up around 8 in real life.

Arrived at the venue on Day 3, around 9, was still the latest team! (Does the other teams sleep?)

We aimed to finish our game before we break for lunch.

This is how I look like coding (just kidding, I knew the photographer was taking a picture).

“Before we break for lunch” ended up being almost 2 PM, instead of 12 as I’ve hoped for. But hey, at least we finished with time to spare.

And then the final presentation (and yeah, I don’t have to present!).

By the way, our game uploaded on GameJolt (http://gamejolt.com/games/action/the-predator/46158/).

And we even made a video.

And when everyone’s done presenting their games, it’s time for group pictures.

And after group pictures, everyone calls it a day.

Will I do it again? Maybe.

And without further ado, our game… “The Predator”.

Try our game?

Global Game Jam page: http://globalgamejam.org/2015/games/predator

GameJolt page: http://gamejolt.com/games/action/the-predator/46158/

Advertisements

How to create DLLs for Unity?

I guess the first question is Why? Why create DLLs?

DLLs can be used to Tidy Up Unity Code, speed up compile time (a bit)makes it easier to redistribute code and a bunch of other Pros (but also Cons), and reduce deployment clutter and you can literally put everything you need – textures, audio, whatever – inside one file.

Okay, so now, How? Unity actually has a pretty good tutorial on How, but it lacks pictures and fails to mention some quirks.

Let’s get started:

  1. Create a New Solution in MonoDevelop, select C# > Library.
  2. Specify its Name, Location and Solution Name. 
  3. Reference Unity DLLs, by going to Project > Edit References…
  4. Select .Net Assembly, and navigate to: /Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll, and click Add. 
  5. UnityEngine.dll will then be included in the References folder of the Solution.
  6. Add files by right clicking on the solution and Add > Add Files…
  7. Before building, make sure that Mono Soft Debugger Support for Unity is disabled. Go to MonoDevelop-Unity > Add-in Manager… Unity > Mono Soft Debugger Support for Unity, and click Disable.

    Remember to Enable Mono Soft Debugger Support for Unity again, after building.

  8. Also, make sure Target framework is set to .NET 2.0. Right click on the solution, go to Options > Build > General, and set Target framework.
  9. Click Build > Build All or Build > Build <Solution Name>.
  10. The DLL will be saved in the bin/Debug folder of the Solution.
  11. Copy the DLL file to Assets/Plugins and reference it like any normal script.

There will always be a few Quirks:

  1. Cyclic dependencies of DLL not allowed
  2. Can only reference other DLLs
  3. DLLs cannot be edited in Unity
  4. DLL with dependencies will log error, if dependency not included in Unity Project
  5. DLL scripts cannot be in separate folders (Editor scripts need to be in Editor folder -> build separate DLLs for Editor and normal scripts, use Unity Package to sort them into proper folders)
  6. Change #if UNITY_IPHONE script to if(Application.platform == RuntimePlatform.IPhonePlayer) and change #if UNITY_ANDROID script to if(Application.platform == RuntimePlatform.Android)
  7. Editor Scripts not working properly -> needs to create a proxy script to bind to Unity (http://forum.unity3d.com/threads/editor-script-dll-and-regular-script-dll-not-adding-custominspector-scripts.107720/)
  8. DLL with reference to AndroidJavaObject fails to build for iOS

Some quirks which I can’t seem to resolve and I’m hoping someone can help me:

Mini Tutorial: How to batch replace textures with different file formats in Unity?

In relation to my previous tutorial: Mini Tutorial: How to batch convert image files to PVR (for iPhone app development)?

So you have a Unity project that was previously not planned for iOS (for PC, Mac or web or whatever), and you might not be as conscious of the texture file formats (iOS is probably the only one with so many constraints).

According to Unity’s User Manual:

Use iOS native PVRT compression formats. They will not only decrease the size of your textures (resulting in faster load times and smaller memory footprint), but also can dramatically increase your rendering performance! Compressed texture requires only a fraction of memory bandwidth compared to full blown 32bit RGBA textures.

So after converting all my textures (or creating a copy of my textures in .pvr format using Automator), I’m supposed to change all the material textures in my Unity Project and that’s a lot. So I wrote this tiny Editor script to do that for me. It will even delete the old texture (.tga or .png or whatever) from the Assets folder.

So here it is:

using UnityEngine;
using System.Collections;
using UnityEditor;                      
 
public class ChangeTexturesToPVR : ScriptableWizard
{
     [MenuItem (“Project Tools/Change Textures to PVR”)]
    static void MakeFolder ()
    {   ChangeTextures();
    }
 
    static void ChangeTextures()
    {
        string filePath = AssetDatabase.GetAssetPath(Selection.activeGameObject);
        int index = filePath.LastIndexOf(“/”)+1;
        filePath = filePath.Remove(index);
        
        foreach (Transform child in Selection.activeGameObject.transform)
        {    Material[] mats = child.renderer.sharedMaterials;
           
            foreach(Material mat in mats)
            {    string texFilePath = filePath;
                texFilePath = texFilePath.Insert(texFilePath.Length, “Texture/”);
                if(mat.mainTexture != null)
                    texFilePath = texFilePath.Insert(texFilePath.Length, mat.mainTexture.name);
               
                string oldTexFilePath = texFilePath;
                oldTexFilePath = oldTexFilePath.Insert(oldTexFilePath.Length, “.tga”);
               
                texFilePath = texFilePath.Insert(texFilePath.Length, “.pvr”);
               
                mat.mainTexture = (Texture)AssetDatabase.LoadAssetAtPath(texFilePath, typeof(Texture));
                AssetDatabase.DeleteAsset(oldTexFilePath);
            }
        }
       
       
    }
}

If your old textures are in “.png”, just change “.tga” in the code above to well, “.png”.

Select the model (.fbx or .obj file) whose materials and textures that you would want to change.

And then go to the menu and click Project Tools > Change Textures to PVR (yes, I created a Menu item for it).

And then voila!

UPDATE:

I edited the code a bit:

using UnityEngine;
using System.Collections;
using UnityEditor;                     

public class ChangeMaterialTexturesToPVR : ScriptableWizard
{
     [MenuItem (“Project Tools/Change Material Textures to PVR”)]
    static void MakeFolder ()
    {   ChangeTextures();
    }

    static void ChangeTextures()
    {
        for(int i=0; i < Selection.gameObjects.Length; i++)
        {    if(Selection.gameObjects[i].transform.childCount == 0)
            {    changeTexture(Selection.gameObjects[i].transform);
            }
            else
            {    foreach (Transform child in Selection.gameObjects[i].transform)
                {    changeTexture(child);   
                }
            }
        }
    }

    static void changeTexture(Transform obj)
    {   
        if(obj.renderer)
        {    Material[] mats = obj.renderer.sharedMaterials;

            foreach(Material mat in mats)
            {   
                string texFilePath = “”;

                if(mat.mainTexture != null)
                {    texFilePath = AssetDatabase.GetAssetPath(mat.mainTexture);

                    if(!texFilePath.Contains(“.pvr”))
                    {    texFilePath = texFilePath.Remove(texFilePath.IndexOf(“.”));

                        string oldTexFilePath = texFilePath;
                        oldTexFilePath = oldTexFilePath.Insert(oldTexFilePath.Length, “.tga”);

                        texFilePath = texFilePath.Insert(texFilePath.Length, “.pvr”);

                        Texture tex = (Texture)AssetDatabase.LoadAssetAtPath(texFilePath, typeof(Texture));

                        if(tex != null)
                        {    mat.mainTexture = tex;
                            AssetDatabase.DeleteAsset(oldTexFilePath);

                            Debug.Log(texFilePath);
                        }    else
                        {    tex = (Texture)AssetDatabase.LoadAssetAtPath(oldTexFilePath, typeof(Texture));
                            mat.mainTexture = tex;

                            //Debug.Log(oldTexFilePath);
                        }
                    }
                }
            }

            obj.renderer.sharedMaterials = mats;
        }
    }
}

Now, all you have to make sure is that the .pvr and the .tga (you can change this to .png or .tif or .whatever), is in the same folder and that’s it.

That’s about it.

Mini Tutorial: How to batch convert image files to PVR (for iPhone app development)?

According to Unity3D’S manual, when developing for iOS

Use iOS native PVRT compression formats. They will not only decrease the size of your textures (resulting in faster load times and smaller memory footprint), but also can dramatically increase your rendering performance! Compressed texture requires only a fraction of memory bandwidth compared to full blown 32bit RGBA textures.

You can use Unity’s built in PVRTC compression, but according to @ToxicBlob

Not all PVRTC are created equal

http://www.toxicblob.com/files/Not_all_PVRTC_are_created_equal.php

Well, the Unity manual also suggested using PVRTexTool to create your PVRs. They have a GUI tool and a command line tool. (Please read ToxicBlob’s blog on how to install the tool).

Since, my artists gives me a lot of texture files, there’s no way that I’d do the conversion one by one using the GUI tool, so Mac’s Automator to the rescue! I love Mac’s Automator, it’s now my new best friend.

So I made an Automator Workflow:

The shell script:

for f
do
/Applications/PVRTexTool/PVRTexToolCL/MacOS_x86/PVRTexTool -fPVRTC4 -pvrtchighquality -yflip 1 -square -i”$f” -o”$f”
done

EDIT: I edited the previous script, adding “-o$”f”” so that the output file will be in the same folder as your input file.

Just add all your textures in the Get Specified Finder Items part and click Run!

And that’s it!

Build fun games even if you’ve never coded before

Reblog of my AltDevBlogADay post.

“Start developing games straight away. Build your first game in the first chapter.” “Fun and fast paced. Ideal for readers with no game programming experience.” “A cool guide to get into the game industry quickly.”

Doesn’t that sound like an advertisement for weight loss, except for well, making games. Those are the lines on the “back cover” (if eBooks have back covers) of game development beginner’s guides. But can you really make a game after reading the book? That’s what I want to find out.

So I grab a copy of Unity 3D Game Development by Example Beginner’s Guide (written by Ryan Henson Creighton aka Cassie the 5 yr old game developer’s dad) and I will write this blog post as I read through the book and make that game. There also Beginner’s Guide books for Cocos2d (Cocos2d for iPhone 0.99 Beginner’s Guide written by Pablo Ruiz), XNA (XNA 4.0 Game Development by Example: Beginner’s Guide written by Kurt Jaegers) and Flash (Flash Game Development by Example written by Emanuele Feronato).

Some disclaimer, I am not a complete beginner at Unity. I spent maybe a year (two years ago) making technical demos using Unity, for a game art outsourcing company in the Philippines that wants to break out from outsourcing to creating their own games. But I left that company, and country and well, to come to a tiny studio in Taiwan to make iPhone games. So here I am, reacquainting myself with Unity. Hi Unity, I’m Hsiao Wei Chen, nice to meet you (okay, that was lame).

So here we go, first chapter. Chapter 1: That’s One Fancy Hammer. (You can read the first chapter on the PacktPub website) Basically, a little intro about Unity. I don’t think I need to tell you guys what Unity is. And he starts telling us about what type of games you can build with Unity, and he shows us Fusion Fall (an MMORPG game by Cartoon Network)…  “You can make an MMORPG with Unity? That is awesome! I wanna make my own MMO!” screams the excited reader. And then he slams that thought by telling the readers to check the credits. You need to clone yourself 79 times, according to the author, and send yourself to school to study various disciplines.

Okay, so no MMO, so what game are we gonna make, Mr. Author sir? Then he points us to games on Blurst and Wooglie. Casual games? I don’t know about you, but I love casual games, I mean that how I got into this business in the first place (read about how I stumbled into this whole game making business on Gamasutra, in case you’re interested, but you’re probably not, anyway, moving on). Okay, casual games it is then, because we need to “Walk before you can run (or double jump)”. And then it’s hammer time, head on over to the Unity website and download well, Unity, and then install install, and then launch!

And then he starts explaining the interface. I took down some notes:

(my “notes”, forgive my terrible handwriting)

And then we move on to the next chapter! Chapter 2: Let’s Start with the Sky. Are we going to be making skies? Read on, the author asks us, “It’s time to build a game, right? But how do you start? Where do you start?” Um, I don’t know, you tell me. He tells us, that every game starts with an idea. But the number of ideas you come up with doesn’t matter. “The one thing that separates you from success is not the number of ideas you’ve had or the number of projects you’ve started and abandoned, it’s the games you’ve finished that count.” Is that directed at me? I have a tendency to have a lot of ideas, starting a lot of projects, but never finishing them. That line really struck me, sir. Yes, sir, I will try to finish my games, okay not try, I WILL finish my games.

And then he talks about “The Siren Song of 3D” (how beautifully put). He says that before we even begin, the odds are already stacked against us! That’s a mean thing to say. He points out that games like GTA, Mario or Fall Out 3 is they have “an animated character or first-person camera moving around in a physics-based environment; a rich and detailed 3D world with maps… teams of hundreds of people burning through multimillion dollar budgets…” Okay, we get it, we can’t make MMOs and AAA quality games.

And then he starts talking about features vs content, and giving a lot of examples of games along the way. The summary: “By cutting features from your game ideas, you can whittle your design down to a more manageable size than by cutting content”. Okay, got it. Can we get started now? I want to make some games! (or at least one game, before the night is over).

Chapter 3: Game #1 Ticker Taker. Yeah, finally! So what game are we going to make? Volleyball. He wants us to make a volleyball game, I hate volleyball (or rather, I suck at vollyeball). But he did ask nicely for us to pretend that we are totally pumped about volleyball. Fyeahvollyeball!

*takes a break to do the laundry*

Okay, now where were we? Oh yeah, game, and volleyball. I love volleyball. Read, read, read. The author Is explaining the rules and the complexities of volleyball and he came to conclude: “You + volleyball game = badIdea.” I know right, really bad idea. But then he insists that volleyball is my dream, my passion, that is why we must strip volleyball down to it’s bear essentials and start from there. Okay, he instructs me to get “a red pen and/or machete”, gotcha. Okay, I have my machete, who do we kill? -Sets, teams, multiple players, net, referee, spectators, and then the player. Wait, what? We’re even killing the player? What’s left? A ball. A ball floating in midair. A ball that cannot touch the floor. And something to bounce the ball on. Okay, I can work with a ball (in fact, I think I can even make a 3D model of a ball in Blender).

So let’s go to Unity. Create new project and then add a new object to the scene, a sphere, which will serve as our ball. So we name him, Ball!

(more “notes”, before and after)

He says that our ball right now is between the ground (half above ground, half below ground). And we must move the ball up to the sky. We change the Y position of the ball to 2 (in the Inspector panel). Okay, that was easy. Next, he complains that our ball is too big, so we scale it to 0.4 for X, Y and Z. Okay. Next step? Save the scene.

Now, we have our ball, next is our paddle (the thing that we are going to have our ball bounce on). We create a cube (Game Object > Create Other > Cube), and we name him Paddle, and then we scale him, so he’ll look less like a cube and more like a paddle. Alright then.

And then we add a light to our scene.

(our ball and paddle used to be dark an dreary, now it is all lighted up. like a make up commercial)

And then we test our game! We hit Play. *those black crows from Japanese animes fly by* Nothing happens.

The author is pulling our leg, he wants us “to test your game at this point, even though nothing happened, to pinpoint that magic moment when Unity becomes awesome.” Okay, well, I can’t wait for things to become awesome.

Add physics to our game! Click on Ball in the Hierarchy panel, and then go to Component > Physics > Rigidbody, to add a Rigidbody to our Ball. And make sure that Gravity is checked in the Inspector panel. And we could hit play again (at least he is telling us to hit play again). Our ball fell down and hit the paddle! Whee! It was “especially cool” (he says I can get ten points, if I said that that was especially cool).

Next, we want our ball to bounce. Because, in real life, ball bounce, right? At least volleyballs bounce (I know that much about volleyballs). So we set the Material property of the Sphere Collider of our ball to Bouncy. And press play again, and it is magically bouncy! “Especially cool”! And that’s the end of chapter 3.

But the ball just keeps bouncing and we can’t do anything. So we have to move on to the next chapter, Chapter 4: Code Comfort. So it’s time for some coding. Nervous? But the advertisement says that: “Build fun games even if you’ve never coded before”. I guess this is the part that will decide whether a book can really teach someone to make a game. Well, it’s 37 pages of condensed lesson in scripting.

The question at the back of my head: do I really want to read about scripting?

*will rest a bit tonight, will take on that chapter tomorrow*

Next day, a new chapter. Chapter 4:  Code Comfort. Here we go! I’m just gonna read it through for and give you guys a short review of what I read.

*reads*

Okay, done. This chapter starts from the basics, in an easy to read and easy to understand way for the readers, whom the author assumes has no background at all in coding. For one thing, he compares functions to a hoagie, the curly brackets being the buns, and the scripts inside as well, the tomato, the salami, the mayo. And a variable to a bucket, which contains things, you know. He also teaches the readers how to access the Unity Manual and Scripting guide and how to make sense of it. He also lets the readers try out code every step of the way. All in all, the author is actually quite a fun read, because of his wit and humor, and it is nothing like my Computer Programming 1 professor, who tends to drone. So, I’m done with Chapter 4.

I do realize that this book has 380 something pages and 12 chapters. And this blog post will go on like forever If I continue in this fashion. So um, I’m going to stop here.

Overall, I think this book is easy read, it’s not intimidating in such a way that it bombards you with information, code bits that you can’t even begin to grasp. I think that beginners, even those who have “never coded before” would find this book easy to digest, and might even be able to “build fun games”. For those who are interested in the book, you can check it here. The book actual offers samples codes and projects that you can download even if you haven’t bought the book, here.

By the way, you can also read my review of Cocos2d for iPhone 0.99 Beginner’s Guide here. But my conclusion after reading that books is: “Overall, I think this book is a very comprehensive guide to anyone, who has a bit of background in programming, and wants to start making games using Cocos2D.” Note, I said that it will be a good guide to anyone with a bit of background in programming.

So can someone who has never coded before learn how to make games by reading a book? That was the question at the beginning of this blog post. I guess it’s hard to tell, I’ll have to say it’s:

( sign from Mythbusters)

By the way, Packt Publishing gave me these books for free to review. Why? It’ because I’m a blogger and I occasionally blog about Cocos2d stuff. You can get free books too, if you are a blogger/ webmaster/ reviewer for a magazine or a popular and relevant website / educator in an academic institution, just email you details to reviewrequest@packtpub.com. If you’re not those, you can also exchange an original article that you wrote of course, for a free book. More details on the Packt website.