Sunday, April 28, 2013

Spawning Code, and a tutorial level

Last week I set out to make a tutorial level for Germ Wars.  I did that.  However, I feel like I haven't accomplished very much.  Maybe it's that the code I wrote is a little ugly, or maybe this is just the amount of work I should expect out of myself.  I feel like the code had to be written essentially this way though - I've been working on a level builder/tutorial, and the basic structure of the code ended up being a large number of essentially if time==1 {do stuff} else if time==2...  The numbers for each time are also just static magic numbers and difficult to change, but I don't really see any way around that.  The structure looks a little ugly but at least I did make my specific tutorial actions a child of the more general timeline object.

In order to spawn enemies without using the obj_spawner (which runs the normal game), I also migrated commands for randomly positioning enemies to a script this week.  This was a little frustrating with GameMaker, but I think I found a good way to do it.  The problem stems from Gamemaker's lack of a good 2d vector structure.  You can't create your own structures except by using real GM objects, which are expensive.  Instead you have to use built in data structures like ds_list, ds_stack, ds_grid, etc..  However these are quite annoying as commands are very long.  For example, to create a list, add a value to it, and then read that value, you have to type:

l = ds_list_create()
ds_list_add(l,5) //you have to pass the list as an argument
//compared to l[0], the below is incredibly long
var val = ds_list_find_value(l,0);

Gamemaker also has some strange ideas about scope.  Arrays using l[0] etc actually are supported, but scripts can't use them.  Variables are by default scoped to the object and therefore saved from action to action and script to script.  The keyword var can be used to make a variable local to just one script.  Also, scripts run directly on the object the calls them.  So if you use a temporary variable in a script but don't declare it 'var' its stored in the host object.  By using this functionality though, I can store my return values as _x and _y.  Since this is very specific script to script though, I'm using _r0 and _r1.  This takes up relatively little memory as long as I'm calling a bunch of scripts in one object rather than one script in a bunch of objects.

For next week: Interface stuff.  Most notably, building a GUI to expose a bunch of constants to playtesters and designers.  Then, the week after I can easily make different gameplay modes (easy, medium, hard, etc) by letting other people come up with the numbers.  Otherwise I'll spend too much time playing the game, not enough time adding features!

Friday, April 19, 2013

Intro to Blogging

My first blog post!  Exciting!  In the next few months hopefully I'll be writing about programming and designing video games, specifically my current project Germ Wars.  Right now it's a "school project that I'm going to keep working on", something I have never actually done yet.  Typically, school teams split up and our project dies, rapidly.

But!  This project may be different.  For one, for once someone other than me is seriously interested in continuing the project.  That would be Don Xu, the artist.  We both want to ship a title by publishing Germ Wars to Android's marketplace.  

It's going to take a lot of work to get there though.  The control scheme is designed for a computer keyboard, not an Android touchpad, and gameplay may have to be revamped to adapt.  Right now I might describe Germ Wars as a Bullet Hell shooter without the shooting, and the precise dodging required may not translate well.  We're gonna have to do a lot of playtesting and probably change up the mechanics.

Assuming we do get the gameplay working well, I'm also going to be adding different modes of play and some features expected in phone games.  Right now there is just one "Go until you die" arcade style mode.  We will be adding more difficulty modes and/or levels that introduce new mechanics.  I'm currently working on a tutorial the player can play through (rather than read an Instructions page).

The second reason I might be able to finish this project is this blog.  Hopefully writing it will help me organize my thoughts and force me to hold to deadlines.  Also thanks to Matt Findlater for inspiring me to write a blog.  See you next Friday, when I will have the game's tutorial done and a new blog post!