Post news RSS Super Battlelands Early Development

Screenshots from the early builds of Super Battlelands plus the projects which lead up to it.

Posted by on

Happy new years everyone! Let me take this changing of the year to dig up the history behind Super Battlelands.

Almost 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 workload. 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 only lakes.

My bigger lesson learned was how a proper game architectures is vital to keeping code manageable. My failure here prompted me to enrol in two game focused courses my university had open.

Kart Bounty

Kart Bounty was an arena car fighting game. It turned out horrible. We built this as a group project for one of the aforementioned 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.

Mass Driver

This 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. 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 Battlelands

A 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 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.

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.