Special Behind the Scenes Feature: Programming Sunrider (1)

watashi_avatar.mediumHey guys, Vaendryl here. Sam asked me to write something for the blog so here I go.

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.

Idiot that I am I accepted. I learned python in a week or so on www.codecademy.com and learned renpy through online documentation and analyzing the Sunrider KS demo and the RPG framework for ren’py made by the very talented Jake Staines.

As it turns out the original demo had a battle engine where every fight was completely scripted from the ground up with liberal use of copy paste. To understand what I mean the best way is to show you. Compare the following 2 ways of recording a value in code, like the HP of a ship:

enemy1_hp = 500
enemy2_hp = 500
enemy3_hp = 500
etc.

copypasta

Samu’s Note: What’s wrong with copy pasta code? :(

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:

Create an empty list named  HP_list
loop 10 times:
each loop add a new value of 500 to HP_list

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:

Sunrider.move(new_location)

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

For example, my new engine implemented shields and armor, various buffs like damage and accuracy and environmental buffs that applied to everyone. It even implemented a lot of different weapon types and the concept of weapons with multiple shots. Every shot gets calculated seperatly and interacts differently with armor and shields. I also created some pretty complex code for missiles, because those can be shot down while traveling from attacker to target by other ships in between.

I eventually released this old version as an April Fools joke about a day or 2 before we releases the real march beta.

earlybeta

This was the cutting edge in ye olden days.

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!

As luck would have it though I did think of a way to do it and a quick proof of concept later I knew it could be done, so Sam gave the go ahead and I started building combat engine number 2. Next time I’ll write more about the various troubles and challenges we faced  while taming that wild beast  :3

screenshot0078

It was a long journey here.

 

4 thoughts on “Special Behind the Scenes Feature: Programming Sunrider (1)

  1. Nice. Hmmm, for some reason, a lot of kickass things people do with Ren’Py are made by people completely new to it.

  2. I took a little liberty of looking through that early code -_-” I just hope that the whole backend of the game does not look like that or you are going to hit multiple so called programmers nightmares/hell :)

    What you did there in 23 Lines for a single enemy Takes only 8 lines with a direct remodel approach:

    if Enymy2Exists:
    Distance_to_Target = abs(Enymy2Location-PlayerUnitLocation)
    LocationMod = (2 – Distance_to_Target) * 25
    disp_hitchance2 = weaponacc+very_long_formula
    if PlayerAtkType == 4 and Distance_to_Target == 0:
    disp_hitchance2 = 0
    if PlayerAtkType == 4 and Enymy2Ryder == False:
    disp_hitchance2 = 0

    And if you did it correctly this would be a simple iteration over objects of type enemy with all the calculations done inside of an object… just work on those programming skills for now PLEASE its for good of us all ;)

    Regards Dedicated Beliver

    • As stated in the post, the previous code was entirely scrapped and the whole engine was remade into what you see in the last screenshot. You should check out the coding in the beta to see all the improvements. :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s