Groups of germs! And a demo just for you.

A pretty normal week - I accomplished what I set out to accomplish. I got germs spawning in groups working earlier today (goal met!), but it still needs a little work before I'm satisfied with it. Right now, germs spawn in groups of 3 every time, but changing that to other numbers should theoretically just be adding a new variable to the growing list of tweakable constants. Spawning in groups is quite cool, and I feel like it gives me as the designer a lot more control over how the game plays. Now I can theoretically do things like spawn a ton of enemies on one side of the room and a have a group of appropriate pills come from the top. Groups also make the game a little easier/slower. They're basically just as easy to dodge and collect, but are easier to process and give you higher rewards for eating them.

Above, the group coming in is circled.

I think I'm close to being feature-complete; whatever comes next should be in response to playtesting. And I should do a lot of playtesting! Biggest features still to go in: difficulty modes (easy, medium, hard), and maybe a joystick for movement? Simply moving wherever your finger is has not been working out particularly well; even with all the changes it doesn't mesh well with the fine play that is still required. Group germs are awesome though, and more fine tuning of the play experience may be able to fix the problem without changing the control scheme.

Uploading a playable version of the game this week! It's an apk file, so you can play it directly on your Android. You'll have to copy the apk from your computer to your Android, then install it on your phone using a File Manager. Download it here: https://www.box.com/s/j0nyb89mrc9mkt0gtej7

For next week: improving and making more use of the group system. Easy, medium, hard modes also need to come in soon, but none of the numbers (enemy spawn rates, enemy speeds) are really set in stone yet. Since difficulty modes will mainly just be tweaking those numbers (and something to do with groups of germs), it will be difficult to have the modes be meaningful yet. Getting the code base ready for it would certainly be a good thing though.

Finally, I have to hurry on this project and release something soon, because I'm starting work on a group project soon. Sadly this will suck away my time, but it also means I will be putting something on the App store soon (or at least something better on Steam workshop). Thanks for reading and have a good week!

Long time posting.

It's been a while since I posted up here, so I have a lot of updates to talk about. The biggest one: it works on Android phones with very few problems. Before, I had gotten it to work on the phone, but there were screen size issues, and, moreover, the game played pretty badly. On the computer, the game has been about using the arrow keys to barely dodge enemies. On the phone, I switched input so the germ moves towards your fat finger. This is much less accurate, and often times you can’t see what’s going on. I’ve been trying to correct for this through significant changes to gameplay, designed to favor more fluid play less about fine dodging and more about choosing where to go. I’ve also made a few changes which help the “fat finger” be a little more precise.

The first update was getting rid of boundaries around the screen. Instead of confining the player to a small square, the camera will now follow the player as he moves. This gave the player a lot more breathing room, as he can no longer get caught by the edge. It also opened up interesting chase gameplay, where the player can pursue a red germ or a specific pill long after it would previously have left the screen. To facilitate chasing, I also added a dash which lets players move faster, but only in a straight line. It’s a pretty interesting risk.

It’s more difficult to move up/down than left/right, because your finger gets in the way. So I set the page orientation to always be landscape (horizontal), and made all enemies come from the left or right. I also made the screen size smaller, so enemies are larger and easier to dodge.

Finally, I’ve added particles! These add no gameplay value whatsoever, but they certainly look pretty!

Next up is to add a little more structure to enemy spawning. Rather than pure random spawning like currently, I’m going to make enemies spawn in certain patterns, like a line or a circle, and then all move in the same direction. Also, potentially making enemies follow paths across the screen. That should be good for the new follow a specific direction gameplay.

Windows Problems

I need a new computer. That's basically what this week has been saying. My drivers for Android phones don't work. I'm not actually sure how to solve this, but I know my Windows Update hasn't been working. So this week I've been repairing Windows Update. I tried a ton of different solutions online, and narrowed down my problem a little bit. Finally, I just posted on a techsupport forum (techsupport.com). They've been super helpful! A few told me to try things I'd already tried, but a lot of it was helpful. One guy even told me where to find a Windows Recovery disk, which I hope is going to solve my problems.

Other than that, I made a few relevant changes to the screen size/resolution. It's still quite buggy though, and I need to more research into porting to Android devices. Right now I'm trying to keep just one version of the game that I can play on both Windows and Android. Theoretically this is possible because I'm using Gamemaker which can export the same code to both platforms, but it may not be realistic. The immediate difficulty is simply a different screen size: most Android devices have a size of 480wx800h, but my Windows laptop has 1280wx800h. And both Android and Windows can have even more sizes than that. Right now my rooms are just too large for the Android device - either it shrinks everything or only displays one portion of the screen. I can programatically adjust the size of my rooms, but it may be better to also have separate Android and Windows rooms. I need to try out more things and do a little more research.

Sorry for the short post - I didn't get that much done this week and tech support is really quite boring. Hopefully soon I will be able to test the game on my phone without having to build an apk. I'd also like to get the screen resolution working, and fix a few other bugs I found on Android.

Droid and Device Drivers

This weekend (it feels like I've been working a lot more on the weekend than during the week) I've been getting my computer to work with the Android development kit. Well, it doesn't actually work yet, but the good news is that I did play Germ Wars on my phone.

Gamemaker has export functionality to basically everything - HTML5, Android, iOs, Steam/Windows. This is pretty awesome, and one of the reasons we're using Gamemaker. It also has some nice debugging tools; once I get it setup, I should theoretically be able to just plug my phone into my computer, and compile the game directly from Gamemaker to my phone. Unfortunately, my computer has a lot of issues with my phone’s drivers. So I’ve way too long going through a bunch of help files and resources trying to fix my computer, which also has issues with Windows Update and other stuff...

I was able to run the game on my phone by exporting the Gamemaker file to an apk (the eventual end product that will be on Google Play), but it took a little longer than I would like. There were obviously some issues, the most prominent being the resolution of the screen is way too wide, but it actually worked pretty well. There wasn’t any noticeable lag, despite my never having optimized for the phone before. And apparently Mouse Click translates into Press on Screen automatically.

Finally, I also set myself up a ticketing system on gitHub with tasks and priorities to get them done. While I did write done some stuff for what I was going to do this week last week, I ended up being a little lost and switching gears mid-week. That's now how I'm setting the goals you see here, and hopefully it'll keep me on track and I'll always know what I should be working on. The biggest priority now is still getting android to work properly – I might give up on the drivers but I’ll still work on some of the other changes like the aspect ratio. Then a back button out of the app & to the main menu using an Android specific button. And my stretch goal is a dash feature by tapping far away from you or something.

Pause Complete!

It’s been a crazy week. Monday-Wednesday always pass quickly, so I only really got to work on Thursday. The week was gone so fast! Luckily I got a lot of work done yesterday, so I managed to at least basically complete the pause/debug menu. Both this and last week’s task were fairly UI oriented and don’t look the greatest, but we have an artist who should be good at that. Here’s a screenshot of the pause menu.

This week took quite a bit of wrestling with Gamemaker, even more so than usual. The basic idea was to have a list of variables that myself and playtesters could change to adjust difficulty etc. I wanted to store them all in just one list so it would be easy to swap in/out variables whenever I wanted. However, Gamemaker doesn’t support pointers at all. It used to have functions that would let you look up variables by name, but with the move to mobile, HTML5, and such these no longer exist. Eventually I resorted to just listing out each variable on in a switch statement. So, for those 5 variables above, I have a script getValue and setValue which have a switch from 0-5 that maps the 0th inputBox in the list to the GERM_SPEED_MOD variable in obj_constants, and the 1st to ENEMY_SPAWN_TIME, etc. A pain if I want to change up those variables and a pain to make and a pain in general.
Making the pause menu was pretty fun, though I had a few troubles with deactivating/activating objects. I sorted most of those out with delayed pause changes. The problem was I would reactivate instances, but couldn’t execute code in those objects using the with(object) construct that same step. To solve it I put called an alarm[1] event when pausing/unpausing, and the alarm[1] event would execute the with statements. Since the reactivation code had a chance to resolve, everything worked out. I’ve also now accepted the importance of alarm[0] ‘slow creation’ events that require other objects’ initial variables. By calling those 1 step after all the objects have been created, it’s assured that each object will already have run its creation code and will have variables the other object needs to check. For example, obj_menu and obj_player both play music in the ‘slow creation’ event that needs to check if obj_constants’ MUSIC_ON is true or false. (By the way, this functionality is mostly for myself because, as good as our music is, there’s only so long I can bear listening to it.)
This week things are going to start getting exciting. It’s time for playtesting! I’m going to be adding a feature or two and playtesting them. I already have a basic timeline set up for the tutorial, and I’ll expand that to work with the regular spawning code which right now is pretty much entirely random. So I’m gonna add a little more structure to that. This will also let me add unique challenges to the game – like flooding the screen with one color of germ, adding waves from one side of the screen, or spawning trackers to come in from multiple directions.

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);

ds_list_delete(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!

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!