Move Engine Recompleted

February 4th, 2012 1 comment

Once again I can move my units as I desire. Next is the reprogramming of the AI. For now, enjoy this screenshot of the movement area, recreated.

3 Steps Forward, 2 Steps Back

Well, time to tuck into bed for the night. While it’s disappointing that I haven’t gotten back to where I was 2 weeks ago, I think I’ll be much happier with the code once it’s done. Just about every variable is private now and the classes are properly encapsulated.

Doctor Who and Programming Time

February 3rd, 2012 No comments

I just found that my local library has the first two seasons of Doctor Who available on DVD. I watched the third season a few months ago and loved it and thought it was the only season they had. I’m wide awake and ready for some programming. I think I’ve got one more class to program and the game will be functioning again.

So it’s 9:30 and I’m settling down in front of my desk with season 1 of the new Doctor Who and FlashDevelop to finish my game prototype. Screenshots to follow later tonight, maybe even a video.

Programming A Click and Drag Function

February 3rd, 2012 No comments

Last night I decided to program in a function to allow easier map scrolling when using mouse controls. Previously I had made it similar to the Wii’s turning functionality in first-person shooters. When you got near the edge of the screen, the game would start to scroll in that direction.

The problems arose when you were just trying to access buttons that were off screen because the game would try to scroll in the direction of the buttons. It was just too easy to accidentally scroll. And if you wanted to scroll to the other side of the screen from where you were, you needed to move your mouse all the way to the other side.

Enter Click and Drag
So last night, I decided I was going to make my game scroll when I clicked and dragged. This was a more intuitive interface, similar to the iPhone’s scrolling functionality.

My first attempt at setting this up had mixed results. The scrolling was jittery and it wasn’t 1:1 for some reason. Check out my code below to see if you can spot the error. For reference, the mouseDown function is called when the user presses the left mouse button while on the map, the mouseUp function is called when the user releases the left mouse button while on the map and the mouseMove function is called when the user moves the mouse around the playField, but only after the mouse button is pressed.

private function mouseDown(e:MouseEvent):void {
	this.startMouseX = this.mouseX;
	this.startMouseY = this.mouseY;
	this.startX = this.x;
	this.startY = this.y;
		
	this.addEventListener(MouseEvent.MOUSE_UP, mouseUp);
	this.addEventListener(MouseEvent.MOUSE_MOVE, mouseMove);
	Main.stageSprite.addEventListener(Event.DEACTIVATE, mouseUp);		
}

private function mouseUp(e:Event):void {
	this.removeEventListener(MouseEvent.MOUSE_UP, mouseUp);
	this.removeEventListener(MouseEvent.MOUSE_MOVE, mouseMove);
	Main.stageSprite.removeEventListener(Event.DEACTIVATE, mouseUp);	
}

private function mouseMove(e:Event):void {
	this.x = (this.startX - this.startMouseX + this.mouseX);
	this.y = (this.startY - this.startMouseY + this.mouseY);
}

Ignore the fact that the game will keep scrolling if you happen to release the mouse button while your mouse is outside the flash screen. I haven’t yet figured out how to fix that, so anyone that has a solution should let me know. If you can spot the other error in my code, then you’re a better programmer than I was last night.

The Solution
The problem, it turned out, was caused by my use of this.mouseX and this.mouseY. You see, as you move a sprite around, it’s mouseX and mouseY coordinates change to reflect the relative position of the mouse from the sprite’s (0,0) point, usually the upper-left hand corner.

What was happening was the game would update the mouse coordinates at the same time it tried to update the map’s coordinates. Resulting in what some would call hilarity, but what I called annoyance. To fix the problem, all I had to do was update the references to this.mouseX and this.mouseY to Main.stageSprite.mouseX and Main.stageSprite.mouseY.

Main is my initializing class and stageSprite is a static reference to a sprite that never moves. So as the map scrolled around, the stageSprite stays where it is and provides an accurate reference point to calculate how far the mouse has moved. Here are the results:

Starting Position

The ending point after one click and drag

So overall, I’m pretty happy with the results. I’m trying to reintegrate my old classes for moving units around and attacking other units now. The only problem is that I changed many of the variable names for my units and actually implemented private variables instead of public variables, so I have a lot of updates left to make before I can even run the game without compiler errors. Maybe I just need to program those classes from scratch too. As I write this I’m buzzing from my 2nd coffee this week (I only drink coffee 2-3 times per week to avoid developing a tolerance) and I’m probably feeling way too ambitious. Maybe that’s for the best.

Medieval Tactics: Zombie Wars Concept

February 2nd, 2012 2 comments

I realized recently that I haven’t actually explained the concept for my game yet, so here goes.

Game Mechanics
Medieval Tactics is going to be a turn-based strategy (TBS) game, similar to Advance Wars. Each turn you can move and attack with each of your units.

Every unit will have statistics based on its unit type and every unit of that type will be identical. This is in contrast to most fantasy TBS games in which each unit is unique. I thought this would allow for better tactical decisions, because once you learn how to use a unit type you know how to use all units of that type. This also simplifies the balancing because I know exactly what each unit will be able to do.

Each map will probably have a specific set of units available to it. I’ve considered adding the ability to purchase units at the beginning of each map to add more strategy to it, but if I don’t have time then it won’t be added. At the end of each level, player’s will receive a grade or score based on the number and health of units remaining. This will be used to generate a cumulative score that will either unlock future levels or provide a bonus in the final level.

Units
So far I’ve decided on 14-15 units to include in the game. This should be large enough to provide a learning curve and diversity of map types, but small enough to allow easy balancing.

Good Units
Spearman
-High defense
-Average attack and armor
-Average movement

Swordsman
-High attack
-Average defense and armor
-Average movement

Archer
-Average, medium-ranged attack
-Low defense and armor
-Average movement with ability to move and fire

Hammerer
-Very high attack
-Low defense and armor
-Average or high movement depending on balancing

Lancer
-High attack
-Low defense
-Average armor
-Very high movement

Knight
-Very high attack
-High defense and armor
-High movement

Catapult
-Very high attack with large range
-Average armor
-No defense
-Low movement and can’t move and fire same turn

Cleric
-Low attack, defense and armor
-Ability to heal allied units
-Average movement

Enemy Units
Note: Most zombie units will have an ability that fully heals them whenever they destroy a unit. Zombies would be able to turn units into zombies to replenish their numbers.

Zombie
-Average attack
-Average defense and armor
-Average movement

Zombie Archer
-Average, medium-ranged attack
-Low defense and armor
-Average movement with ability to move and fire

Explosive Zombie
-Very high attack no matter what unit’s health is
-Low defense and armor
-Average movement

Hulking Zombie
-Very high attack
-Average defense
-High armor
-Low movement

Vultures
-Average attack
-Average defense and armor
-Very high movement with ability to cross all terrain

Necromancer
-Very high attack (Or maybe ability to ignore armor)
-High defense
-Average armor
-High movement
-Ability to turn any unit it defeats into a new zombie unit

Level plans
I’m aiming to create around 20 levels for the game, depending on how long it takes to complete each level. Overall I hope the game takes a couple hours to complete and hopefully the ability to get a bonus on the last mission will encourage people to replay levels to get a high score.

Control scheme
I was originally planning on making the game completely playable with either keyboard or mouse, but I’m thinking that optimizing it for mouse will make for a better playing experience. While I prefer using keyboard controls for games, I don’t think I can easily optimize a strategy game for keyboard controls.

I also think that mouse controls are just more intuitive, i.e. click this unit, click there to move it, click the enemy to attack. Keyboard controls would be more like, let’s see, press ‘n’ to go to the next unit, press ‘m’ to move, scroll over to the target square with arrow keys, press ‘m’ to move to that square, press ‘a’ to attack, scroll over to target unit with arrow keys, press ‘a’ again to attack that unit.

Final Thoughts
There are a couple additional mechanics I’d like to include, such as wizards with spells, water-based units and an alternate campaign. I don’t think any of these are going to make it into the first version of the game. I’ll reserve them for sequels.

Any thing you’d like to see in the game that I’m not including? Let me know in the comments.

Programming Part-Time

January 31st, 2012 2 comments

So I know I haven’t made much visible progress on my game since I started this blog. And I think it’s due in large part to working on it part time.

Since going back to work after the new year, I haven’t had a normal sleep schedule. I got used to staying up until 2 AM every night instead of my typical 11 PM. I’m finally starting to get back to my “normal” schedule. But until now, this terminal sleepiness has made programming after work difficult.

This is a situation a lot people get into when they start trying to start up a business or project on the side. A full-time job can be really draining and after one and a half hours of commuting and eight and a half hours at work, the last thing on anyone’s mind is putting in work on a side project. The only thing keeping me working on my game is my intense passion for games in general and my strong desire to turn this into a career.

While I don’t expect to quit my job and start developing flash games full-time in the near future, releasing and selling my first game is the first step towards that goal.

Even if I produce a mediocre game that sells for $50 after I put a couple hundred hours into it, it’s still worth it. If I want a career in video games, having released one will help. If I want to turn this into a business, having released a game is necessary. Even if all I do with this is use the experience to improve my programming skills, it’s worth it.

So I’m resolving to get this game finished and ready for sponsorship on Flash Game License by May 1 of this year. If I have to rush the last bit and release a game that’s barely more than a prototype, I’ll do it. Stay tuned over the next 3 months to follow my progress. You’ll know as I get closer to the deadline whether I’m going to release a crappy game or something actually worthy of playing.

Let me know what you think of my goal in the comments. Is it not ambitious enough? Too ambitious? Should I instead follow the advice of this article on Lifehacker and schedule some time each week to work on my game?

The Results of 3 Hours of Programming

January 29th, 2012 1 comment

So after doing 3 hours of programming from scratch I only have the bare bones of my game completed. I did manage to make my level select screen and the rest of the game is in much better shape than it was before. Unfortunately the new game is still a good 3-4 hours short of being a full prototype.

This is what I had after 45 minutes of programming

I think the lesson to learn from this is don’t attempt to complete a prototype from scratch in one sitting if you’re not a great programmer. Also, don’t start at 11 PM if you know staying up past 2 AM isn’t a realistic expectation. I’m guessing the people that do this from scratch thing probably have more tools than just basic actionscript 3 at their disposal. Once I have my game working again I may have to look into it to see what’s out there.

Game Jam Time

January 28th, 2012 No comments

A Game Jam is a programming session undertaken with the intention of creating a complete and working game prototype. Since I had so many issues when I went to integrate my level selection screen, I’ve decided that I’m going to start from scratch and see what I can do. If all goes well, I’ll post a picture of the new version of the game tomorrow.

I know I can stay up until at least 2 AM, so that’s at least 3 hours of work. Having already made the prototype of the game once that should be enough to get everything working as it does now. Since I already know what mistakes I made the first time, it might actually work better after I’m done with this. Wish me luck!

Unexplained Bugs

January 26th, 2012 No comments

My game has been on Flash Game License for a week now and in that time all 3 of my friend’s with fan accounts have logged in and tried it. The first one discovered the error caused by code encryption. The second one told me that they couldn’t figure out how to end turn, but after looking into that I couldn’t find an issue. The third one reported the same issue as the second one. So I dug a little deeper.

Apparently, moving units is causing the “End Turn” button to disappear. The third tester also found that when clicking on an enemy unit, the game completely locked up. I have yet to reproduce either of these things even when playing the game online on a different computer. So I guess it’s back to the drawing board on the buttons.

Additional Game Progress
In the meantime, I’ve been working on adding a level selection screen up front. It’s making me realize how bad a decision it was to treat the “Main” class as though it were the class for my battle screen. I don’t have a “destroy” function to quickly make everything disappear when I want to go back to the stage selection screen.

That’s a lesson for anyone starting on their first game. Make every screen the user might see it’s own class and make the “Main” class (the one that runs every time the game is opened) as minimal as possible. It should contain a static variable referencing the window itself and should create an instance of whatever class will contain your opening screen and then attach it to the window. That way when you switch up which screen your game opens with you only need to change which class is called. Don’t do what I did. You’ll have to rewrite most of it later.

Listening to Other Indie Developers

January 24th, 2012 1 comment

So I spent a good amount of time listening to the Infinite Ammo podcast today, specifically the one with Andy Moore. I think it helps a lot to listen to other game developers, especially when they have more experience than I do. Their discussion ranges all over the place, but here’s a few things I pulled from it.

Hook your players quickly

Like Murphy Lee said, “Wat da hook gon be?” For flash games specifically, it’s important to get players excited about the game as soon as possible. Players aren’t paying any money up front to play a flash game so if they aren’t enjoying it they have no reason to stick around. With more traditional, paid games, players have a sunk cost that they want to try and recoup before dropping a game. It’s a behavioral economics thing.

I’ve read before that with a flash game, you want to try and hook a player in the first minute, including load time. That’s also one of the reasons why keeping game file size down is important because people without a fast internet connection might give up on your game if it takes too long to load. Ideally, the player will feel like they’ve accomplished something within the first 4 clicks.

That might seem extreme, but why not? One click for “Play”, one click for “Okay” on the tutorial slide, one click to select your unit, one click to select an enemy. BOOM! You’ve defeated your first enemy! YAY!!!

I’m trying to keep this in mind as I design my user interface.

Metrics can make games better

While it’s important not to rely on metrics to design your game for you, they are a necessary tool for fixing and polishing your game. For example, let’s say you’re tracking what percentage of players are completing each level. Over all 20 levels, about 3% of players quit during every level, but you find that 20% of players quit on level 5.

Is it because level 5 contains an especially difficult challenge? Is there a glitch that causes some people to be unable to complete the level? Is there a mistake on any of the hints on that level that causes confusion? This merits further investigation, but without the metrics you’d have no way of knowing that there even was a problem.

Tips for new Indie developers

I realize I’m still in the target group on this one, but here are a few of the tips I gathered from the Infinite Ammo podcast.

1. Release your games
It’s very difficult after spending a lot of time on a creative work to think rationally about it’s quality. I know from just a couple months of working on this game that it’s all too easy to put an endless amount of work polishing, correcting, adding new features and generally improving the game. But if you do this forever, you’ll never release your game.

It’s also possible to get to a point where you’re sick of the game, having playtested it for the thousandth time and still not being satisfied with the way the characters move or with the level difficulty. At that point I think it’s time to fix any big glaring bugs and then publish it. It’s better to publish a game that has a few issues than to never publish a game at all.

2. Secure your code
This is a particular issue with flash games. Because of the way flash saves your game, it’s all too easy to decompile the source code, make whatever changes you want and then upload the game as your own. Fortunately there is software that encrypts code so that it’s more difficult/ near impossible to make changes to the swf file. Flash Game License provides a 25% code for Kindisoft’s secureSWF. It’s still $300 for the professional version, but it’s better than having your games ripped off.

3. Don’t be afraid to be inspired by other games
While this isn’t specifically mentioned during the podcast, it’s a lesson I drew from it. Around the 2:20:00 mark they discuss game clones. While copying a game action for action and level for level is definitely too far, there is a point at which you can borrow from other games. Innovation comes when people take what came before them and either reimagine it in a new way or combine it with other things to make a new combination.

It’s all too easy for critics to call any work derivative, but at the same time it’s impossible to construct a creative work in a vacuum. If you’re especially inspired by another game, don’t be afraid to say so. As long as you put your own touches on your game you have nothing to be afraid of.

Code Encryption and the Stage

January 22nd, 2012 No comments

So I’ve learned a valuable lesson when it comes to flash code and code encryption software. Don’t use the default “stage” variable outside of the initialization function.

So for those of you not familiar with flash, the screen that is displayed when you open something in flash is called the “stage”. It is created automatically when code is compiled and everything that shows up on the screen has to be added as a child of the stage. So if you want 3 airplanes to appear on the screen your function call should look something like this:

tempAirplane = new Airplane();
stage.addChild(tempAirplane);

tempAirplane = new Airplane();
stage.addChild(tempAirplane);

tempAirplane = new Airplane();
stage.addChild(tempAirplane);

Encrypting your code is a necessary step when publishing a flash game, otherwise anyone could copy your flash game, decompile it, and change whatever details they wanted to pass the game off as their own. Unfortunately, when the code is encrypted some things may break. In the case of Kindisoft’s secureSWF, almost all references to the stage become broken. The only things that seem to be left intact are those in the initialization function that’s called the first time the stage is created. So keyboard events created during that time will stay intact and any children added to the stage at that time will be added, but from there on out, you will need to rely on adding children to the objects added during the initialization function. So I added a “stageSprite” object and then added everything else to that. My new calls to add objects look like this:

stage.addChild(stageSprite);
stageSprite.addEventListener(Event.ENTER_FRAME, enterFrame);
stageSprite.addEventListener(Event.MOUSE_LEAVE, mouseLeaving);
stageSprite.addEventListener(MouseEvent.MOUSE_MOVE, mouseEntering);
stageSprite.addEventListener(MouseEvent.MOUSE_DOWN, onClick);
stage.addEventListener(KeyboardEvent.KEY_DOWN, keyPressed);
stage.addEventListener(KeyboardEvent.KEY_UP, keyReleased);

tempAirplane = new Airplane();
Main.stageSprite.addChild(tempAirplane);

tempAirplane = new Airplane();
Main.stageSprite.addChild(tempAirplane);

tempAirplane = new Airplane();
Main.stageSprite.addChild(tempAirplane);

Before the changes, my action menu stopped appearing when a unit was clicked and my onClick functions to select a target to move or attack stopped working. Post changes, everything seems to work great. Now that it’s working online with the code encryption I can start working on new things. Next step is creating a navigation menu to actually allow multiple maps to be selected from (right now it only loads one map that can be played endlessly). I also need to design a company logo to appear when the game loads. Any ideas for maps that might be fun?