The web site of lostwebring

The Lost Web Ring


EXPLORE MORE OF THE LOST WEB RING (List)

[BLOG] - [NOODLINGS] - [G4M3]






CC:D DEV LOG - 1



CC:D "CONSOLE CORE: DOOMSDAY" is a game I have been developing in the Python programming language. It is based on some side projects I created earlier in my journey through programming and has been partly encouraged by an upcoming work training that will use Python.

The game as it is now really started to take place during an attempt to better understand object oriented programming. Languages like Python allow for the creation of "objects", distinct items within the code that can have their own identities and attributes. Using my old Alphagrid format, I created entities with tracked position on the grid and symbols that represent them visually as attributes. I then used inheritance, another useful element of objects to reproduce the attributes of its parent class while still being unique from them, to make predators and prey.

My original intention was to make a simple biological simulation with animal like creatures, but once I created behaviors that made predators chase prey and prey to flee from predators my mind immediately went to zombies.

With the formula down for the objects, I could easily add as many as liked. I added a behavior that replaced "eaten" prey with a new predator, added 50 humans, and it quickly turned into an infection simulator. My mind went wild from there and I quickly added more features. Soldiers with firearms that can protect humans, structures with destructible walls, a system for humans to repair structures and summon new units for help, and "heat maps" that encourage humans and soldiers to seek safety within structures.

It all felt like it very organically evolved at this point. What made it feel special is that it was a simulation where emergent behaviors happen. Sometimes a structure becomes a last stand for the humans, sometimes the zombies reach critical mass and leave a trail of destruction, sometimes the zombies hold a large portion of the map while the humans have their own reclaimed city with neither budging. I find this stuff very fun to watch. To me the ultimate success of a game is that you yourself can be surprised and entertained by it.

It is worth noting that this entire game was running as text from the windows command prompt console. The Alphagrid program I had made before proved that by printing lines of text characters as x values and the rows of text as y values I could map and display images using ASCII art to display my zombies and humans. The display area was one big block of text, and each movement would edit it to say remove "x" symbol from the 20th space in row 3 and add one to the 21st. The text would be displayed and then immediately cleared to create an animation effect. I feel like it was working amazingly well, except I had more plans and I was clearly maxing out the console's ability to do something it was not designed to do.

Looking around I decided the best path forward was PyGame, a library for Python specifically made for game development. It was a sharp learning curve at first, but thanks to some downtime while in Las Vegas I was able to do some testing and start understand it's workings.

Once I was finally able to start rendering my zombies and humans on the screen it was pretty exciting. Whereas the console would start really lagging at about 150 characters on the screen, Pygame could easily run 1000 smoothly. This was why I switched over.

I definitely committed early on that my goal was to keep the look and feel of the original console version, even though pygame can run traditional high resolution graphics. I learned that even classics like Dwarf Fortress use a similar process to keep their low-fi style but handle the graphical demands of their games.

It was also becoming apparent to me that my original version was built without any planning or structure and I was beginning to paint myself into a corner. I had avoided completely restructuring my code in favor of the excitement of seeing things happen, but I decided this was a great point to start from scratch and remake the game with much more intentional design.

A critical system I was beginning to realize would be extremely helpful for my game is chunk mapping. When I have all these humans and zombies running across the screen, each one is a unique object that is calculating its next move. But for the humans to know what they're fleeing from and the zombies to know what they're chasing, they must look through the index of all the entities on the world map and check if they are nearby. If you have 1000 entities, each one stopping to scan 1000 entities, the processing demand grows exponentially.

To deal with this, programmers have developed a system of "buckets", or I prefer Chunks since that's what Minecraft calls it, where the game area is divided into zones. When an entity needs to check it's surroundings, now it just looks at its nearby chunks and only reviews maybe 7 units, instead of 1000. It was slow going at first, this had to be done first as it effects how the positions of every item in the game is read going forward. But once I got it going the effect on processing speed was dramatic.


EXPLORE MORE OF THE LOST WEB RING (List)

[BLOG] - [NOODLINGS] - [G4M3]