Writing

This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Top 10 Reasons to Teach Kids Programming

Here are my top ten reasons.  My wife says I should have added discipline to this list as well as the ability to complete, see something through.  What are yours?   

1.  You like to spend time with your kids.
2.  Your kids like to spend time with you.
3.  Kids need trade skills to make them employable.   
4.  Math becomes useful, less abstract.
5.  It takes 10+ years to master something.  Start early.
6.  Creating things is very cool.
7.  You will learn things, about yourself, your kids, and coding.
8.  It is way better than TV or Netflix.
9.  You might make money in the first year.
10.  Games are fun.

Flash versus Java:

Market:


After making two games with Java, I realized that the mass web delivery mechanism for Java is almost  zilch.  This was a classic case of the cart before the horse for me, but I learned a lot programming with Java.  There are few game portals out there that host Java only.  If you have a very popular game, you can get it up on many of the sites, but you are fighting an uphill battle.  Many great games do make it, but usually through less refined channels.

Yes, I have some regrets about not starting with ActionScript.  I have a business plan from 10 years ago that did all Flash games but we went different directions.  First C++, then Java.  Java did lead to a ports to the Android Mobile platform but that is also a very hard market, requiring nearly infinite updates to keep your game in front of your customers.

Is Flash going to make me rich?  No.  I doubt at this point that I could ever make a living from it.   The advertising revenue is about the same from YouTube.  My current research shows that people make between $2 and $3 per 1,000 views.   That means with a 1,000,000 views, a game will only net $2,000 if it is not monetized in some other way.  To make financial matters worse,very few many games reach a million views.

Code:

I'm not finding any significant difference between ActionScript 3 and Java.  For coding games, there are actually many times the amount the reference materials and much better game libraries like FlashPunk and Flixel out there for the 2D games.  ActionScript also has the up and coming 3D engine, Stage3D, that will get more traction than the equal quality Ardor3D for Java.

The two differences I have found that I do miss:  Enum and Overloading.   ActionScript does support optional arguments which takes care of the overloading, but I do miss the Enums.




Dot n Munch: Postmortem

Dot n Munch

My wife, Miho, was pretty busy with kid's school work, taxes and what not, so I thought that I would make a game that was super easy to tied me over before I got help with the art work. If the wife is happy, I'm happy.

I decided to make what I thought would be a simple game. It was a timed, "fit the piece in a hole" type of game, giving me hopes of advancing my skills and increasing my reusable code. In particular, I wanted to develop a level manager, something that would display unique splash screens, then load the next level, then display a different fail or try again screen.


The Good:

1. Improved my classes.
2. Improved my state machine.


The Bad:

1. Time estimate was off.
2. Did not reuse my sprite class for collision detection.
3. Not that excited about the game.
4. Adding complexities did not work out.


The Good:


1. Improved my classes.

This is pretty minor actually. I cleaned up my timer and frame rate classes. My favorite class by far in this whole game is my BubbleChat class. Basically it reads the size of the text and puts a bubble around it with a pointer to the sprite who is talking. It can contain up to four lines of any length. I can change the color and what not.

2. Improved my state machine.

I was really hoping for a nice segue to my next game, Pixel Rescue. I wanted to become comfortable with loading levels and scripting them to what I wanted to do. This was a semi-success.

I set up a very nice scripting for the talking dot. It is a simple state progression. Probably along the lines of how I would set up some scripting. State is progressed when timer is done.

private void draw1 (Graphics2D g2d){

    // move over to the center
    if (state == 1){
        x = player.getX() + 4;
        if (x > 388){
            x = 388;
            ++state;
            chat = new BubbleChat(x,y, Color.WHITE, "Hi there!", "Please don't let me get crushed.");
            timer = new Timer(messageDelay);

        }
        y = player.getY();


        player.set(x, y);
    }

    // say hello for timed period
    if (state == 2){
        chat.draw(g2d);
        if (timer.done()){
            ++state;
            chat = new BubbleChat(x,y, Color.white, "Use your arrow keys to", "move me to a safe spot.");
            timer = new Timer(messageDelay);
        }

    }

    if (state == 3){
        chat.draw(g2d);
        if (timer.done()){
            ++state;
            chat = new BubbleChat(x, y, Color.white, "Good luck!");
            timer = new Timer(messageDelay);
        }
    }

I did not get the level loader quite to where I wanted. It progresses but not as cleanly as I would like.

The Bad:


1. Time estimate was off.

Game number two in java for me, and I still can't estimate how long something will take. I estimated a week and again I'm at two weeks with many more hours than I expected. On the inside I even told myself this should take 20 hours. The two biggest delays came from collision detection issue and motivation. There was also a lot of sitting and staring at the game, thinking to myself "how can I make this better?"


2. Did not reuse my sprite class for collision detection.

Since I was not going to rely on Miho's artwork this time, I used Java2D to create my polygons. I went too simple and ran into major problems. The bottom line is testing for an intersection of two polygons might work for hitting something but if you need to bounce back, it doesn't work well because it doesn't provide directional information. It much better to use the sprite approach of testing edges. If the left edge has passed the right edge, then move the sprite right. This works.

I spent a lot of time trying to guess at the direction and counter directions. Then the keyboard input created a bit of lag time so I could never ever get it working perfectly. I went back to the sprite style of checking edges and that fixed nearly everything. There is still a small problem when two sides are over at the same time but it doesn't seem to effect game play much. I'll have to see if someone complains during the feedback phase.

Not using my sprite class from Subby and the Fishes seemed to be dumb decision as I had to rewrite and troubleshoot a bunch of code.


3. Not that excited about the game.

The game is okay. I've tried to make it funny and as addicting as possible within a very confined design space. However, I'm just not that into it. Working on the collision issues for over a week was really demotivating for me. I was thinking "I don't like this job" when I should have been thinking "this will be so cool when I'm done." Procrastination and avoidance added several days to the development time.

The funny thing about it is that I could have sworn I had spent four weeks working on the game but when I look at my completion date for Subby and the Fishes, this one was only two--but sure felt like four.


4. Adding complexities did not work out.

Firstly, there were just general design ideas, not really thought out, so no reason to implement things like slippery movement or bouncing. The game is more about finding the spot rather than motor skills.

Second, I am happy to be done.

Best Java Games

Best Java Games

I'm a little bit cynical about developing in Java. It is such a nice language, but I find myself having hard time finding games that are developed in it. With flash, I can find 2,500 games in an instant. With Java it took me several hours to find 300 or so. Not sure which comes first here, the chicken or the egg.

Here is a listing of the best and most successful Java games I've found.

Subby and the Fishes
RuneScape
Bang Howdy
Milpa
Alien Flux
Puzzle Pirates
Tribal Trouble
goSupermodel
Lux
Coke and Code Games
Erik v Erik is my favorite here
Arcade Pod has bunch
Java Game Tome has even more
Dan Ball Very cool physics


Others:

Call of Juarez
Chrome
Titan Attacks
Star Wars Galaxies
Kingdom of Wars
Law and Order II
Ultratron
Roboforge
IL-2 Sturmovik
Galactic Village
Wurm Online.

Subby and the Fishes: Postmortem

So how did the development "Subby and the Fishes" go. My goal was to write a simple applet game that could be sold to advertising based sites. Lets review 10 things that went right and 10 things that went wrong on the development.

The Good:

  1. Starting with a small project.
  2. Choosing Java2D over 3D.
  3. Rewriting to make code more elegant
  4. Having other people play it.


The Bad:

  1. Estimate to completion was completely off.
  2. No refined sprite class.
  3. No refined sprite manager class.
  4. Display class was not abstracted

The Good in detail:


1. Starting with a small project.



Starting with a small project is just about the best thing a programmer can do. We all want to make an even better World of Warcraft but this isn't the way to go. First progress is immediate. It is quite motivating to see the game become better and better by the hour. I found the how to write an RPG in 40 hours quite inspiring.

Second, it is much easier to rewrite your code. If you did something wrong with the structure, you only need to refactor a few classes versus thirty or more. I think rewriting for elegance is key. With a big project, there is just no time to rewrite with huge pieces of code. My first rewrite and reorg took almost 8 hours on a very simple game. I hate to think how much it would have taken on a larger one.

Third, feature creep is limited. For example, my sprite class resizes, animates, and alpha blends. It does not flip, rotate, or force pixel colors. At some point I will want to add these features but they are not needed for this game. Each would probably take me hours to complete if I implemented properly with speed tests.

Fourth, there is little to no artwork delay. Art takes a long time to make and can be expensive. It can be quite quickly developed. In my case, my wife, Miho, can knock out most of the sprites in a weekend.

2. Choosing Java2D over 3D.

This could probably be retitled to "Go with what you know." In my case, I've spent a month playing with Java2D. It is familiar, and there are a ton of excellent tutorials on the subject. JOGL looks extremely attractive and will probably be the only way to go in the long run for developing desktop applications. However when I sat down to try to learn it, I found myself wasting valuable time. It was going to take me a month to become quite comfortable at least.

I also felt like I had more important things to learn like object orientated structures, sound, map management, user input. Kevin Glass has a nice tutorial that abstracts the display of the game from the game itself. Flip a switch and run JOGL, Java2D or LWGL. I'm still deciding if I should go this far perhaps as a final rewrite.

3. Rewriting to make code more elegant

I can't say enough about this. Since it is a small game, there is time to go back and make it right. For me, my first rewrite was to make reusable sprite and sprite manager classes. Maybe this is just good object oriented design but it was a first for me and I love the way it turned out. I can now add sprites in a matter of minutes. My code is much easier to read.

A spin off of the sprite class was to create a resource manager for the art work. It was simple hash map that loads everything into memory. But it sets up my sprite manager for timely reads so I don't have to wait for hard drive loading. It also sets things up for later if I ever need to manage video or PC memory with a large game.


4. Having other people play it.

Feedback is invaluable, no matter how hard it is to listen. About 10 people played it on JGO, finding bugs and making excellent suggestions with regards to speed and difficulty. What was also quite important was that I was able to pare down my TODO list just to get in what players wanted.



The Bad in detail:


1. Estimate to completion was completely off.


My original estimate was one week. Total time was four weeks, working part-time, nights and weekends. Rewriting the code to make in organized well took a week and half alone but improved my programming skills. The sound was a bit of a nightmare. I originally tried to add some music but the EasyOgg and another free library have major bugs in them, making them scratchy and bugging on different operating systems.

Here is the list of things that took longer than I thought.

Rewriting the code 1.5 weeks
Reorganizing the code 2 hours.
Sound and music 1 week, OGG never worked.
Compiling for Java 1.5 1 hour
Art mistakes 2 hours

2. No refined sprite class.

I spent the most time working out a nice sprite class. This took a long time to get it perfect. The nice thing though is that is completely reusable. I loved the fact I can add sprites in minutes.

3. No refined sprite manager class.


The overall structure of the code could still probably be improved. There are controllers and actors. Then there is a controller for the controllers. The first time going through this makes it a little confusing as to what controls what.

4. Display class was not abstracted

This is more of an I wish I would have thing. I wish that my display class was setup perfectly for a JOGL or LWJGL conversion. I'm very curious to see how much more speed I would have with these in place. 33 FPS cap just doesn't seem that good. However, no one that played it really went lower.

Drawing Sprite Speed Test

In an attempt to make my code a bit more elegant, robust, and fast, I've started review my newly created Sprite class in detail. I included percentage resizing and alpha blending. I chose an easy way to alpha blend but had two choices on how to resize my images. I started to become curious:

What is the best way to draw my sprites in Java 2D?

I turned off my sleep timer in the game loop and then drew a 59x448 pixel index image on to my canvas. Note I tried the same image as RGB and had scary slow downs. Making sure your art work is all indexed will be your greatest speed boost by far.

The results where interesting.

Resizing causes a much greater hit than alpha blending.
drawImage(img, destination, source) was slightly faster than drawImage(img, destination, size)

Here are the details in milliseconds over 10 seconds.

// As fast a you can get. Used whenever the others are not required.
g2d.drawImage(buffImg, 40, 40, null);

Result: 1381.4

1375
1390
1378
1378
1386


// Slowest draw. Half size, setting width from 448 to 224, and height from 59 to 30.
g2d.drawImage(buffImg, 40, 40, 224, 30, null);

Result: 1313.6

1292
1374
1298
1290
1314

Result second test: 1305.4
1310
1298
1307
1302
1310

// Oddly enough faster than the above method.  This is what I use.
       g2d.drawImage(buffImg,
                40, 40, 40+224, 40+30,   // destination, scalable
                0, 0, 448, 59,  //source on sprite
                null);

Results: 1309.8
1303
1307
1301
1311
1327

Results: 1313
1320
1286
1319
1339
1301

// Sets alpha blending to 50 percent. Not as bad as expeced but changing the composite 100 times would be terrible.
g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 0.5f));
g2d.drawImage(buffImg, 40, 40, null);
g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 1.0f));

Results: 1366.2
1360
1376
1364
1368
1363

Finish Damin it!

While looking at books at Amazon, I found an forum discussion that posed the question, "Can a self taught programmer get a job?" The answer was a resounding yes but with a few caveats. Note I'm not really interested in a job; I'm interested in making games which requires being a good programmer. So the discussion was pertinent to my goal and steps that I should take.

The first thing that was rejected was the idea of certifications, most saying they are waste. (My guess is that this is only partially true because you just never know if one word on your resume makes a difference or not to the person screening.)

There also seemed to be a couple of tiers of programming complexity. Many programmers posted that they never used linked lists or hash tables, mostly focusing on the user interface and web side of things.

Others seemed to have quite challenging, problem solving jobs. Programmers seem to come from many different backgrounds, and their performance, and pay, has little to do with their college degree.

What was more relevant to this blog is that several coders said the key to getting yourself trained came in three parts.

1. Finish projects.
2. Learn everything you can.
3. Make your code elegant.


I think there is another important piece to that was stated by Peter Norvig who discusses the foolishness of learning a programming langue in 21 days. He points out that it takes time to master something. So lets add this as the four key to learning programming.

4. Stick with it.

With these four items in mind, let me go over them as they pertain to me. I started programming in Java in mid January of 2009.

1. Finish projects.

This really was a very nice wake up call for me. Taking a hard look at the files on my hard drive and the date, I'm was sitting at about three months since I started learning Java with one semi- playable game and quarter of a playable game. Not good. No finished projects. With this is mind I put away my space game and decided to make something simpler that could be finished. Now it took me over a day trying to figure out what that something was but it was well worth it.

2. Learn everything you can.

As for the learning side of things, I've actually done pretty well. My speed has increased. I've learned more than I ever imagined. Programming is not for the feint of heart. Game programming is only for the brave because it is actually very complex. Currently I'm dreading learning sound for my games. It looked like at one time there was a very nice interface for it but has since been depricated.

But on the positive side of things, not only have I memorized a ton of java syntax, object oriented programming is starting to make sense to me. Abstracting class and making re-usable code is becoming fun. I've become comfortable with Java 2D and have a fair understanding of swing.

When I think about the sound api for my game, in some ways this conflicts with number one. I really don't want to learn how to code sound API. It is one of those things that seems so simple to use. Play this sound once with this animation, or loop some background mood music. Of course you can set up a mixer to play multiple sounds at once with time delays for background moods but really it is just play and loop. But it is quite difficult to build an Ogg streamer. The wav player seems reasonable but even then there are many reports of crackling as well as mix problems. There are also threading issues. So my dilemna is whether or not to hire someone to write the code for me, thus completing my first goal of finish damn it. But at the same time it defeats my goal of learning everything I can.


3. Make your code elegant.

What about elegance? I wasn't quite there. As the blog stated most beginner coders probably don't even know what elegance means in terms of code. I think this probably a pretty fair statement; however I do know that in writing elegance can be gained through a lot of hard work and rewriting. The same seems to be true of coding.

With this in mind, I spent an entire week reworking the Subby code just to make it feel better, make flexible, organized. I looked for patterns in my code and tried to turn those into abstractions for reuse.

The greatest sucess I had in this area was my sprite and sprite manager classes. They were readable, documented, extensible. I had a nice little frame work to add different sprites in a manner of minutes.

4. Stick with it.

This is by far my worst issue. Typically I can dive into something for a few months, then get distracted by something new. Oh, look how cool is that thing over there! This time though I've promised myself to stick with it for a year.

I did have a three month lull but I just took a week and half off then came right back to it, quite refreshed.