Life in TGE 1.5
by Frank Carney · 03/02/2007 (11:32 pm) · 0 comments
Well I bit the bullet and converted my life implementation to TGE 1.5 from 1.3. It was fairly straight forward and other than changing a few header file location references and moving files around it did not take more than an hour. Granted I just had a few files to compile, but still.
One thing that helped with the move was keeping my sources separate from the "game" c++ directory. I built my own directory that was parallel to game. This made it easy to just copy my sources over in one chunk. I had all my cs files intermixed, but it was limited and if your creating a new game you would replace everything anyway.
Sorry, no screenshots yet. I am gearing up and getting ready to create in game shots of the algorithm. However, before I do that I need to create a War algorithm version and limit grid space. All cells will be limited to a caster radius. Otherwise one pattern could take off and produce hundreds of cells. If each cell represents a TS object it could drop frame rates to 0.
The War algorithm will introduce the concept of cell ownership to a caster. If opposing cells collide they will check for cell ownership of cells nearby and reduce cell count rather than increase count. The difficulty will be achieving balance, but since I am actually looking to have a certain amount of uncertainty (does that still make it uncertain?) it may be half the fun trying not to kill yourself or everyone around you!
One version of the algorithm I tried was to implement energy collection of each cell to increase its persistence. However, this proved to do either of two things depending upon the "life rules" I applied. It would either explode and cover the grid or do not much of anything other than additional novel constructs that were not possible in the normal rule set. It also made predicting patterns harder as the cells had hidden information. This is a good lesson that your cool idea may in actuality be a complete flop. Here is another vote for the rapid prototype.
Have fun,
Frank
One thing that helped with the move was keeping my sources separate from the "game" c++ directory. I built my own directory that was parallel to game. This made it easy to just copy my sources over in one chunk. I had all my cs files intermixed, but it was limited and if your creating a new game you would replace everything anyway.
Sorry, no screenshots yet. I am gearing up and getting ready to create in game shots of the algorithm. However, before I do that I need to create a War algorithm version and limit grid space. All cells will be limited to a caster radius. Otherwise one pattern could take off and produce hundreds of cells. If each cell represents a TS object it could drop frame rates to 0.
The War algorithm will introduce the concept of cell ownership to a caster. If opposing cells collide they will check for cell ownership of cells nearby and reduce cell count rather than increase count. The difficulty will be achieving balance, but since I am actually looking to have a certain amount of uncertainty (does that still make it uncertain?) it may be half the fun trying not to kill yourself or everyone around you!
One version of the algorithm I tried was to implement energy collection of each cell to increase its persistence. However, this proved to do either of two things depending upon the "life rules" I applied. It would either explode and cover the grid or do not much of anything other than additional novel constructs that were not possible in the normal rule set. It also made predicting patterns harder as the cells had hidden information. This is a good lesson that your cool idea may in actuality be a complete flop. Here is another vote for the rapid prototype.
Have fun,
Frank
About the author
I Started programming in HS and have never stopped. Now an 18 year vet of programming anything from assembler on a NES console to a nuclear waste processing system. If it can be programmed I may have tried to program it!