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!

No comments:

Post a Comment