Gamieon is a privately owned entertainment software development company located in Tampa, Florida. Since October of 2004, we have aimed to provide quality video game software which emphasizes both intellectual and action-driven challenge to the gaming community. Gamieon depends on the talent of individuals working as a team to develop video games and video game engines with a focus on exceptional game play and surrealism.
When developing Domino Arena, I experimented with using diamond/crystal shaders for the dominoes while deciding the look and feel of the game. I found a mobile diamond shader at Wiki.unity3d.com by BurningThumb. It worked great for most PC's (there was one report of the dominoes not rendering however), but it was slow on my Asus EEE tablet. I could not get a frame rate better than 30 fps during normal game play.
The Unity profiler revealed that much of the time spent working in each frame was with transparent rendering; partly because of the dominoes, and partly because I called GUI.DrawTexture() way too much (which I fixed).
I'm very inexperienced with shader development, but I figured the least I could try was commenting out all code in the shader that had the word "Transparent" in it. To my surprise it actually had the desired effect: The frame rate went back up to 60 fps, and the diamond dominoes still looked like diamond dominoes with an unexpected caveat: They look transparent where they did not before. I don't exactly know why (again, I'm not an experienced shader developer) but it wasn't a big deal since dominoes don't obstruct each other during normal game play anyway.
Here's the shader code I ended up with (you can tell which parts I commented out):
If you want to see it in action, just check out my game Domino Arena when it comes to Android!
With every new project I try to make better tools to carry into my future projects. One of them has to do with the game configuration and PlayerPrefs. There are two issues I have with PlayerPrefs:
So I decided to make my own static class that not only addresses both issues, but does so in a way that I find convenient for organization. I call this class the "ConfigurationDirector."
The Preference Cache
For those of you who learn by staring at code first, or just want to copy it into your project, here you go:
In short, what I do is call PlayerPrefs functions when I need values that are not cached in memory, and just read from memory at each subsequent Get. When I Set values however, I have to write to both cache and PlayerPrefs. Setting is, however, a fairly rare event.
Doing a dictionary lookup at each frame is of course not as fast as just grabbing the preference value in Awake() or Start() into a member variable and using that member variable in Update() or OnGUI(); but I don't notice the speed hit even on an iPhone 3GS and I like knowing that the preference is always up to date so long as I use the ConfigurationDirector properly.
So you need to track your player's name, their high score, the class they're using for the current game, the color of their uniform, the game difficulty level, the music volume, the IP address of the most recent server they played on....and that's just the beginning!
I chose to bring order to that chaos by having my own system:
If I want to get the player's name, I do:
string name = ConfigurationDirector.Player.Name;
Doing this has two advantages: No more remembering the key you assigned to that preference from outside the ConfigurationDirector, and you know from the context (Player) that it's a player-specific preference. I also know that anything following "PlayerPrefs.CurrentSession" applies to the game in progress, and anything following "PlayerPrefs.Audio" must be related to volume controls. I'll let auto-complete do the walking for me.
This is how I manage configurations in my recent games, and it works well for my purposes. If you're not happy with how you maintain your game's configuration, or you forgot the preference key for the player name for the 8th time, it might be worth looking into doing something like this.
For the past few days I've been dealing with a puzzling issue in Unity: Every time I called Application.LoadLevel to change the scene in my game, this would appear in my console window:
The referenced script on this behaviour is missing!
This is despite the fact that I had no missing scripts! Based on my own logging, I determined this was happening before the next scene was loaded. I ultimately found that there was an internal issue with the prefabbed objects in the scene that was to be loaded (the ones that show in blue in the hierarchy window).
I was able to eliminate the warning by:
1. From the editor, open the scene that was to be loaded during the game.
2. Go through every prefabbed object and Revert to the original prefab state.
3. Go through every prefabbed object and change all the object properties back to the way I wanted them.
It was a bit of tedious work, but the warning stopped appearing after that. My guess is this happened because I deleted a script without detaching it from some of my prefab assets first.
I hope this helps someone out there who may be experiencing the same problem and just can't pin it down!
Unity developers are familiar with
But if you want a text field that only accepts numeric input, then you could accomplish it with some Regex filtering:
myText = Regex.Replace(GUI.TextField(myRect, myText), "[^.0-9]", "");
Now suppose you wanted to contain it all in a function. The first thing that comes to mind is:
string result = Regex.Replace(GUI.TextField(r, n.ToString()), "[^.0-9]", "");
Looks fine on the surface, but there's a glaring problem: It can't handle empty inputs. If you want to treat 0 as an empty input and change the function handle to it accordingly, you could do that. I chose to go this route:
string result = Regex.Replace(GUI.TextField(r, n.HasValue ? n.Value.ToString() : ""), "[^.0-9]", "");
Rather than processing an integer, I process a nullable integer. This way I can discern valid from invalid input without using sentinel values.
(Credit to Labs.kaliko.com for the expression ... and a special thanks to the author for actually including the namespace in their code snippet! )
I promised myself I would not do any more large projects without working in teams, but I never said anything about small ones. Even with the small ones however, I'm stuck with the same problem I have with all projects: I'm not that great at creative and artistic direction.
Consider my latest project "Domino Arena," possibly the smallest one I've done myself besides Paper Cowboys. It's a multiplayer "party" puzzle / action game where you have a playfield full of colored dominoes, and you manipulate places in the playfield where one domino knocks over more than one at a time such that as many dominoes as possible match your player's color.
You can see a concept video on YouTube:
I think it will take a tutorial and a little getting used to, but it could be fun. I'd at least like to pitch a beta around to see what people think when it's ready.
Now that the basic mechanics are defined, I need to figure out how the game will look. I've narrowed it down to three styles: Cartoon, "Jeweled" and semi-realism.
As a mobile developer, my first thought is always "cartoon" because all the popular and top selling apps that come to mind are all cartoony or at least have vibrant, pleasant art themes. Every "party" game I've played also shared similar traits. After looking at a bunch of mobile board game and Mario Party screen shots, I experimented with a scene using cell shading and six spotlights.
It's clear where all the dominoes are and everyone should be able to discern the blue from the gold dominoes...but the environment colors just don't look right to me. I'm concerned that if I make them brighter, then the dominoes will blend in more and players will have a more difficult time seeing them. If someone were to help with art direction, I bet this could work. Otherwise I can toy around with this a bit more.
During development I asked myself "what other games have game mechanics that rely on color?" The first game that came to mind was Bejewelled. After finding some gem shaders on the Unity Asset Store, I came up with a weird, wild theme of jeweled dominoes in dark scenes that keep the player's focus on the game's primary objects.
The word I would use is "bizarre." The mechanic and the style seem altogether foreign from anything I've played before...but that could be a good thing. I do like looking at the pretty colors, anyway. I could also have players "collect" the jeweled dominoes that match their color when a game is over, and have the grand total maintained on a leaderboard.
When I'm in doubt over style, I always turn to wood textures because i find them pleasant to look at. It's hard to see in the picture, but the dominoes are reflecting on the floor.
I thought this would look better as I was working on it; and the white dominoes on wood looked fine when the simulation began....but when they got colored, they just seemed out of place with the rest of the scene to me.
For me it's a close race between cartoony and jeweled with a lean toward jeweled. If I had to decide this moment, I would make a beta with a tutorial, three multi-player jeweled levels, computer player support, and just throw it out there and see what happens. If it gets a positive response, I'd work it to completion; otherwise it's still an eye catcher I can add to my portfolio.
First off: If you haven't already, you should watch the video "Your first f2p [free to play] game: where you will go wrong." at Edery.org . This will tell you much more than this blog and from someone who has more experience. Thanks go to jbadams on GameDev.net for pointing this out.
One of my ad-supported mobile games has been on the market for the better part of a year, and I'm in the process of removing ads and putting in microtransactions to see if they will bring in more income. I'm a neophyte when it comes to designing apps around monetization; and while studying a few AAA apps doesn't make me an expert, it has given me some ideas that I'd like to try with my games and share with other developers to critique.
In Hamster Chase you can earn coins by skipping levels. In the next update, players will be able to buy them, too. Here is the in-app screen I designed to appear in the game when a player wants to skip a level but does not have enough coins:
These were the considerations I made in the design:
In-app screen design aside, here are some other ideas I'm running with in this next update:
DO: Have boosters that players can purchase to win the game more easily.
DON'T: Hide the fact that players can purchase boosters if they don't have any.
DO: Let players purchase a booster immediately when they want to use one and they have none.
DON'T: Make a player go to an entirely different place in the app to purchase something.
DO: Consider allowing players to also earn boosters without purchasing them.
DON'T: Give away so many free boosters that there's no point in purchasing them.
DO: Think carefully about every detail in the appearance of an in-app purchase prompt.
DON'T: Just throw together an in-app purchase screen with minimal effort.
DO: Consider having more expensive boosters to let players win the game more easily than cheaper boosters.
DON'T: Charge $37.99 for a booster.
(Counter-point: If someone is willing to pay $37.99 for it, why stop them?)
DO: Let the player discover they want or need something before presenting the opportunity to purchase it.
DON'T: Harass or pressure players into wanting something with repeated pop-ups or waiting screens.
DO: Consider selling players non-boosters that just make the game more fun, such as hats or skins.
DON'T: Try to sell anything to a player unless you either give them a free sample or explain what the item is for.
DO: Study the in-app flows of popular games similar to yours to learn how players find their products, and see how they are encouraged to buy them.
DON'T: Prioritize making money over making a genuinely fun game or having fun making one.
(Counter-point: It's easy for me to say because this isn't my full time job)
And now, my golden rule of in-apps:
DON'T: Force players to buy anything to finish a free to play game.
Paper Cowboys is now on GitHub in three flavors; each one utilizing a different network engine. Paper Cowboys is a simple side scroller that supports up to eight simultaneous players in co-op mode. You can get it by following this link:
The three flavors are:
Which one should you use? Well, I find that Photon works the best out of the box because of its room management system letting players find and join your game without you having to open firewall ports and such. However, you should not decide before reading this excellent blog:
I don't believe I'm yet experienced enough to help you decide. Once I've actually had hundreds of players play all at once, then I'll know better.
Over the past three years I've spent my free time releasing and maintaining three unique games for the mobile platforms (Hamster Chase, Hyperspace Pinball, Tiltz) and three games on the PC platform (Cycles3D, Hyperspace Pinball, Paper Cowboys) doing all the programming on my own. Along the way I've accumulated a fair bit of general game development knowledge that I can use in future projects; most recently, how to develop a network game in Unity.
Despite the past successes, I still feel unaccomplished. I'm therefore setting my sights on my next goal:
Having a game on Steam, Desura and Indievania for professional game developers may be par for the course; but to me, having helped develop just one game that made its way to Steam would be my personal super bowl ring.
Could it be Dominoze? Maybe. As impressed as people have been with the latest concept art, there's not a solid design behind it. I don't think it will get there unless I find a talented designer and other help.
Could it be a successor to Paper Cowboys? It's possible. I was also tinkering with a tower defense game called "Lone Star Zombies" which imitates mechanics from the success Starcraft 2 mod "Mineralz" and a custom Killing Floor server I like to play on. Like with Dominoze, I seem to not have any inspiration for design. I can make a cookie cutter platformer or tower defense game, but there's a certain signature, personality, and quality of detail to a PC game that I just don't factor into my designs.
If there's one thing I've learned in the past 20 years, it's that I can program almost anything I put my mind to. I can be a helpful asset to a game development team who would have a part-time programmer like me. I may not quit my full time job developing medical software and put 40 hours into a week writing games, but my projects speak for what I can do in 48 hours, and what I can release in a year.
If you're on a team and need a programmer thoroughly familiar with Unity, or you're an individual who just feels like collaborating on a game, feel free to drop me a line.
In the meantime, I'll be working on the next major update for Hamster Chase: Boosters and hats!
Got more sound effects set up, cleaned up the instructions a bit, and added a "Join random game" button. The Photon Network seems to be back up, so I had a chance to do some online testing with some folk at Develteam.com . Here are the bugs we found:
1. Ghost characters -- I don't know why, but sometimes a player duplicates themselves.
[FIXED] 2. Boss HP bar is misleading; if there are multiple players, then the boss has more HP...but the bar thinks there is always one player. Also, multiplying the HP by the player count is a bit excessive; maybe multiply it by the number of players times 80%.
3. It should be more obvious when a player is dead and waiting to respawn.
[FIXED] 4. On at least one occasion, players respawned even when everyone died
5. A number of errors in the Unity console that I won't spam you with here.
I -may- have fixed the issue where a player can appear more than once, and added a skull-and-crossbones icon that appears to the left of a player's name when they're dead. I also made a decision knowing it's probably a bad one: I'm going ahead with level 3. I managed to get the background art done, and the camera to follow the player when jumping vertically, and have the player die if they fall off the bottom of the screen.
I'm rather fond of the background art -- I drew it by studying a picture of the grand canyon and just "sketching it."
I finished level 3 sooner than expected; but that's probably because I cut corners to wedge in more time for overall testing. I recycled the same old enemy prefabs and put almost no effort into the boss. It was a pleasantry to see that I could still make it look half-decent with just one "stepping stone" bitmap instead of the several I had planned on drawing. I think this level is the hardest because it has a strong respawning enemy presence. I still haven't been able to beat it solo.
The rest of the time was spent on adding links to the title screen and game-wide testing.
This hour was devoted to bug fixes:
I also starting working on a bug where you sometimes could not start or join a game.
Here's how my desktop looked for a good portion of this hour:
I spent a lot of this hour fixing the "Sometimes you can start / join a game." bug. I tried to get gamepad integration in as well, but I ran out of time. I might have to turn this into an extended "50 hour" jam.
I could have just settled on two levels with less bugs; but I let the chaos side of me, the "cowboy coder" if you will, make the call. I'm paying the price for it, but you know what, this was all done in good fun. It was a very nice holiday from the usual grind of serious game development.
Nope...I still need to write the post-mortem! Stay tuned!
Six hours is a short amount of time to blog about, but I have to pause development of Paper Cowboys because the Photon Cloud service that powers the game's networking seems to be down right now. I won't be finishing the game this weekend (let alone releasing it).
Made some good progress on level 2: After studying some images on Google, I drew three box cars, a coal car, the engine and some tracks. Then I used them to begin building the train for level two. The next step is to get the enemies properly spawning on each kind of car, repeat some of the cars, then put the engine at the front. Then I need to create the boss whose main weapon will be dynamite.
Note to self: Need to be able to chat in a game, and Escape to the main menu....and add Escape to the control instructions while I'm at it....and the game over sequence...
This hour made me realize how small the horses are compared to the player characters riding them; oh well. I got all the cars created, the particle engine smoke stack set up, and the boss partly done. I need to replace his machine gun with dynamite in the next hour. If that goes smoothly enough, maybe I'll have time in the next hour to play test the whole sequence.
Spent much of the hour getting the dynamite to look passable. Then I did a local playthrough: it's short and redundant, but I didn't get bored with it too quickly because of all the bullets flying around. I'm happy that I was able to get level 2 laid out and single-player tested so quickly! I had enough spare time to start designing about the in-game menu. I wanted to do some two-player testing, but the Photon Network is down. I may just have to get my own Photon Server up if their service is this unreliable!
The Photon Cloud service is working again (must be an intermittent problem); so I took advantage of the moment by fixing a bug with syncing enemies between players. I also got made it so you can choose to host a private game w/ password and dictate the number of game players. After that, I got the in-game menu working, and made a little progress getting chat messages working.
I got in-game chat working; lost a bit of time trying to figure out issues where keystrokes were getting gobbled up (you'd have to hit enter twice to chat). I also finished the game over sequence; not much to write about, it just reads "Game Over" and has a quit button. Master clients can restart the game for everyone. I started looking into the proper way to do network level loading...this may be easy or hard depending on if I just "get it." Plans for level 3 are looking very bleak now; I still need to find and add all the sound effects after all that!
This has been a mostly frustrating hour. The Photon network Cloud service is up and down like a spring, and in the rare seconds it was up, I was having problems getting the library to properly handle level transitions as it gave me other strange error messages. At the last minute I made some big changes that I hope will work when the service is back up.
I give up on the networking bit for a while...in fact I may not have the game done this weekend. The Photon network cloud is outright down again, and I still don't have the scene transitions working. I invested most of the hour on getting the player and a few non-player sound effects set up. This makes me very glad that I didn't do level 3 first.