Dev Update #14 – Concept Graphics and Aspect Ratios

Have your base (classes) covered!

In spite of what I wrote in my previous blog post, I realized I need to create one more department before I can finally tackle the Build Menu: The Management department. Like the Design department, this one works differently from the production floors. This makes a difference from the coding point of view – as I want a base class to take care of all floors, and then handle only specialized stuff in derived classes. And like I said, I want all my bases covered.

Here is the mockup graphic for the Management floor:
Management

The idea was that a Management floor can employ up to four development directors. Each director would allow for one game to be in production. This way the player can work on multiple games at the same time. But I made a pretty noobish mistake when creating the above mockup – I hadn’t given any thought to the aspect ratio of my floors.

Aspect Ratio, anyone?

When creating the actual game graphics for this floor based on this mockup, I ran into some trouble. I hadn’t really thought about aspect ratios and screen width when I created those images. That was a big mistake, as it turns out. The mockup screens were too wide. There was simply no room left on the right side of the screen for the two big purple buttons, not unless I scaled the height down.  But then everything else in the floor would become tiny. To counteract, I would have to scale up the characters. But then I didn’t have enough room above the head of the managers to put the actual game icons. My characters were simply too big.

So I redesigned that department completely. Here’s the result (middle floor):

BlogPost15

Instead of placing the icons above the characters’ heads, they were placed next to them, sorta like a PowerPoint screen in the background. It actually gives it a nice manager look and feel. And as a bonus, this will free up some screen space at the top of each floor where I have been wanting to put a floor number. In another change, the Release and Trash buttons on the right are done away with. Instead, scripts can be released or trashed by clicking on them and opening up their details dialog.

I definitely learned my lesson and will create future mockups in a sensible aspect ratio.

Now, this time for real – next up is going to be the build menu.

Dev Update #13 – Code and Design Departments

It should have come as no surprise to me that spending my free time working on a game directly clashes with writing blog posts in that same free time. And one of these things simply comes more natural to me than the other. So it’s been five months… Time for an update.

I really want to start working on the build menu, but before I can do that, I need a few floors that I can actually build. So I created basic prefabs for the Code and Design departments.

Here are the results.
BlogPost12The Code department layout (top) represents the basic layout for all the basic production floors. 3D Art, Animation, Sound etc… they all will share the same basic setup with three queue slots. The Design department (bottom) works differently and needed a special setup. So it made sense to create these first and cover all my bases.

In my original game design document, the workers would all sit with their backs towards the player. This was mainly due to my poor drawing skills. But for the actual game I found this to be too boring. So instead, I turned them all around, so that they would be facing the camera.

The floors all use the same background graphic for the floor, which is actually grayscale. The graphic is tinted in realtime with the color of the floor.

Please keep in mind that the floors are not really finished yet. The coder for example doesn’t even yet have a computer in front of her. But it’s good enough to work with. Now I can start creating the menu that let’s me build floors into my game studio tower.

Dev Update #12 – Game Name Generator

I like to get all unpleasant work out of the way first – but I allowed myself a little fun task this week: A Game Name Generator!

blog_gamenamesFor my game Game Tower I need a bit of code that randomly generates game names for the virtual games the player creates.

This was probably the most fun task of all the work so far!

Pattern Matching

I went for a simple pattern matching system. The generator picks a pattern at random from a long list and then replaces the placeholder wildcards with random words from others lists.
Here are a few examples of such patterns:

<name> and the <noun>
<noun> Tycoon

The generator would take such a pattern and replace the wildcards with words from a list of pre-approved words. The wildcard determines which words match – there a nouns, verbs, names and plural forms of nouns. When all wildcards are replaced it spits out the finished game name, for example:

Jesse and the Unicorn
Waldo and the Zombie
My Mom and the Warlock
Zombie Tycoon

It’s soo much fun!

I added the name generator to my debug menu (see Dev Update #9) so I can test it out and generate new game names when I feel like it. It works great and I find myself adding new words or patterns to my database every few days, because it is simply that much fun.

GameNameGenerator

Good ideas come … while in bed.

All patterns and words are kept inside my trusted Google Spreadsheet. I have a macro that can convert them into a string list quickly, so I can get it into my code fast. I can access the spreadsheet from anywhere – and this has already paid off.

Like all coders (I assume) I have a lot of good ideas in bed. When I have a fun idea for a new pattern or a noun to add to the list. I can just reach for my phone and punch it in.

More updates and screenshots from the game in progress coming up soon!

Dev Update #11 – Tip of the Day instead of a Tutorial

I would like to see if it’s possible to make Game Tower a game that can be played without a needing tutorial.

It’s not that I would shy away from implementing one. But when I pick up a game, I would like to start actually playing it right away. So this is an experiment I will try. There’s two plans of attack I have for this: Giving the player more features only over time and a Tip Of The Day.

Tip of the Day

I like loading screen-tips in games, because I can easily ignore them when I don’t want them. A tutorial forces me to click at a sequence of buttons in a specific order and is much more restrictive. That is fine for other games, but feels like overkill for such a simple game like Game Tower.

BlogPost11More coder art for your enjoyment! Ok, I know that this is bad, even by my standards. But my plan is to get the entire game done and working. Then I can see to it that the graphics are replaced by someone with actual talent.

So I created this quick’n’dirty Splash Screen and a Tip of the Day database. A random tip is displayed every time the game is started. The game will load the player’s tower in the background while the screen is displayed. There is a minimum display time of 4 seconds, to give the user a chance to read it even if the loading is done faster.

Easy to Learn, Difficult to Master

Probably everybody has heard of Bushnell’s law, that good games are easy to learn and difficult to master. The actual quote is a bit longer and also mentions rewarding the player (here is an interesting blog post about it). But I’ll stick with the short-hand version for now.

Applying that to my no-tutorial experiment, it should be possible to make the game easy enough in the beginning that there is no need for a tutorial before the player can start actually playing. I will have to do some more trial-and-error testing, but my current plan is to provide the player with three basic floors instead of an empty tower at game start. That way he can immediately jump in and start producing games, rather than worrying about building the correct floors, hiring people etc. Essentially I want the player to learn the core gameplay first – and then get into the finer details as he levels up.

The level-up design should come in really supportive here as well. Since the player unlocks more departments and larger game designs by leveling up, the complexity of the game already starts out small and grows larger over time.

If at first you don’t succeed…

…make sure you don’t blindly ignore if something is just not working.

Making Game Tower playable without a tutorial is something I want to try. But I won’t stick to it like it’s set in stone. If in the end I discover that the absence of a tutorial makes the game to confusing, I will mark the experiment as failed and provide a tutorial. After all, the game is meant to be played.

P.S.: I am also playing around with different names. That’s why that screenshot reads “Game Studio Manager” instead of “Game Tower”.

Dev Update #10 – A Resolution Independent Tower

As promised I will post some updates about what has happened with Game Tower in the last weeks.

Creating the actual tower with all it’s floors was a little more difficult than the creating the overlaying UI and the menu screens. The main problem here was the various resolutions that needed to be supported. It’s a mobile game and with the multitude of phones and screens out there, it needs to be basically resolution independent. Buttons and other nine-sliced UI elements can stretch or be anchored and adjust themselves to different resolutions fairly easily. But the individual floors inside the game area are a different matter.

The floors should adjust to the screen size, but without squishing or stretching the graphics. Because of the different screens, the width of the tower is unknown. The tower doesn’t have a fixed height either, since I can add more floors to it as I play. This made it slightly difficult to set everything up.
BlogPost10I want each floor to use the entire width of the screen. Of course the graphics shouldn’t be squished or stretched, so depending on the width each floor then adjust it’s height to match the original aspect ratio that I designed it for. This would mean that the floor graphics look the same on all devices, but the amount of floors that are visible on screen at the same time depends on the aspect ratio of the screen of the phone it is being played on. Thinner or longer phones would show more floors than wider or shorter ones.

The new Unity GUI system is still fairly new to me, so it took me a little longer to figure this one out. But it finally worked. My code now calculates each floor’s position from it’s height, and the height is calculated from the width. Technically the game can handle it if the screen is re-sized in the middle of the game. Even though that would be impossible on a real phone, it’s just something I feel good about. The floors and their content keep their aspect ratios and adjust with the screen resolution, and I can even already scroll through the tower by dragging up and down.

There are more updates coming, next up is a startup screen with gameplay tips!

Lots of progress, but not a lot of updates

I realize I haven’t posted since the new year started and hang my head in shame for that. I have been working on Game Tower quite a bit and have a lot of progress to show for it – but somehow I never found the time to post any updates.

Now with the GDC out of the way, things should slow down a little. In the next weeks I will start sorting through everything and post a few updates about what happened with the game since Christmas.

Dev Update #8 – Let the implementation begin!

With Thanksgiving finally out of the way, I have enough peace of mind for another blog post, even if it is just a short one.

Finally I found the time to start the actual implementation of Game Tower! It felt really good to finally create a new project and folder structure in Perforce (Yes, Perforce. I prefer it over Git.)

It will be fun implementing the functionality as I have written it down in the design document. Since the major design work is done, I should be able to focus mainly on the technical side of everything.

Unity Logo

For the implementation of Game Tower I chose the Unity engine. I don’t know it as well as I do CryENGINE yet, but I have worked with it before on two other games (Boob Rescue was made with it as well).

I think Unity is perfect for this game, because I can easily get the game to run on both iOS and Android (and Windows Phone – as per special request from a friend). And it is so ridiculously fast to do anything in this engine that I find myself moaning every time I have to do anything in any other engine now.

Since Unity has just released their new GUI system, I want to use that for Game Tower. I have previously used NGUI, and the base of the new system was written by the same guy, so I expect good things.

 Enough for today, I will post more soon.