Special Behind the Scenes Feature: Programming Sunrider (1)
Word of warning though: being a coder writing code is kind of my thing. You can expect to see some in this post.
Let’s start at the beginning. I first heard about Sunrider during the kickstarter through /r/visualnovels on reddit and I was really impressed with the video, the music, the story, art and the fact there was even a demo. For a reason I’m not sure of myself I thought I’d send Sam a message through kickstarter offering my services. I told him I suck at writing, don’t know anything about music, can’t draw a picture to save my life and doubt I’d be useful as a voice actor but that I was sure there was something I could do for him as I did have an affinity with programming. I offered to perhaps do some bug testing or other boring menial labour so that Sam could focus more on the actual creative aspect of development.
Not long after I got a message back asking if I could completely rewrite his entire combat engine. Mind you, at this point I knew nothing about python or ren’py so my initial reaction could probably best be described as ‘lolwat’. I hadn’t even noticed that it says on the kickstarter page all the way at the bottom that they were looking for a programmer. Now, I’ve had some limited coding experience with various languages and tools but the only real (useful) things I ever made were in visual basic for applications (VBA), the language used in Excel and other MS Office software.
I think you will see that if you want to have 10 enemies in a battle this is going to take some writing. A slightly more advanced way would be to put the values into a list, like so:
And suddenly we have a list with 10 times a value of 500 in it. Further down the line when an enemy is damaged we can change the corresponding value in this list. This saves some writing but more importantly you can have the loop repeat as many times as you want. It doesn’t have to be 10 times, it could be 20 times. Or more.
The original demo however didn’t use any loops. Didn’t use lists or functions. It definitely didn’t use custom classes. Classes are really nifty and very flexible concepts in programming. By defining your own class it is possible to refer to each ship on the battlefield as it’s own object which has a number of properties which can be easily set individually. For example, if I wanted to set the HP of the sunrider I can do so like this:
Sunrider.hp = 2000
But classes support more than just properties. It also allows you to define your own methods tied to an object. If I want to move the Sunrider to a different place on the battlefield I can do so like this:
There are tons of advantages to this approach that are probably boring to most people so I’ll leave it at this.
After getting a handle on python and ren’py I set out to completely recreate the combat system used in the first demo based on this new data system. For one thing it allowed for a limitless number of player and enemy ships right away and it made it very easy to define and customize new ships. Especially setting up each battle in the game would be very easy. This very first rewrite took me a solid month to get anywhere but I made a lot of cool new features that weren’t in the demo.
Somewhere in mid January Sam decided he wanted to completely redesign the user interface. Although the core of my battle system wouldn’t be affected much by this it would still require some significant rewriting of what I had already made to account for the layout changes. It was at this point I pushed for the idea of changing the game to a 2d grid system instead of the 7 columns we had up to that point, as it would be now or never as I didn’t feel like having to rework the interface yet again after that. It would certainly be a massive challenge to write but the game would improve massively if we could manage to pull it off. Sam insisted we’d need a way to zoom in and out of the battle grid but I was skeptical it could even feasibly be done in ren’py. It’s really not something ren’py was made for!