Tuesday, March 23, 2010

Daily Developer: Day 68 - The New Game

Nothing gets the imagination going like the start of a new project.  Based on some of the accidental gameplay I discovered in my ToxicGrowth project, I started brainstorming for my new game that I am designating "Project Elasticity."

While there is a lot I don't know about how I want everything in this game to behave, I did take the time to pick a starting point.  I am going to use one type of gameplay to start with, with the expectation that there will be a variety of fun ways to play and styles to choose from.

I used Freemind to come up with some of my general ideas, then I selected some of the details and created a basic requirements document in Google Docs that only covers the one aspect of the game I am currently interested in.

My goal for tomorrow is to take the concepts outlined in my requirements document and try to solidify them a bit in a design document.  Since I am working on a small portion of a game that could be pretty big, it shouldn't take too long to come up with a basic design.  Though, I did notice as I was describing things in the requirements doc that there were several concepts that were much bigger than the simple sentences it took to describe them.

Duration: 01:07:56

Saturday, March 20, 2010

Daily Developer: Day 67 - The Return

Things have settled down enough that I am able to return to my daily routine.  My task today was to simply get re-acclimated with the game and the code itself. What I've determined is that I really don't think that game as it currently is has much potential for ever being fun.  So, instead of slogging along, trying to force it to be something that it will never be, I think I am going to retire it.  I might post the code somewhere, in case it is interesting to anyone, but I think it is time to move on to other games.

Working on this game has sparked some other ideas for other games.  I think my goal for the next couple days is going to be try to nail down the details of how I want my new game to perform.  I might actually *gasp* write out a quick little requirements document so that I have a guideline for what I am expecting.  At the very least, I anticipate that this will help me determine what makes a requirements document into something that is truly useful, something that I think I would be able to pull over into my job.

Duration: 00:15:33

Sunday, March 14, 2010

A Brief Hiatus

I have been taking a short break from my "Daily Developer" activity since I have had an offer accepted on a new house and am in the process of trying to get my current house "show worthy."  Once I have finished this, which I am hoping will be tonight or tomorrow, I should be able to return to my game development.

Tuesday, March 9, 2010

Daily Developer: Day 66

I added an upper limit to the number of growths that can be displayed at once.  This has highlighted that the issue seems to be that something isn't being cleaned up properly in the background, since even when it reaches a limit much lower than the 3000 I was seeing problems at, it eventually starts to lag like it had before.  I'll need to investigate further.

I also re-added the health system for the growths.  Now, when they are shot, they decrease in level until they hit zero and disappear.  However, I think the pool I created is causing troubles with this, since the growths stop spawning after enough are shot, since they are being pulled out of the pool with zero health.  This should be easy to fix.

There still might be something to this game, or maybe not.  However, I at least want to get the bugs worked out before I call it "done."  I have an idea that would use multiple avatars, but it could take advantage of all the work I've done already, so it makes sense to keep ironing out the issues.

Duration: 00:19:16

Monday, March 8, 2010

Daily Developer: Day 65

I received a response to my post from yesterday.  It suggested that I use a pool of enemies: instead of constantly creating new ones, when one is destroyed, put it into the pool and reuse it.  I gave it a shot, but was still seeing the issue.

 Something else he asked was how many items I had on the screen at once.  I guessed about 100, but after the pooling didn't help, I decided to print the growth count to the screen. 

What I had overlooked was just how quickly spawning four new growths for every existing growth would become unwieldy.  Instead of being an issue at about 100, the slow down was starting at about 3000.  I don't think that there will ever be a need to have that many items in the real game, so I think it is a non-issue.

Next on the list of things to look at is to re-enable the collision of the growths with the projectiles and then making sure that the growths revert to previous stages first instead of simply being destroyed outright.

Duration: 00:24:31

Sunday, March 7, 2010

Daily Developer: Day 64

Today was a day of exploration.  I decided that the most reasonable way to approach resolving the game freeze issue I am having is to see what others have done to avoid it.  I looked through some of the posts at the CodePlex forums for farseer and have a couple of ideas, but there is nothing definitive.  So, I registered and wrote a post asking for assistance.  Hopefully, someone who has already solved this problem will be able to guess at what is going on.

Duration: 00:21:51

Saturday, March 6, 2010

Daily Developer: Day 63

I added the check for the boundary back for the projectiles, destroying them if they cross it. I duplicated this functionality for the growths as well. I also remove the excess object from the physics engine, so it seems that things are being properly destroyed now.

I adjusted the collision detection for the growths to only cause a destruction if they bump something other than another growth. This needs to be updated further to properly use the health functionality instead of immediately destroying the growths. Also, the projectiles need to get similar collision detection, since they are not being destroyed until they reach the edge of the screen.

With too many growths on the screen at once, the game bogs down and crashes. I'll need to address this. Possibly, it will be taken care of when I add the death sequence for the player.

Duration: 00:33:48

Friday, March 5, 2010

Daily Developer: Day 62

I removed the old collision detection manager from the project and removed all references in the code. Added a quick test collision detection routine and it looks like it is in the right spot. I did notice that it doesn't complete destroy the objects with the calls I make. I think I've forgotten to remove both objects associated with each displayed object from the physics engine, instead only removing one.

Also, I noticed some odd behavior in a couple of places and made some notes in the code. I also found an issue where it crashes when it tries to create a new growth in a location that one had already been created. The way it is being stored was because I was doing all my own collision detections, so I should be able to simplify that area.

Duration: 00:31:31

Thursday, March 4, 2010

Daily Developer: Day 61

I solved the problem of the projectiles colliding with the shooter when fired by assigning a different CollisionCategory to each. Then, I set the growths to collide with everything and the shooter and projectiles to only collide with the growths. So, now that works nicely.

It took a bit longer than I expected, so I will pull out the old collision code and create the new collision code tomorrow. I also need to either create a barrier around the edge of the board, or to destroy anything that goes outside its bounds.

Duration: 00:42:46

Wednesday, March 3, 2010

Daily Developer: Day 60

Following the pattern I already established, I reworked the shooter to use the Farseer physics engine. Since I have all the objects sharing the same base, and I've already re-factored it to do most of the physics stuff, it was mostly just a matter of making sure the old things weren't being called any longer and that the new properties were being set correctly.

I still need to disable collision detection, since all the objects in the game correctly collide with one another. Because the projectiles collide with the shooter when fired, sending the shooter flying about wildly, I'll either need to recalculate where the projectiles are generated (so that they no longer originate from the center of the shooter), or just create other collision groups and make is so that the group the shooter is in doesn't collide with the group the projectiles are in. I am leaning toward the second, since it should also help with processor time.

Duration: 00:19:46

Tuesday, March 2, 2010

Daily Developer: Day 59

I progressed at moving over to using Farseer for all the game objects. I re-factored the Growth object, moving all the Farseer specific stuff into the base object that the projectiles also share. After a bit of debugging, I was able to get the projectile created and moving properly.

Next steps include porting the player controlled avatar to use Farseer. I need to disable and discard the old collision detection routines and then use the detection that Farseer is already doing. After that, I need to tweak some settings, since I notice significant slowdowns with a large number of items. Though, that may be reduced once the old collision routine is disabled.

Duration 1:00:00

Monday, March 1, 2010

Daily Developer: Day 58

It looks like the experimentation with the sample project I created paid off. I was able to get the growths to move and collide with one another. The avatar and the projectiles now need to be moved to use the physics engine. Also, the collision detection I created needs to be disabled and reworked to use the engine. This shouldn't be too tricky, since it handles most of the work and I just need to trigger on particular collisions.

I also noticed that if a large number of the growths form, it drastically lags the game. I need to put a check in to destroy anything that goes off screen, but I think that there might be some other optimizations that I'll need to look at, too.

Duration: 00:26:04