Some thoughts on Zynga

I have been hearing a lot about Zynga in the news lately. While I am not a big fan of the company, who to me seem to be far more interested in extracting money from their players than in actually creating compelling games, I actually have taken their side on some of the issues. Yes, they may be an evil company that clones other peoples game, copyright does not protect ideas just the implementation of the ideas. I can make a clone of Asteroids if I want to as long as my version of the game has some new and unique elements to it. People may complain about this, but in reality it is far easier to sell a game that is 10% unique and 90% similar to other games people have played than it is to create a game that is 90% unique. Far too often people want a new game that is "just like the game I just finished except different".

When I heard that EA was suing Zynga over copyright infringement I was ready to take Zynga's side  but when researching the EA versus Zynga lawsuit  I came across the following article: http://dlr-law.com/3/post/2012/08/zynga-slammed-again.html . It seems that there actually may be something to EA's lawsuit. When you hire people away from a company in order to produce a game that is similar to the one that they are producing, you are only asking for trouble.

There are actually a few game ideas that I have abandoned due to people I have done consulting work for planning a similar game. My thoughts are that even though my version of the game may be 100% mine, it would be easy for the company to claim otherwise and they tend to have far more resources than I have when it comes to lawyers. It is best to avoid potential legal entanglements, especially since I happen to be the type of person who would not back down if it came to legal action and so would end up having to spend way too much money on my legal defence.

Perhaps one of the reasons I am not as successful as companies like Zynga isn't my total and complete lack of marketing skill, but the fact that I actually have ethics. To me, making money isn't the important thing. I created Blazing Games because I wanted to create games. I think that far too many of the successful game companies are successful for the wrong reasons. Worse, these companies have a tendency to buy the companies who exist to make great games. Bioware is just the first example to come to my mind.

The sad reality is, despite my claims to be ethical, if Zynga came to me and offered to buy me out I would jump on the opportunity if there were enough zeros in front of the first non-zero digit. I would make up excuses such as "They will properly market my games" and "It would be nice to actually have a budget." Yes, those excuses would actually be true, but the reality is that everybody has their price. In my case that price is probably not as high as I would like to believe, especially in this economy.

Alien Chase road generation

My Twelve Months of Doomsday Alien Chase game was released last week on Blazing Games so this week I am going to briefly go over road generation. This is not the first time I have created a randomly generated map, but is the first time that I have created a car driving game.

I wanted a road that was randomly generated to give the game a bit more replay-ability. More important, the size of the map would be huge and I really didn't want to create a really large road map by hand. Creating a map by hand has the advantage of giving the designer a lot more control over the difficulty of the game and often can result in better looking maps, but if done properly you can get fairly good results from a randomly generated map.

The first task, which is necessary for both random and hand-mad maps, is to come up with the tiles that the map is made up of. As I didn't want an obviously tiled look to the road and grass, I decided that there would be a number of tiles for each piece of road which would be textured slightly differently. I opted for 10 tiles for each root type of tile. The root tiles in the game were grass, trees, curb, road, dashed road, lined road, dividers (left, centered, right). In addition to this, I realized that transitions for increasing or decreasing the road size and the divide size would also be needed.

The road is then broken into sections. To keep the generator more manageable, the sections only allow a single change to the road. The four changes are increases in lanes, decreases in lanes, increasing the divide, and decreasing the divide. If any transition is impossible, the road remains the same as it was for that section. Divides consider a double-line and a concrete separator different types of divides.

While in practice this system worked okay, I found that additional transition tiles would have been nice to have, such as a road curving as the divide is increased. I did not have enough time to add this extra transition, but may do so when this game is revisited in the future.

Making Alien Espionage

One of the nice things about creating small projects is that it gives you a chance to play around with new techniques and try out new things. This is especially the case when the game is a type of game that you normally don't create.  For this episode I played around with a different way of handling animation.  I also experimented with vehicle systems. Finally, I tried a new way of spawning enemies.

The animation subsystem for this game is table driven with canned clips. Normally I use animations centered around the current coordinates of the object being animated.  This has the advantage that it is easy to move the object as you can simply use linear interpolation.  With the canned animation the motion is part of the animation meaning that the  animation plays through with the coordinates not changing until after the animation has completed.

Making the animation system much more complicated was the number of different sequences. To handle all the different transitions necessary without needing a huge number of animations, only the core animation segments are created. The transitions then stored as a table of sequences. Each segment in the transition then gets played in sequence. This approach works great for more complex character animations.

The elevators were an interesting challenge. My first thought on handling the elevators was to treat them as platforms. This lack of control simply did not feel right so I opted instead to treat the elevators as vehicles. Players "enter" the elevator by jumping or crouching while standing in front of the elevator. The player then exits the elevator by moving left or right. While inside the elevator jumping and crouching become the up/down controls.

Because the main theme of the game is about moving through a building infested with aliens, having aliens pop out of the doors seemed to be a really good way of handling the spawning of aliens. Each door has a set number of aliens (based on the level) that it can spawn. To prevent too many aliens from showing up, there is a per-floor limit (again based on level).  Finally, I decided to make the spawning of aliens time based.

If I had more time, I would have created a number of towers. I would also consider making the player retrieve a number of cases by entering multiple doors and then return to the first floor to complete a level. If I ever revisit this game, I may make these enhancements.

Thoughts on Coffee Quest 5/6

Working on Coffee Quest FPS has really got me thinking about giving my cursed Coffee Quest 5 project another go. I suppose cursed is really not quite the right word, but I have started on CQ5 a number of times in the past only to have the project go to the wayside as other things came along to eat my time. Needless to say, paying work always takes precedence over my game development hobby. As much as I would like to be able to turn my hobby into something that will pay the bills, I lack the proper marketing skills and tend to work on a large number of smaller projects instead of one really large project. I am trying to remedy the later problem but my twelve months of doomsday project just was something I had to do so my plans were derailed (and the games took a lot longer to code than I anticipated). Still, Coffee Quest 6 is a game that could work on something like the iPad and Nexus 7 and it is large enough of a game that I could justify charging money for.

For those who are unfamiliar with my Coffee Quest series, it started out as a Java game written for browsers. I drew up a roadmap of games that would lead to the ultimate role-playing game. This was broken into 9 games with the last 5 games being broken into a large number of episodes. The first game was simply getting a 3D maze working in Java (which at the time was a new language to me). Next came monsters, then multiple-levels and proper inventory. Coffee Quest 4 was the first true RPG featuring magic and more of a story.

Coffee Quest 5 was going to be a multi-part story that added NPCs and Stores to the game. Coffee Quest 6 was going to be a huge continent spanning epic with the player in control of a party of characters. CQ7 through 9 was more  of a 3 part story arch with no planned elements other than the vague idea of taking advantage of all the cool technologies that would appear when I finally got around to creating the game. Needless to say, the browser technology kind of stagnated until recently and Java has been replaced with JavaScript. This is something I could never have imagined happening.

I still have a few months of work to do before I can even consider taking another stab at a large-scale game. Coffee Quest is still in my heart so it is a project I would like to do but I suspect as soon as I get into the project something else will come along. Hopefully a high-paying project that will occupy far too much of my time. Still, it might be worth another shot and perhaps this time the games will see the light of day. As someone who isn't that big of a FPS fan, it would be rather surprising if a FPS is the catalyst that finally resulted in CQ6.

7DFPS Postmortem

This week's blog post was delayed by a couple of days as I was participating in the 7 Day First Person Shooter challenge. The idea of the challenge was to create a FPS in a week. My entry was Coffee Quest FPS, which is kind of fun but was not as polished as I would like. I will be polishing the game up a bit more and releasing it on Blazing Games. This week I would like to do a mini postmortem. The game is roughly 2K lines of JavaScript (including comments, spacing, and data) with roughly 120 art assets spread across 8 sprite sheets.

What Went Wrong

The biggest issue for me was the time. This was made worse when most of my Sunday ended up shot and by the fact that I kept up my exercise regime. The problem with short deadlines is that they simply go by far quicker than you think they will. At the end of the challenge I had a finished game but not a polished game. My list of things I want to do for the Blazing Games release of the game is 0xF items long so at least a few more days would have been necessary to meet my minimum goals for the game. Notice that I said minimum goals? In fact the original idea I had in my head was a lot more than I knew that I could realistically implement so I focused on just having a single level competed by the deadline.

The second biggest issue, which may have largely caused the first issue, was developing the game and game engine at the same time. For me, the whole idea of developing a game in a week is the whole game. Just creating content for an existing engine makes the challenge more of a level design or modding challenge. The honest truth is that we have reached the point in game development where games are built on top of existing engines. This saves a lot of development time, at least half of the week in my case. If I ever do another challenge like this, I would write my own engine well before the challenge began and build the game with the existing engine. This would allow a vast amount more time to be put towards the actual game. Still, there is nothing like the feeling you get when you have created a fairly complex game from scratch in a week and if I had used an existing engine (mine or especially a third party engine) I simply would not have been as satisfied even if the resulting game was ten times better. In other words, I am glad I chose to write my own engine during the challenge but it was still the wrong decision.


What Went Right

While my new JavaScript ray casting engine has a ways to go before it is "finished", it is a very flexible engine. What I was able to implement is only a subset of what the engine is capable of. Earlier ray casters that I developed had fixed texture sizes. Part of this was designed to speed up the rendering and insure that integers were used for calculations. Now floating point is almost as fast as integer math and JavaScript uses floating point for its numbers anyway so allowing for variable texture sizes was easy. There was a bit more work getting the rendering to work, but I found myself using 256x256 textures for the walls but a variety of sprite sizes (64x64, 128x128 and 256x256 though power of 2 isn't even a requirement anymore). This actually made implementing the game easier. It will make future games that use enhanced versions of this engine easier to write.

The second thing that worked well was building on known IP. Using a known universe makes a lot of the design decisions very straight-forward. While there are often restrictions when using existing IP, in this case it is my own universe so I could do whatever I wanted with it. When your time is limited, working out background information and trying to figure out what works with the universe you are creating is a dangerous time sink. Granted, if I would have used an existing game engine instead of creating my own there would have been plenty of extra time to create a new universe. I suppose that is another reason why my decision to create my own engine during the challenge was a wrong decision. More to the point, at least in this case, it was a while since I played around in the Coffee Quest universe and really enjoyed myself.


The future

As I convert my older Java and Flash games to HTML5, this engine will be utilized in porting all the games that use their own ray casters or similar technology. What I am ultimately planning on doing with this engine is reworking it to use WebGL for the rendering, but falling back to ray casting for browsers that do not support WebGL. This way I will get great performance yet sill have my games work on the vast majority of browsers. Before I can do that, I have to actually learn WebGL so it might be a while. Coffee Quest FPS will have at least a couple of updates so eventually you will see what I originally was planning for this game.

Twelve Months of Doomsday episode 5: Asteroid Attack

Episode 5 of my TMoD series has been released on Blazing Games so this fortnight I will discuss some of the design decisions that went into the development of this game. While this game is clearly inspired by the classic arcade game Asteroids, it is much more inspired by one of my favourite movies: The Empire Strikes Back. While Asteroids had aliens in it, they were more of an afterthought. I wanted my game to focus on battling aliens not on shooting asteroids. To do this, I made the asteroid field much bigger so the player would actually have to navigate through it and I made the rocks much harder to destroy.

The big problem with making asteroids hard to destroy is the basic fact that navigating using momentum based movement like the game uses makes rapid dodging difficult. To address this problem, I decided that giving lasers some form of impact value would be a good way of solving this problem. Shooting an asteroid will then either alter the course of the asteroid or cause it to break apart.

One of the great aspects of being a game developer/programmer is that you control the laws of physics. I based the amount of impact that a laser has based on the radius of the asteroid instead of the mass of the asteroid so lasers will have a much greater effect on larger asteroids than they should. This decision was made largely based on intangible factor: the feel of the game. This is actually one big advantage of doing small games. You are able to finish the game while the game is still enjoyable so playing the game yourself actually gives you meaningful feedback. When you are spending years working on a game, unless the game is one of those rare exceptions, you will be sick of the game as you reach later stages of it's development.

Originally the game was going to give the player a limited number of lives and the player would not re-appear until the coast was clear. That really didn't fit well with the story, so I decided that the player would only have a single life but would have a shield that would flash when they were hit with a limited amount of shield. This also allowed me to make it less damaging to bounce off an asteroid than to be hit by an alien laser.

Aliens were a lot more dangerous in earlier builds of the game as they would home in on the player and would start shooting at a fair distance away from the player. This difficulty was reduced by making the aliens wander randomly while trying to keep away from asteroids and not shooting at the player until they were fairly close to the player.

While I am sure there are a lot of people who disagree with me, I was quite happy with the way the game turned out.

Flash Professional CS6

I was really considering staying with CS5.5 unless there was a compelling reason to upgrade. Flash CS6 really didn't provide that reason, but as the upgrade price for CS6 for CS5.5 owners was half the price of the normal upgrade price, it was pretty compelling. When I found out that the Web Premium package was being combined with Design Premium, it would mean that a program that I wanted but couldn't justify was now part of my upgrade. InDesign is a desktop publishing application. With all the additional features in the other apps in the suite, the upgrade became a no-brainer.

If I only had Flash, not a suite, I doubt even the reduced price would have been enough to justify upgrading. I hope that I am wrong, but I really get the feeling that Adobe is abandoning Flash. Still, it is a tool I see myself using for many years to come. Perhaps not as a game development platform, but definitely as a tool for creating animations for the games. With Air packagers and Stage3D, it is possible that Flash will remain a platform for game development. As I have the tools, I have decided that I will play around with the starling framework and possibly try some low-level stage 3D work.

Still, for web development, the move to HTML5 is clear. Thankfully, Flash CS6 provides some tools for aiding in this migration. A few weeks ago I looked at a tool for creating image strips. This functionality is now built right into Flash. Likewise, there is a plugin for converting animations over to the CreateJS suite (which EaselJS is part of). While it is a great feature, it does not convert the ActionScript into JavaScript. Had this capability been in CS6, Flash professional would have instantly become the best tool for HTML5 development. ActionScript is a far nicer language to work with than JavaScript so the ability to write in ActionScript and compile to JavaScript would be well worth the price of Flash Professional. Yet another case of Adobe being blind to what they already have.

The thing is, both ActionScript and JavaScript are derived from the ECMAScript standard. ActionScript just happened to be based on a specification that was abandoned due to politics and infighting. Personally I think JavaScript would have been a much better language for web development had ECMAScript 4 passed. Since the underlying language is the same the version would have been backwards compatible. While I understand that some people think JavaScript should be easier, as the web moves towards JavaScript even larger programs will be created in that mess of a language so thoughts of dealing with large scale programs should be at the forefront as that is what the web ultimately needs.

In fact, the languages are so close that I think a quick porting tool could easily be developed so as a side project for this development blog, in future weeks when I don't have other things to discuss, I will look into the issues of writing such a tool. Even though I don't want to add yet another project to my overflowing plate, I just might develop such a tool as part of this blog. I know in the past I had looked for such a tool and while some projects existed they did not work the way I needed. Perhaps it is time for another look.