First, happy Easter everyone who celebrates it. While I was originally going to post a sneak preview of my Sudoku Generator (yes, it is in a functional state though as usual I am behind in writing the articles related to the development), the Easter bug bit me and I simply had to quickly make an Easter game. This was actually a fairly quick development as I took my Santa's Search game and my Evil Eggs games and simply merged the two. As I am the copyright holder for both games, I have no need to release the source code though plan to in the future.
The random egg generator from Evil Eggs was used to replace reindeer but this actually proved to be more difficult than originally anticipated. The difficulty came from having the inventory eggs match the pattern picked up. This resulted in a clone feature added to the egg generator. When designing the map, I opted for a much smaller 16x16 map as I felt the 32x32 map made the game play too long.
Still it is amazing how quick I was able to get this game finished despite unexpected problems. I think a lot of the speed has to do with familiarness with the source code.
Sunday, April 24, 2011
Sunday, April 17, 2011
DDTe2 hours 1 to 3 Sudoku Model Making
With the first episode focusing on the player, and barely making the self-imposed time limit, I was really worried when I started working on this episode. The player was fairly straight-forward with the implementation, I started this project out with no idea whatsoever how I was going to actually implement this. To figure out how to write a generator, I figured the best way to start would be to simply create a puzzle by hand. By doing this, I would get a hand on what is required. While often techniques in the real world are hard to translate into software, it often can result in at least a good plan for attacking the problems. In fact, I found that sudoku puzzle creation, or at least the method I ended up using to create the puzzle, was the opposite case. It would be much easier for the computer to use my technique then it was for me to.
While generating the puzzle, I quickly realized that the process consisted of two different tasks. First is the creation of the solution, which will be the tricky part. Second is uncovering parts of the puzzle in such a way to make the puzzle solvable yet have very few (ideally one) potential solutions. The second task to me seemed to be the easiest to implement so I decided to implement my generator in reverse, starting by implementing the hider followed by generating unique solutions.
Both tasks require that I have some type of model. The sudoku model should already exist as it should have been part of the player. To save time, however, I combined the model with the controller. This is not something that should be done as the time I saved by doing this was minimal (though as it turns out necessary) while the gain of having a separate and reusable model would have been nice at this point. Still, this isn’t that much work to implement and what I came out with is slightly different than I would have done in the first project.
The model class consists of an array of values and an array of locked tiles. Any tile can be set, with the set function setting the value of the tile to the mod 10 of the passed number. If the passed number is greater than 10 the lock value is set. This is done to make it easier to pass grid data but is not necessarily a user friendly way of dealing with this problem.
A convenience function for determining which group a tile belongs to based on the row and column was added. The row, column and group counting functions have more appropriate names this time as they are now countValueInX with X being row, col, or group. These functions simply count the occurrences of the indicated value returning the count. To finish off the class, clear and setData methods were added.
The next step then is to implement the hiding of tiles.
While generating the puzzle, I quickly realized that the process consisted of two different tasks. First is the creation of the solution, which will be the tricky part. Second is uncovering parts of the puzzle in such a way to make the puzzle solvable yet have very few (ideally one) potential solutions. The second task to me seemed to be the easiest to implement so I decided to implement my generator in reverse, starting by implementing the hider followed by generating unique solutions.
Both tasks require that I have some type of model. The sudoku model should already exist as it should have been part of the player. To save time, however, I combined the model with the controller. This is not something that should be done as the time I saved by doing this was minimal (though as it turns out necessary) while the gain of having a separate and reusable model would have been nice at this point. Still, this isn’t that much work to implement and what I came out with is slightly different than I would have done in the first project.
The model class consists of an array of values and an array of locked tiles. Any tile can be set, with the set function setting the value of the tile to the mod 10 of the passed number. If the passed number is greater than 10 the lock value is set. This is done to make it easier to pass grid data but is not necessarily a user friendly way of dealing with this problem.
A convenience function for determining which group a tile belongs to based on the row and column was added. The row, column and group counting functions have more appropriate names this time as they are now countValueInX with X being row, col, or group. These functions simply count the occurrences of the indicated value returning the count. To finish off the class, clear and setData methods were added.
The next step then is to implement the hiding of tiles.
Sunday, April 10, 2011
Mythical Man-Month
One of the more interesting books that I read when I was in school was "The Mythical Man-Month" by Fred Brooks. This is the book that resulted in Brook's law, which is "Adding more programmers to an already late project will result in the project becoming even later." The point was that more people results in more overhead which results in diminishing returns so at some point adding more people to a project will actually increase the development time required to complete a project. Being a one and a half person team working part time, this isn't really an issue for me. What got me thinking about the book, however, was my looking into the indie development scene and noticing that small teams are becoming the standard.
It is interesting that in the early days of commercial game development (actually, pretty much all early software) was a single person working on the project. Slowly that changed to small teams. The team sizes began to grow, and now we have AAA commercial titles that cost hundreds of millions of dollars to create and have team sizes of hundreds of people. I don't think indie development will require that large of teams but I honestly never ever expected game teams to grow so large.
When you hear about a team putting together a game in 6 months, that is the time the team takes. If the team is 4 people, then a single person should be able to do the same thing in 2 years. But, that does not take the overhead into account. As I have the tendency to take on far larger projects than I should, this is actually scary to think about.
Still, I think watching a project evolve can be interesting and has the potential to improve the project if there is feedback so the larger projects I am working on will start to be posted to Blazing Games as sneak previews. Hopefully there will be more feedback than there was on my recent poll, but time will tell. If I find returning to a weekly release format is too much of a hindrance, I can always cut back to monthly or quarterly again.
It is interesting that in the early days of commercial game development (actually, pretty much all early software) was a single person working on the project. Slowly that changed to small teams. The team sizes began to grow, and now we have AAA commercial titles that cost hundreds of millions of dollars to create and have team sizes of hundreds of people. I don't think indie development will require that large of teams but I honestly never ever expected game teams to grow so large.
When you hear about a team putting together a game in 6 months, that is the time the team takes. If the team is 4 people, then a single person should be able to do the same thing in 2 years. But, that does not take the overhead into account. As I have the tendency to take on far larger projects than I should, this is actually scary to think about.
Still, I think watching a project evolve can be interesting and has the potential to improve the project if there is feedback so the larger projects I am working on will start to be posted to Blazing Games as sneak previews. Hopefully there will be more feedback than there was on my recent poll, but time will tell. If I find returning to a weekly release format is too much of a hindrance, I can always cut back to monthly or quarterly again.
Sunday, April 3, 2011
Decision 2011
For the first few days of April I am having a poll on my Blazing Games site to determine the future of the site. Right now the ad revenue on the site covers the costs of running the site but does not earn enough to actually pay me for my time or effort. For that reason I am trying to focus on some larger projects which can either be put on other portal sites or possibly sold commercially as indie titles. Phone platforms are definitely being considered. This leads to the question of what should be done with the Blazing Games site. I was thinking of returning to a weekly format, with sneak previews, betas, and incremental upgrades to existing games on the site being the focus. Alternatively, remaining monthly puts a bit less pressure on me so I can focus on my larger scale games. Perhaps the best choice, however, would be to go quarterly with the site updates and just focus on the larger scale games.
I was originally planning on posting the results of the poll today, but so few people have voted. Worse, half the votes have been for the non-committal whatever choice. For that reason I am going to leave the vote up for a few more days before making my decision. If you are reading this before April 7th, 2011 and haven't voted yet, please do so.
I was originally planning on posting the results of the poll today, but so few people have voted. Worse, half the votes have been for the non-committal whatever choice. For that reason I am going to leave the vote up for a few more days before making my decision. If you are reading this before April 7th, 2011 and haven't voted yet, please do so.
Subscribe to:
Posts (Atom)
