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.
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.
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.
