Happy new year everyone.
Let me take this changing of the year to dig up the history behind Super Battlelands.
GoGoWarsAlmost two years ago I was working on super battleland's predecessor GoGoWars. GoGoWars was written in the Go programming language with an ncurses like gui. My theory was if all the graphics were simple unicode characters then I could focus on gameplay and AI.
In retrospect the character based graphics had the opposite effect. They were supposed to make the graphics portion of work simple but instead those simple graphics meant even rushed results took significant work. The perlin terrain generation was at first used to place grass but got relegated to placing just lakes.
My bigger lesson learned from GoGoWars was that a proper game architectures is vital to keeping code manageable. My failure here prompted me to enroll in two game focused courses my university had open.
Kart BountyKart Bounty was a arena car fighting game. It turned out horrible. We built this as a group project for one of the university courses. I designed the architecture and that worked out fine but the gameplay has boring. All bullets were physically simulated which forced them to be slow, rare, and hard to land. Instead of combat being fast and chaotic actually hitting anything required pure luck. As a result the team decided to making bullets instant kill
The lessons from this project were lessons from failure. I learned that good team dynamics are vital. Our team did not have a clear vision nor a leader. The team members were all strong programmers and this hurt us. There were two groups in this course and while our group failed the other group created a decent game with a solid theme and a real difficulty arc. That group had only 1 strong programmer who could dictate technical and gameplay decisions and he acted as the defacto leader.
Mass DriverThis was the second course's project: a homebrew shoot-em-up for the original gameboy. Programming for the gameboy's 1MHz Z80 was pretty limiting but a fun exercise in optimization. This project went fantastic despite everyone on the team being a strong programmer. I handled gameplay programming so stuff like bullets, hit checking, enemys, etc. Nothing significant about the game architecture here, just a large global struct and a fixed time delta game loop.
Early Super BattlelandsA few months after Mass Driver I started work on Super Battlelands. For the first few weeks I focused on graphics and the overall things improved day by day. Important thing to note is that while the visuals changed early on there was no gameplay or simulation. Even when units start appearing there is no logic to their movement.
Day 1: I played around with Three.js's predefined features. Here we've got shadow mapping, bump mapping, "terrain generation", plus a working sun and ocean.
Day 2: We go from a bunch of random rendering features to a game board setup.
Day 3: Buildings and texture-less tanks. The buildings are procedural and show off the shadow mapping which is still enabled.
Day 4: First visuals of the roads. These road spots are the road "seeds" from which roads between cities will be generated. The second university course covered some retro dungeon crawlers which used a similar path generation algo.
Day 5: Progress on that road generation.
Day 6: Roads are now smoothed and rivers we now have river generation.
Day 7: Those tanks are now moving in random directions. This is the point when development switched to gameplay focus. The core game architecture now exists at this point.
Two months after that I created this thread.
Community
