Casual Connect 2015 Report

A bit overdue, but I'm gonna just drop this here:

My Casual Connect 2015 Report.

Death of Maxis, but of course, right?

Wow, last month was madness. Tons of crap happened. My mother's attempt at matchmaking, Chinese New Year, and a loooong mad rush to meet deadline at work. I was drained and on a verge of burnout the last couple of days. Thankfully, I think I'm better now.

I guess there's not much I can do about it but complain. Poor decision making, disrespecting pipelines, leading to risk quality assurance and if something goes wrong, I will be served on the palate. On top of all that, the risk vs reward is highly unfavorable. It was rather stressful and I will obviously try my best for the sake of my sanity to avoid such a terrible situation ever again. 

Arg.

The month just zoomed past just like that. I mean, I like working on new stuff and gaining new knowledge, but to code with a leap of faith is just irrational and irresponsible.

And this morning I woke up to this: 

http://kotaku.com/ea-shuts-down-simcity-developer-maxis-1689454903

Of course, it is impossible that the Maxis then is the same Maxis now. This just goes to show how fragile game industry studios have become, as if they wasn't fragile to begin with. In the end, your successful projects only allow your studio to sustain. 2 major flops and your studio is on a verge of death. Exceptional cases occur though, like Blizzard, but that's another story, much like how our conventional physics don't work for quantum physics.

You really know you are getting old when you see game studios that you used to love disappear, and how old game studios that are alive today are struggling to stay alive. Bullfrog is dead. Interplay is dead. Codemasters is dead. Westwood is dead. THQ is dead. Troika is dead. Paragon is dead. There is literally only 2 western studios which are still alive and I am still hoping for good games from them: Obsidian Studios (back then Black Isle Studios) and Firaxis games. Man, if Pillars of Eternity dies, Obsidian would be in an extremely bad shape.

And then there are those that completely lose you as a fan because of their change of direction. For me, that's where Bioware stands. I just cannot enjoy their current gen games as much as their older ones. Maybe because they set my standards too high with Baldur's Gate 2; everything they made post Neverwinter just felt cheap, and I'm saying this even after I understand and worked in a game industry myself.

But I'm just a rambling old man, possibly one that cannot move forward with the change in demographics. It has come to the point where I can barely afford time to play the kind of games I like, because there is another game I like better. Technology is evolving so much faster than we can evolve. More scripts are being ran, more excel sheets are being edited, so much code is being compiled and written, so much more art is being drawn. In the end, we are only human, working with 1 keyboard and 1 mouse to input our efforts.

Cheers to what the future holds!

A few things I have learnt (Feb 2015 version)

In just about 4 months, it will officially be my 2nd year working in the games industry. I have been meaning to write about what I have learnt in my 1st year but since I was not doing any real development, I withheld such a post. Now that I was given a chance to handle bigger problems, I would like to think that it is nice to write something up here. So far I have had a hand in porting a game to a platform, created features for an existing game, had a hand in creating an app from ground up, among others tasks like maintaining servers.

There's a few things I have learnt and hopefully other developers will read this to get a rough gauge of what they can expect in a big game company, especially if you are working on maintaining social games. I'm going to leave the very technical stuff aside, like attempting to do unit testing or write safe code. These are more of things you do not really learn in school.

So here are 3 that I can think off the top of my head..

1) Follow existing conventions as much as possible.

This applies to everything. Code, excel documents, documentation, SQL scripts, etc. Usually, there isn't much of a written document on conventions; it is up to you to read what was done, understand why it was done this way, and follow. If there is a flaw or if you feel some way of doing things should be changed, complete your task first and bring it up to higher ups. ALWAYS discuss with the affected people if you are making changes, even if you are the lead. 

When the deadline is tight, there will not be time to do a full code review, so in a sense, everyone is responsible for their code. There WILL be legacy stuff that do not follow the conventions. These are basically stuff that went unchecked for whatever reason. Do not follow them, cut your future junior programmers some slack. When future programmers pick up your code and they start going 'is there a reason why this guy isn't follow convention?', it's going to eat up their time, and time is money here.

2) Readable code vs Optimized code

It is ultimately in the heart of every aspiring programmer to push for as much optimization as possible. But the amount of time it could take to develop it, plus the pain it might cost the next programmer to take over your code can be a high price to pay. General rule of thumb is, if the code has an acceptable speed, there isn't a need to optimize it. 

I cannot stress how important readable code is.  If you have to eat slightly more CPU or RAM just to make your code look nicer, I'd say go for it 100%. I have seen some optimized code that was a pain in the neck to decipher and could completely be avoided at no cost whatsoever. For example, I give you 4 variables to store your values in the database, but somehow you want to make use of only 1 variable to store 3 variables by using bit shifting/masking. Sure it looks damn cool if you are creating something for a school project, but the next programmer is going to take like 30 mins to figure out what you are doing AND why are you even doing it like that. 

The most frustrating conclusion any programmer want to make is "because the previous programmer wants to be cool shit". That's not cool at all.

Another good rule of thumb my colleague pointed out to me is to be able to write code such that it is understandable without comments. Comment ONLY when you are doing weird shit. Also, comment only WHY, not WHAT or HOW. WHAT or HOW should be inferred from your code. If you need to explain WHAT or HOW, time to refactor.  

3) Power must be controlled

Programmers are super powerful. I mean, they are the ones who knows (supposedly) the inner workings of every part of the project. It will come to the point where a workaholic programmer, for the sake of saving time, wants to do everything by himself so that his task is completed faster.  Really, to us programmers, adding an extra text to a properties folder is extremely trivial. Clicking on buttons to, say, generate assets, is also trivial.  

But when communication is difficult, like say your teammates don't work next to you, this can get out of hand. Even when we work next to each other, we had our own share of such problems. Committing text files is fine and all thanks to merging tools, but what about more complicated things like images, or even folder structures? What if the folder you are working on disappeared, or suddenly had files attempting to override your files because they have same name? It gets messy. At the worst scenario, you would have to delete your repository (because you cannot figure out the problem or because it is FUBAR) and re-setup your workspace, taking tons of time because of one innocent commit.

For such unstable pipelines, I think it is inevitable but to assign a go-to personnel in charge of it until a clean solution presents itself. Like no matter how inefficient it sounds, stability of the project is more important. You would rather 1 guy screw up, than a possibly 10 other guys screw up.

[HobbyRPG] Menus!

Progress seems slow for the past couple of months, with my weekends either packed to the brim with events, or just me falling sick. Either ways, progress must somehow be made so here goes:

As expected, this inventory system takes a pretty long time to develop behind the scenes, especially since we were busy these 2 months, with concerts, live viewing, fighting game events, forcing myself to clear my backlog of games and being sick during my free time. I did felt that it would take under 2 months to complete so thankfully it did.

Only that I am absolutely clueless about RPG UI design on touch screen.

It's annoying when I could probably whip out a non-touch-screen design easily but couldn't do the same for touch. There is just so many considerations to take note of and it is rather painful at this moment to shift elements around. So I just whipped up the basic functions and moved my elements so that it is at least usable to me. Making sense of it and catering to players will have to wait =(

Setting up the UI requires a lot more work at the background. XML loading, LUA, additional macros to my XLS and new CSVs started popping out as development progresses. It may not look like much but it's feels like more work done compared to the other components that are in place now. It even involves a rather retarded bug fix within cocos2d-x that should not have happened.

Well, at least I'm going to start moving on to other gameplay elements like transitioning to another map. 

[HobbyRPG] Dialogs!

Dialogs!

Anyway, the last week was basically trying to get the game running on the device since we wrote so much code since the last time we tested (which is like...the beginning of time when we had only like 2 files or something). The thing is that we code in Visual Studio because it's an awesome environment, but our android is setup to use GNU compiler (cocos2d-x has some script that sets up for us). The screwed up thing is that it relies on a Makefile, which means I have to manually indicate which files need to be compiled. Fortunately, after some googling, modifications and thanks to the linux 'find' function (big hint here!), we now that a script that searches for all .cpp files and include them into the Makefile!

Anyway, so far LUA was pretty much pain in the ass. I was constantly trying to convince myself what is the right way to this X and Y mostly because I have like zero experience working with scripting languages on top of a native language. I can potentially write my whole game in LUA if I really want to; that's how much power it has. The only thing that's stopping me is that C++ is still our native (hurhur) language it probably has better performance and memory management (well manual memory management). There are other minor reasons too like wanting to make full use of our IDE, increase performance, etc. This is still a game that runs frame-by-frame, so it just does not make sense to me to write update loops in LUA.

Still, as the game progresses, the stuff that needs to be data-driven starts coming in and that's causing a few decision problems. It comes to the point where attempting to create 'generic systems' need to have feasible and reasonable boundaries, which also means NOT making it too generic. It's normally not a problem, but because I have loads of RPGs to reference in my head, I keep trying to hit all their features. It's really hard. Just the inventory and item system (which I am currently working on next) is giving me a headache. I could easily write out a chain of inheritance in C++ like having a UsableItems derived from a base Items class and then chaining a Armor class out of UsableItems class, but this is really unproductive especially since I have LUA. I'm trying to derive some way to just use one nice Item class. There's just too many variables to consider if it works for the limited RAM in my head, so I'll just code it out and see how it turns out.

Once the inventory is done, hopefully we can get item shops and equipment in and we'll be ready to FINALLY get started on combat. This might take awhile though ^_^;;

[HobbyRPG] tolua++ and menus!

This is turning into some sort of development blog, but from my perspective. Anyway, since LUA and UI were pretty big stuff we intend to add for this sprint, progress was seemingly slow due to time needed to research. I almost went into a huge hole of creating our own UI system but Dom managed to save me by just looking up cocos2d documentation -_-. I think when I figured that I could reinvent the wheel, I would just go ahead and do it without consulting Google or look for existing implementations.
Anyway, a not-so-glamorous progress to motivate ourselves!

For those who can't see the changes, I have neatly boxed them in red, since they are all code-based changes. Dom already told me a bit on how he intends me to use the UI, so I'll work on it once I can find better art. I'll try to follow his idea lol. 

LUA binding is a bitch. Well, it isn't once you know what's happening, but when you have no idea wtf is LUA, it's a bitch. cocos2d-x comes with tolua++ support, and I had no idea what that meant until I spent a couple of hours reading its online reference before I sneezed myself to bed on Saturday night. I felt super terrible yesterday, so terrible that I gave up on implementing it. Today I sneezed less, so I managed to get it working with a few good guesses. 

The documentation online for tolua++ is pretty heavy read for those who don't understand what's going on. Examples and tutorials are almost non-existent; in fact, the best tutorials I found were in Chinese or in Japanese. I totally gave up on the Chinese one. The Japanese one is easier to understand thanks to the existence of katakana. After seeing a few code snippets here and there, I finally figured it out. 

In a gist, tolua++ basically takes in a .pkg or .h file and generate a .cpp file with a function for you to call in your program. Then you just grab the lua state in your program (by right from tolua++.h, cocos2d-x has a wrapper around it) and throw it into the function that tolua++ gave you. I'm too lazy to explain in detail, but here's some poorly made step by step screenshots on how to expose a class to LUA:

First, get tolua++ to run on command line! Download the tolua++ executable and let adjust your Environment Settings' PATH variable to point to it. You know it's working when you open your command line and type "tolua++". The help page will appear:

Go to your project's root and create a .pkg file like so. Note that it looks almost like your .h file. These are the functions you want to expose. 

I must emphasize that the file included in the $cfile line MUST be accessible from the .pkg file's location. If not, tolua++ will complain.  Finally, just run tolua++: 

And voila, if there's no errors, you should magically have a file that looks something like below. If there are errors, well, just try to resolve them. Remember to Google for help (when in doubt, just Google the whole error message).

Add this to your IDE and pray that it works. If it doesn't, you screwed up somewhere in the .pkg file. If you have trouble, remember to Google, ask stackoverflow.com, attempt to find the answer in tolua++'s online documentation and/or actually try to figure out and guess how tolua++ binds your C++ code (it's not THAT magical). 

Moving on, the red box is the function you should be interested in. Simply call this function in your program and pass the lua_state in. The next screenshot is a cocos2d-x example since they have a wrapper: 

And now, when I run my script it works! (script is in first screenshot).

After you have successfully done this, the entire online tolua++ documentation will suddenly make sense! *gasp*

[HobbyRPG] And it has began!

Remember the RPG game I wanted to make?

It took some time, but finally Dominic and I have something visible up ^_^.

This is using the awesome cocos2d-x and my native language C++.  This project is probably going to be very slow since we agreed not to think about monetizing or selling it, and use it as a side project to create the RPG we want to make, which is great since there is no pressure. We can't guarantee if we will get burnt out at some point, but so far progress has been really fun for us!

Honestly, coming out of Digipen showed me how much I really wanted to make an RPG. After over 5 years in studying game development, I have only managed to create a simple text-based RPG game, which was a fun experience. Unfortunately, RPGs are extremely tedious to get it right, so it was not exactly a viable option as a school project, or even for a game you want to sell. Over the past decade, we have only seen the RPG genre decline and decline, leaving only a handful 'good' ones which were mostly cult hits. Hmm, not exactly a good genre to throw money into.

With this, hopefully when we go into design, I can attempt to return to my daydreaming story-writing days. I used to write tons of stories and other crap for fun, but that was easily a decade ago before I picked up programming and pursued to have a sciences foundation, easily obliterating my story-telling abilities and also my English. I can also go back to using Fruity Loops (which is now a full fledged...thing!) and fall onto my rusty music background to create sounds though I have much less hope of that succeeding. 

This project has sooooo much to be done, but it's so fun making each component work. Right now we are still working on the overworld system and already have animations, input and collision done. We also went to excel and write a macro to export stats into .csv files to reading into the game. 

What I like about this project is that it keeps my game development skills sharp, since I am not really doing development as much in my company.  We are also able to put into place what we have learn in our companies into this project, so it is a good learning experience so far.