The DevLog is a place to see what I'm currently working on. Occasionally I'll post links to demos of things I'm working on. Check back here often. For more information about a particular project, visit the Projects page.
There's some cool new upgrades I added to help defend against those pesky elemental dragons. Introducing the fire and ice flak bomb upgrades. These work just like the regular flak bomb but now harness elemental damage which should prove useful against enemies weak to specific elemental attacks. Tip: Use fire flak bombs against ice dragons.
Another cool upgrade is the Fairy Bomb. This is a cure related skill that unleashes ferocious war mongering fairies that are hell bent on seeking out their targets to inflict imminent and utter ... healing. Yeah, so they're not that ferocious I guess but don't tell them that. These guys home in on injured units (you included) and restore some health when they get close to you. If no units need healing they will live out their natural short lives happily bouncing about the terrain until their life timer expires at which point they explode (as they should) dealing no significant impact on the surrounding environment.
The user interface received a few much needed tweaks. You can now scroll through your action bars using the mouse wheel. The action bar ID is now listed in between the up and down action bar scroll buttons. Currently there are three available action bars to put all your cool projectile related upgrades. This may increase in the future.
Also UI related, you may now move your character with the arrow keys in addition to the WASD keys. I'm not sure why I forgot to add that, it was literally just four lines of code ;) Don't get too excited though; I'm not yet working on a fully customizable keyboard bindings interface. That's a nice-to-have feature that you may see in the future though.
Updates:
New Upgrade! Fire Flak Bomb Arrow (fire skill)
New Upgrade! Ice Flak Bomb Arrow (ice skill)
New Upgrade! Fairy Bomb Arrow (cure skill)
Added "Like" button to the HTML landing page of this game. If you're on facebook then be sure to "like" this page.
Balancing:
Decreased mana cost for elemental arrows significantly
Decreased mana cost of Flak Bomb Arrow.
Increased the cost per rank upgrade for Flak Bomb Arrow
Fixes:
Fixed issue that caused Hunter's Spike Trap to not work properly.
Unintentional cruelty to units fixed: After last update, dead units would get inverted and placed underground when frozen, on fire, or sliced in half. Death visuals should work properly now. Poor game units. As if being frozen, chopped, or burnt wasn't enough I had to also turn them inside out and bury them underground.
Fixed issue where a grunt unit's head when encased in ice caused extra ice to form above the top of the head as if to accommodate a cone head shaped unit. The ice now forms evenly around the unit's head thus making him less self conscious but more importantly allows him to die with dignity.
Fixed issue where the Wacky Bomb would break if it moved to the left or right edge of the screen too high above the ground. Oh that wacky Wacky Bomb. Always getting itself into trouble. Perhaps he just needs some extra love and attention so he won't act out so much. This can be said for much of the features in this game so he will just have to wait his turn!
Stay tuned for updates. Keep me informed of any issues you may find.
I released Bowmaster Winter Storm as Beta. I can't believe it's been over a year since I posted the last Alpha update. I've added a lot of cool features since the last Alpha post. Several of the features that I mentioned in previous devlogs are now present in the game. I'm still debugging some of the features, but rest assured I plan on updating the Beta more frequently than the Alpha. Check back weekly for new updates to the game. You'll be able to see what's new directly in the game with the "News" feature I added. The News page will also allow you to catch up on all previous updates and replaces the "version info" html page that was used in the Alpha version.
You can still play the Alpha for now with all of your saved progress, but your saved data will not carry over to the Beta. Consider the Beta a fresh start.
Five years ago I was just about almost graduated with my undergraduate degree in Software Engineering. I was in dire need of some place to host all of my Flash content that no longer was going to be hosted for free on my school's server. It was just after the 3rd new-style Star Wars movie came out. I remember because while waiting in line to see the movie I was discussing with a friend possible domain names. We were throwing around names with "Vector" in it and he suggested LostVectors. I loved it and I was lucky it wasn't already registered.
Since then, what started as a portfolio and place for all my experimental Flash work has now turned into a nice little independent Flash game site. I'm still hard at work and I don't plan on quitting any time soon. So stay tuned!
Yeah, so I've been working a lot and have been writing several devlogs but haven't had a chance to post them until now. In short, I've been so busy working that I tend to use every last minute of the night performing "just one more test." I'm taking this short break to post these updates. I recommend starting with 2010-04-06 Tell Me Where It Hurts Part Part 1 and then moving on up. I hope this squelches any concerns that maybe I was slacking off this month. Time for a break.
2010-04-09 Tell Me Where It Hurts Part 3: Security Checkpoints
This memory testing is quite the bug hunt. I've been testing between two computers and two browsers. I've been patting down every game object for illegal memory stashes. Offending code blocks are stripped and searched and sometimes even completely exterminated. Progress is being made little by little as I debug and optimize while innocent code is made to suffer inconvenient slow performing test operations.
It has been a tedious process but still productive. All this debugging has reacquainted me with some old code. Some of which I haven't seen in months. It's been nice getting back in touch. ;)
I still haven't found that magic one-line-of-code that if fixed would solve all my problems...
////////////////////////////////////////////////////////
/////////////////////// PAIN IN BEHIND BEGIN ///////////
// set to false before testing public static var GAME_BUGGED:Boolean = true;
// set to 0 before posting public static var MEMORY_LEAK_RATE_KBS:int = 1024;
/////////////////////// PAIN IN BEHIND END /////////////
////////////////////////////////////////////////////////
9:45 PST - I finished coloring and formatting this series of devlog posts. That part about me "taking a break" mentioned above turned out to be an hour of devlog mayhem. The real break starts now.
9:46 PST - Okay, I'll break for reals in a second but I think I just plugged another memory leak...
I've been having trouble with the pikemen so I have them fight to the death for my amusement. Actually, I don't even watch the battle. I just work on other stuff and wait for my computer to come to a screatching halt due to flash consuming all of my resources. At the end of this night I looked over and saw that they were still duking it out AND my ram was still not completely ravaged. As you can see, there has been 323 level changes (levels last just a few seconds) and still no problems! Yay. I've decided to tell you this because I want to completely jinx my code. Or do I? Take that Karma. Or don't not take it not. See if I do not don't care not so much so not... Everyone stay real quiet... ... ... okay I think the it's safe now. I need food.
2010-04-08 Tell Me Where It Hurts Part 2: Not (All) My Fault
So after doing some further tests I was able to pinpoint code that would result in memory leaks. The code itself looked harmless and functionally it worked.
I narrowed a leak to a “doSomething” function in my Util class. I knew it caused an error because when I turned the function into a no-op the leak went way. So I knew that something in that code was causing the leak. But just looking at it, it made no sense whatsoever why there was a leak.
Example original code:
public static function doSomething(clip:MovieClip):void
{ var mc:MovieClip;
do some sort of gotoFrame logic on clip
for all children in clip {
if child is MovieClip { mc = MovieClip(child);
doSomething(mc);
}
}
}
This code recursively does something on a movieclip and all of its children that are also movieclips.
public static function doSomething(clip:MovieClip):void
{
do some sort of gotoFrame logic on clip
for all children in clip {
if child is MovieClip {
doSomething(MovieClip(child)); // cast child and send
}
}
}
Notice that I removed the local variable “mc” and just passed a MovieClip casted version of child as the parameter. There was NO functional reason for this change. I really had doubts that this would have any affect. After all, “var mc:MovieClip” is a local variable and should be marked for garbage collection at the end of the recursive function call. The function does in fact end so don’t think it’s runaway recursion. We’re dealing with clips that are just 3 subclips deep at most and I use this function several times a second on many clips without any hanging.
When I tested the second version of the code there was no leak to be found. Undeniably the code change had some effect. Why?!? My theory was that since I was calling this static function from inside a non-static instance of an object that maybe Flash had some obscure rule about local variables inside static functions and it caused the program to hold on to all references to MovieClips thus preventing them from ever being garbage collected.
I don’t pretend to know everything there is about Flash or how it works. But something about this seemed real fishy. I often like to blame flash for its bugs but I do this mostly to complain about the IDE. I like to trust that the flash player is solid and without error... yeah, so naive. It’s not a good practice to blame the flash player because then you may write off real issues as “flash bugs” when in fact they are your fault. I try hard to give flash the benefit of the doubt. I’ve done so for this entire week. I’ve torn apart my code to pinpoint the causes for memory leaks. I’ve been rebooting my game practically one feature at a time just to find issues. This is how I found the issue mentioned above.
Even though I felt a little relieved that I’ve finally “fixed” one of the leaks, something didn’t feel right about that fix. I didn’t feel it was my fault. It felt like a hack solution and what bugged me the most was that I had no real understanding of the issue. There was no white-paper or release-notes that I was aware of that explained the issue I uncovered. I’m not sure I can even recreate the leak using anything but the complex environment of my game code. I’d love to make a lean code example of the issue without my entire game attached and submit it to Adobe and ask “why?”. I felt run down. A little defeated...
AND THEN... On a whim, I decided to test the code on a different machine. I should have done in the first place. It’s good practice to test the application in different environments with different browsers. I don’t know why I assumed my environment was error free. I was wrong.
I took the same exact game that had the leaky code and ran it in IE on a Windows XP 32 bit system. I was originally running on Windows 7 64bit using IE 32 bit. Using the same problematic version of my game but using the XP machine with latest flash installed the game had NO MEMORY LEAK. At that point I was mad. All this time I thought it was my fault. All this time I spent turning code on and off and locating obscure areas of code that my flash player decided it just didn’t like willy-nilly.
So now I go back and test variations of my game using past tests that failed before to see if they would pass this time on the different computer. Unluckily only some of the previous failed tests passed this time so I still had memory leaks that were my fault somewhere. OR the flash player on this other PC had a different kind of criteria for giving me faulty memory management. Either way I had to fix something because chances are I’m not the only one with the issue. However now I’m left second guessing whether or not the leaks are my fault or the player's.
All I can do now is do further tests and isolate the areas of code that cause the game to break. Even if it’s a dumb flash bug and not my fault I still have to adapt since no amount of yelling at Adobe is going to fix this issue right this second.
The plus side to all of this testing is that it’s giving me a good understanding of how much memory certain features use. This will help me determine where I need to optimize the game to make it run smoother.
2010-04-06 Tell Me Where It Hurts Part 1: For the Horde
I’m oh-so-close to posting a new update to Bowmaster Winter Storm (Alpha 0.0.1.9). I was so ready to start preparing the files for post and I blocked out an entire day to work on it. As I started working I discovered, much to my dismay, a memory leak! Dun dun dunnnnn! Well, I noticed that after performing some overnight tests using never ending battles that the game would use up all available memory and then crash the web browser... err...maybe I shouldn’t be telling you this.
To those of you who don’t know what a memory leak is it’s when a computer application starts using up memory but doesn’t free it up after it’s done using it. This is most often the developer’s fault due to a programming bug or just poor design. A simple flash example of how this might occur with poor design is that let’s say every time you killed a unit or closed a window that instead of removing it from memory the programmer coded it to just turn invisible by setting alpha = 0. Essentially this would cause the data to continue to exist in memory instead of being freed for use for new enemies and new windows. Unfortunately my memory leak was caused by something way more difficult to locate.
Anyway, it’s quite demoralizing when you set aside an entire day to work on play-testing and game balancing (the fun stuff) to then discover that you first need to fix a major issue instead. Not a great way to start out the day. Looking at the faded out crashed internet explorer window with a frozen image of bowmaster carnage in the background, I was not looking forward to hacking up my code to find the cause behind the memory leak. Image having an apartment that you just cleaned and organized and then getting a knock at the door – It’s the FBI and they have a warrant to search the place. Sure it has to be done but in so doing they’re likely going to trash the place. That’s what debugging memory leaks can be like. I just got done working on my unit-skinning system and re-integrating old units and adding new ones. Now I need to go into the code and start turning off stuff, add hard coded test functions to inspect output, and otherwise break the game in order to try to fix it.
Not knowing how long this was going to take or even where to start for sure, I did my best to divide and conquer. Unfortunately it’s not easy just turning off half the code without adding new bugs, but in theory if you could turn off areas of the program in half increments you can potentially narrow down the source of the problem fairly quickly. For example, if I suspected that some of the new unit skins may have been causing the problem, I could just not load those units and only load the ones that I know have worked in the past.
Not only is it difficult to find a memory leak, it may be difficult to replicate one in a short period of time because it may take a while before the impacts are noticeable. I needed a way to accelerate the process of replicating the issue. I hacked my game to load tons of units in random areas of the map so they would instantly engage in battle. With more data being loaded and unloaded more frequently I could now inspect the memory usage using the Windows system processes inspector to see the memory increase quicker. I was also able to get the web browser to crash in a matter of minutes instead of hours. Yay!
It may sound odd to be happy to cause the game to crash, but when debugging it’s essential to be able to recreate the issue. With this step complete I was ready to start turning off sections of my code to see if doing so would remove the issue. The usual suspects for potential memory leakage were the new units, the elaborate special death animations (slice in two, electrocute etc.), and certain custom units like pikemen and dragons that have special ways in which they attack.
Technically speaking, there are few known best-practices that will prevent memory leaks from occurring. If you’re not a programmer or you do not care about these tips then feel free to skip down to where I talk about how dumb I am.
Tips:
1. Use weak references when adding event listeners.
addEventListener(“eventString”, listenerFunc); // wrong way
addEventListener(“eventString”, listenerFunc, false, 0, true); // correct way. The last three parameters are optional but the default useWeakReference parameter is set to false so you need to set it to true.
2. Even if you use weak references, call removeEventListener to explicitly remove event listeners when you know they aren’t being used.
3. Adding code to clips embedded in a timeline may cause memory issues. For example if you add a listener to a clip on the timeline and then that clip is replaced by a blank keyframe you may have memory problems. Another example is if you give a clip on the timeline an instance name and then move that clip to a different layer with the same instance name you may have memory problems.
4. Remove or nullify references to unused objects. An object will continue to stay in memory if there are references to it. In Bowmaster for example, I keep a singleton reference to the LevelManager class instance for easy global access in other classes. However, this instance is only relevant when the player is in-game and is not relevant when viewing the main menu screen. Therefore I need to make sure to set the global static singleton variable to null when the game window is closed otherwise all objects still referenced by the LevelManager will not be freed.
How dumb I am...
So despite how smart I may sound listing all those tips above, I felt like a total flash noob spending the entire day trying to locate the problem. I kept turning on and off code and checking the results but every time I wasn’t able to specifically pinpoint the issue. I thrashed for hours, 12 full hours, trying different things and documenting the results. At some point you just need to call it a day, and I probably wasn’t very productive or efficient for those last four hours I worked, but it’s hard to stop when you think to yourself, maybe if I try just one more thing...
The next couple of days I was forced to only work in short increments, but I was making progress. I eventually turned off all the units except the grunt and started testing one skin at a time. I discovered that just one of the five unique grunt skin sets was causing a memory leak. Guess which one... It was the orc. Yep, I created a new grunt unit that used the same basic animation as the skeleton foot soldiers but changed the graphics to look like an orc. And then for some reason, in an act of defiance, the orc decided to crash my game. I give him life and this is how he repays me? By hording all the memory and never giving it back? Bad orc! Bad! (::scrohboo::) So it wasn’t just the fact that he looked like an orc -- that would just be silly. Specifically I narrowed it down to some embedded code that I used to animate the shine on the orc’s sword. What was unsettling was that I used this embedded code approach before in other animations. I’m thinking that the new skin redesign may have made this code incompatible, or maybe it was always broken and I just never noticed the memory leak until now.
Luckly, after some tweaking I was able to get the shine animation to work AND not crash the web browser (i.e. no memory leak), but I’ll need to inspect other areas of the game that use similar embedded code and fix those as well.
It was one of those traumatic software development experiences where there’s no hope and you wonder if you’re going to have to redesign the entire application... Yeah, maybe I blamed flash a little too. I was quite vexed about this issue. I did not want to crash people’s web browsers. I care about the user. Yeah, maybe the issue will only affect those that play for hours straight without refreshing the browser, but I’m not going to deny them that opportunity just because I didn’t want to fix a bug.
On one hand it looks as if it took several hours just to find and fix one bug. On the other hand, I just spent several hours towards the goal of ensuring that the user has an error free experience. And in the process of doing so I’ve implemented several useful debugging systems that will allow me to test the game much easier in the future.
Yeah, so maybe it’s not so easy to skin an orc. But in the end it will be worth it. Stay tuned. You’ll see.
UPDATE: Not so fast jase... don't think this is over. Read Part 2.
Here's just a simple example of the skinning stuff I've been working on (click on the buttons at the top right to change the image).
Originally I was redesigning the character animation models to allow me to replace the entire set of body parts with any different set of body parts so that ... it would make my life easier. But then I started to see the potential for changing just certain parts of the character such as their helmet or weapon. I kind of got carried away a little and needed to take some steps back to determine all the impacts that my redesign had on other game systems such as collision detection and damage calculations. I kept running into chicken-egg conundrums regarding game unit initialization. Like... "do I skin the unit first, then reinitialize the bounding boxes? What if I want to add a weapon after the unit has already been initialized. But I already initialized all his weapon stats! Oh crap, now he's not doing any damage for some reason. Why are my arrows passing right through him!?!?... ::quits and goes to play Mass Effect::" So as you can see, even if none of that makes any sense to you, I had to re-think some of my initial design. This is why the frackin skin job has been so hard to kill. Gladly I think the hard part is over. I've developed a flexible approach that allows me to skin, reskin, change weapons, remove weapons, change armor, remove armor for the Pikeman game unit. After a little more testing, I will adopt this same approach for the rest of the game's less complex units.
In other news...
Snowboarding:
I stopped (for now) due to injured elbow (it was worse than I thought... physical therapy here I come!). I'm hoping to get back on the slopes soon enough. At least I didn't break an arm like my friend did on the slopes. He just recently got his cast off right before his 30th birthday. I asked him, "how's it feel to be 30?" he says, "It's great... I just started physical therapy."
Gaming:
I've just beat Mass Effect 1 since I love living in the past. I missed out on that game... rather I tried it but didn't really give it a fair chance and it just fell by the way side. After finishing a play through of Dragon Age I decided to give BioWare's space epic another try. My original mistake the first time I tried Mass Effect 1 was to judge it on its underwhelming 3rd person shooting mechanic. I didn't give it a chance to hook me in with the story and biotics (spells). So with all the news and podcast coverage on Mass Effect 2, I was dodging ME1 spoiler bullets all matrix style so figured it was time to give ME1 another shot considering how apparently awesome ME2 is. As soon as I beat ME1 I bought ME2 from Steam. I couldn't wait. It's cool how ME2 uses your personal character's save file from ME1. I'm not very far into it but so far I'm really liking it. And they improved the shooting mechanic! Yay. And did away with all that pesky inventory management...yay?
2010-01-12 Hello, My name is Jason and I am a Projectile
Hey people. I hope everyone’s new year is going well and that you all got everything you wanted (or deserved >:| ) this holiday season. I’ve mostly been enjoying some time off by visiting with family, playing video games, and snowboarding but I did manage to put some time into game development. I took a little bit of a break from Winter Storm to work on a few updates to Bowmaster Prelude. Yeah, I still go back and tweak my old games from time to time. The latest update to prelude features some much needed user interface changes for sound controls along with a new in-game stats display which shows such things as your accuracy and greatest damage dealt for the current round. I also replaced the intro narration with my friend Kris Kowal’s voice as well as bumped up the quality of all the sounds. Go check it out if you haven’t yet.
Yeah so in other exciting news I recently acquired the domain bowmaster.com. This was not as easy as it sounds as it was already owned by a very cool entrepreneur that was using it for an entirely different reason (ribbon/bow making business). He decided to move on from that endeavor and was generous enough to allow me the opportunity to acquire the domain. So now I have it. It’s mine. Muahahaha. Right now I just forward the url to LostVectors.com but in the future I may use the domain to further expand the Bowmaster empire.
Let’s see what else...
I’ve been doing lots of snowboarding lately. I like snowboarding but I’m not a big fan of some of the culture. I’m sure there are lots of nice fun snow-sport people who aren’t total jerks but I’ve encountered a notable amount of less-than-desirables on and around the slopes of Mountain High Resort. My pet peeves: line cutters, in-line smokers, people who litter, and drunk people. It’s people like these that make me reluctant to call myself “Snowboarder”. But, yes I am “one who snowboards” and for convenience sake I refer to myself as such if asked. Just as I am a PC, Gamer, Indi-Game-Developer, Geek, etc if you’re keeping track of labels.
So for Christmas I got this shirt from my lovely awesome fiancée. And since I have Viking blood which grants frost resistance +10 I rarely need a jacket when I go snowboarding. Hence, I’ve adopted this shirt as the official tabard for my snowboarding guild. The shirt is a nice way to say “hey look at me... but wait, I’m not your typical ‘hey-look-at-me-snowboarder’ I’m a gamer too” if that makes any sense. So despite all of the undesirable snowboard “culture” occurring around me I still had the pleasure of a random group of kids shout out to me, “hey check out that guys shirt” followed by some impromptu Mario themed a cappella.
Snowboarding Stats:
Local Trips Taken: 5
Runs shredded: 60
Times airborne: 101
Successful landings: 99
Elbows hurt: 1
Helmet status: 100% awesome, worn at all times while on slopes.
As for games I’ve been playing lately...
Left 4 Dead 2: Still totally awesome fun. Love Scavange and Versus mode. The BatGirl Posse (headed by my fiancee BatGirl no less) is an unstoppable force of awesome.
Dragon Age: Origins: I completed my first play through as a heroic mage who made the ultimate sacrifice for the greater good. (::spoiler alert::) Long live King Alistar.
Mario Bros Wii: Cooperative rage building game. Will BatGirl and I call off the wedding? Our love is strong... but will it endure the accidental mushroom stealing and head stomping?
Munchkin Quest (Board Game): Epic/funny RPG board/card game. Lots of fun. Rules open for debate. Debates may result in real-life family feuds. Feuds may result in bloodshed. Band-Aids sold separately. (Fun fact... I once shared a cab with Steve Jackson, creator of Munchkin, in San Francisco at the Game Developers Conference).
Winter approaches. This year seemed to fly by. It’s almost Christmas! Lately I’ve been working on programming for my yet to be released Bowmaster Winter Storm Beta. I have been working on some cool stuff that will help me optimize file size and increase productivity in the long run. Specifically I’ve been working on character skinning. In the past I used unique movie clips for each character even if they used the same animation. So for example when I wanted to create new units I would just copy and paste the same animation and rename and manually re-skin the graphics. The problem is that each copy has its own set of hundreds of animation key frames. This was the design approach that I carried over from Prelude and with the amount of content planned for BM2 this is just not going to work out anymore. Flash tends to choke and crash when I open the animation library because there’s just so much there (and I plan on adding lots more!). Hence, it was time for me to take action.
I’ve redesigned the beta build of BMWS so that I only have one animation clip per character type that I can then dynamically change the body parts to. So imagine a stick figure that has all the basic animations such as walk, attack, die... Then I just attach whatever parts I want to the stick figure and make the stick parts invisible. Since there’s less duplication in the Flash library, the export .swf file size is reduced which means the game loads faster and can be easily be uploaded to other sites that have file size restrictions. It also means I can cram more content into the game without using as much space and without crashing Flash as often (not a hard thing to do by the way).
This new approach will also increase productivity. In the past, if I wanted to change the animation of the walk sequence I would have to manually fix the animation in all the characters that used the same walk method. Now I can just make the fix to the main animation clip and all characters that use that animation model are automatically updated.
And lastly, aside from increased productivity and reduced file size, this redesign opens up the possibility for increased variety in character models. For example, in the past if I wanted to make two skeleton grunts with the same animation to have two different weapons (one a sword and one an axe let’s say) then I would have to create two different movie clips (or do some other tricky sub-clip key frame magic). Now I can swap any body part at any time, including the weapon. Now that everything is skinable, all body parts are targetable through Action Script. I can load anything from armor, weapons, clothes, monkeys, ham sandwiches, anything. Imagine instead of seeing the same ninja graphics for every rank, you see the color of his belt change. Higher level orc grunts could have spikier armor and meaner looking helms than the low level initiates. Maybe you could even upgrade the weapons or armor of your own troops and see this reflected in the character models. These are still just examples of what is possible – I won’t give away any specific new details just yet.
2009-10-22 My (Windows7) LAN Party ... The Invention of Awesome
So my friend signed up for the Windows7 party pack with free copy of Windows7. I guess you had to give a story about how you’d have some sort of Windows7 party and if they picked you they would give you a box of party supplies (balloons, streamers, party favors ... all Windows7 themed) along with a free copy of Windows7. My friend applied for the free copy and gave some story about how he was going to have a boat party and sail around the harbor... he did it just for the free copy of course... but since I was having a LAN party he offered to donate the decorations. So I kind of had a Windows7 party... But I’m a little bitter because had I known about the free windows deal I would have signed up because my LAN party was no typical frag-fest and it would have most certainly awarded me my own copy had I applied.
Okay so here’s what I did: I combined a typical LAN party (Call of Duty 2, Soldat, Left 4 Dead, Demigod) but added Live-Action-Roleplaying elements to it. Of course my guests were completely unaware of this feature until I “rescued” them from “real-life” wearing a mad-hatter hat, some Ozzy Osbourne sun-glasses, and wielding a kick ass (plastic) crusader sword. I escorted guests from outside my apartment and opened the gate to my parking garage using none other than my totally legitimate Game Master magical powers (electronic key fob) and escorted the refugees of reality to the safe room... the Realm of Anti-Reality (aka my apartment).
Bare in mind my friends aren’t huge Live-Action-Roleplayers (neither am I really, though I’m totally for it ;) and also bare in mind that not everyone showed up at the same time... so I’m running back and forth from my apartment, in and out of the safe room, up and down elevators, being stared at by several NPC characters (my neighbors) while looking like a crazy mad man holding a plastic sword and pretending to open the automatic gate with his “force powers”. At least it’s kind of near Halloween time, but mind you my LAN started in the middle of the day so there was lots of daylight and little chance at going stealth.
Anyway... so at the safe room I started the character creation process. My friends were like, “you’re are nuts” and I’m like “just bare with me here, if you want to opt out then you can be an NPC and you won’t be affected by any spells...” and they’re like, “Spells... oh god, what are you up to Jason.”
Naysayers! But I was determined to convert them and they were all willing to give it a shot.
So the first part was the character creation process... First they had to give themselves a new Name. Then they had to choose their character class... Thief, Assassin, Peace Keeper, or Wizard. Then they had to pick a side: The Green Berets (allies of the Pirates) or The Red Army (allies of the Ninjas). All of this info went onto their sticker name tag. Then I gave them 5 gold coins and their XP score card (note card) and gave them a single bronze mardi gras bead necklace (to indicate they were level one).
As we played games throughout the night I would award XP and gold for winning matches. People would keep their own score (we used the honor system) and as people leveled up they would get more beads and higher ranked colors (such as silver, gold, and then purple).
Gold coins would be used to buy items such as nerf guns, ammo, snacks and drinks (honor system again... 1 coin for all you can eat/drink per trip, unless you were a thief then you might just steal the food and hope a peace keeper didn’t catch you).
Yeah so early on in the night my fiancée, as a thief, chose to steal all of the “good” food from the counter and set up shop with all of her stolen goods charging high prices per item. She also stole the pizza from me when I was paying the delivery guy and then extorted 25 XP from me (the Game Master) before letting anyone have a piece. She played her part well... perhaps too well.
So later on in the evening I introduced spells and gave out class specific quests. For the spells, I created a few basic ones to give people ideas and then asked everyone to take a note card and write their own spell idea down. You had to write down the spell name, what it did, and your name (author of the spell). Spells were things you could cast on yourself or on another person and were semi-game related... stuff like, “Spell of Melee Weapons Only” where you could only use melee weapons, or “Call of the Wild” where the person had to yell out a roar or give a battle cry whenever they were about to attack someone. Someone got both of these spells cast on them during free-for-all Call of Duty and it was pretty funny to watch. Another spell I liked was, “Spell of Questioning” the person had to form everything they said into a question (even if it was a statement)... the guy was like, “Who just killed you!? Was it me? How ya like me now? ... Do I have the enemy flag!?!? Shouldn’t I be protected right now!?!?!” I’d hand these spells out randomly to people, everyone got one to cast sometime during a match and they got recycled and more were added as the night went on.
Yeah so the spells were pretty wacky and highly un-balanced and ad-hoc but it added to the craziness and people really got into it.
Then there were the class-specific quests. There was an over population of assassins, so the few peace-keepers there were had their hands full. One of them even got corrupt and started selling nerf guns and ammo to the villains. So I created a quest for the other two peace-keepers to grief that person for the rest of the night. I gave a quest to some of the assassins to stealth kill execution style to the back of the head certain targets (with nerf guns or in game... whichever was possible). They couldn’t be caught by the peacekeepers or else it wouldn’t count. At this point there was just one Thief and it wasn’t my fiancée. She must have eaten a poison apple because she was a sleeping beauty for the rest of the night ;) So I gave this thief a quest to steal all of the peacekeeper’s nerf guns without them looking and then hide them somewhere. He also had a separate quest to steal their peace-keeper hats (which ironically were mobster hats) and throw them across the room.
There was only one Wizard. I gave him the quest to create five new spells and hand them out to random people... He took it upon himself to create way more than five and instead of giving them to people he sold the spells. He then would create immunity spells to cancel those spells and sold them to other people. Yeah so he kind of got super rich with gold and I had to eventually “patch” the game and nullified any immunity spells that were out there and I made all previous nullified spells re-activated.
I even had Wii Sports Resort going, and a little Air-Soft shooting gallery with little plastic ninja and pirate “army men” in which you had to shoot only enemy targets and avoid hitting your allies. Of course it was completely safe and eye protection was required. I kept a global scoreboard of Pirates vs Ninjas... I think Pirates won... though there was lots of friendly fire and collateral damage so it’s hard to tell if this was intentional.
Yeah so I don’t know if anyone has ever done something like this. If not, I just invented something awesome.
2009-10-08 the sleepy giant... (is not very reponconsive*)
So I’ve been trying to cram as much summer activities into every last shred of daylight left nowadays so game development has been simmering on the back burner lately. However since my last post I’ve been incrementally working on new game modes for Bowmaster winter storm (yet to be released). The design is highly interchangeable so I’ve been having fun creating some interesting victory and defeat conditions... for example (hypothetical):
Mission: Fire Dragons Invade the Town!
You are victorious if you accomplish any of the following:
1. Kill All Fire Dragons
2. Destroy the Enemy Castle
You will be defeated if any of the following occur:
1. Your hero dies.
2. Three of the five escaping villagers are killed.
3. The refugee shelter is destroyed.
Here’s an example of how crazy and modular these conditions are...
Mission: Beat the Clock Jumpy Happy Land
You are victorious if you accomplish any of the following:
1. You jump 99 times.
You will be defeated if:
1. The game timer expires.
2. You die.
3. You use any weapon.
Disclaimer: This is just a hypothetical example and this exact level scenario will probably not be in the game (maybe in a separate challenge mode... oh cool idea jase).
So hopefully I’ll have more chances to work on game development in the near future. For now I have to make room in my apartment for the Epic Rocktober Birthday LAN Party that’s about to go down. Time to get rid of boxes and boxes of childhood memories in the form of old schoolwork papers, soccer and little league trophies, old PC Gamer magazines, empty N64 boxes etc... it’s so hard to say goodbye. I feel like I’m defragging my life... what sucks is that it doesn’t happen automatically overnight while I’m sleeping.... like a sleepy giant... (you thought Bowmaster WS was the giant... nope. it was me all along. How’s that for a plot twist?)
*responsive – a “happy word” according to that little “I’m a PC” girl that is a on the new windows7 commercials. Rockin’ slideshow. My favorite is the kitten in the sea of marshmallows. If you dvr’d the season premiere of House then look for that commercial. It’s hilarious. I watched that thing like five times.
I still working on balancing units but I’ve finished implementing the unit rank system for all of the current units in the game. The rank system (unit level system) allows me to set unit stats and abilities based on a single rank number. So for example I have a function that sets all sorts of stats and AI code based on the rank number for that unit. This makes it easier for me because I can call a single function (e.g. trebuchet.setRank(4)) and all the stats that are relevant for that unit are updated (e.g. hit points, movement speed). The unit AI code also may use this rank number to determine how the unit will think. A low level dragon may fly low and not move around as much as a higher level dragon. A high level shield grunt will block more often than a lower one. A ninja may use more advanced melee attacks at higher ranks.
So for these past weeks I’ve been integrating the setRank function and identifying variables and AI code that could be scalable according to the rank. This will provide the player with new experiences when encountering the same types of enemy units later in levels. Aside from unit rank icons I’m thinking about maybe tweaking the look of the player skins slightly to reflect rank, like changing the color of the ninja’s headband, or the number of spikes on a grunt’s helmet. This is a nice-to-have feature at this point though and I’m focusing on gameplay and functional stability at the moment.
I have a rough plan of the level progression as it relates to unit types and ranks. I’ll be refining this plan as I continue development. My next major tasks are updating and balancing the upgrade system and developing new game level objectives.
Upgrade System Development
The current alpha version (0.0.1.8.3) has a demo set of skills and skill mod combinations with some random costs and skill requirements associated with them. These skills, the mods that are available, and costs may not reflect what the game will be like at launch. Specifically, I plan on revamping the ally unit upgrade system. The unit pre-requisites will be made clearer and you’ll be able to upgrade the unit ranks to match or overpower the ranks of enemies you encounter. Also, the current version does not have player rank requirements but in the future certain skill may not be available until your character reaches a certain rank.
Game Level Objectives
The current alpha version (0.0.1.8.3) has only one objective. It is the same for every level. Just kill every enemy and don’t get killed yourself. I plan on having a few new types of game objectives. I have been planning on doing this for a while now so this isn’t late breaking news, but until now I haven’t been able to start development this aspect of the game.
Here’s just a few ideas for game objectives:
Capture the flag: Classic Bowmaster Prelude level objective where you can either win by capturing the flag or destroying all of the enemy units.
Defend your base: Win by successfully defeating all of the enemies. You lose if your base is destroyed.
Attack enemy base: Win by destroying the base against a never ending horde of enemies. You lose if you die. Perhaps you have a limited number of troops at your disposal (ouch that sounds harsh... at your “disposal”)
Escort/Protect: Protect a slow moving caravan or injured unit as it is transported from one area of the map to another.
These are just a few ideas for game level objectives. I also plan on generalizing the design of these objectives to allow for interesting variations. So even if the objective is familiar the situation may be a lot different. Instead of escorting a single unit from one place to another, you may have to protect an exodus of refugees escaping from a raided town and they’re coming from the same direction as the enemies.
I’m in the early development process for these features so I haven’t completed a whole lot of code for the other modes, but I have been toying with some variations on the current game mode. Since I’ve been working a lot with the unit AI code I’ve been trying to refactor the code to anticipate these new game modes and mode variations. One very important design change was the concept of which way is “forward”. Right now I have the good guys always come from the left and bad guys from the right. They each move “forward” toward the other team. I used to have functions in the unit AI code called advance() and retreat() but this was always relative and became very confusing. I also locked myself into the idea that good or bad units will _always_ come from the same side. Well I’ve finally generalized this code and now I can place a unit anywhere on the screen and it will move to a target spot of interest. No more confusing functions and no more “forward” variable or hard-coded start position point.
This redesign means that I can now create some interesting new variations on the current “kill all enemies and don’t die” objective. I tested two new ideas variations. The first thing I did was switch the starting positions, just to see if the AI still worked. Success! Both armies marched towards each other as expected. It was just a little weird because it was so different to be shooting in the other direction (especially if you’re using the pull string method). I then tried something a little more interesting. I place the starting spot for the good guys in the middle of the screen next to a stonekeep and created spawn points at both the left and right edges of the screen. It was very exciting being completely surrounded with almost no safe place to retreat too. Maybe I’ll create a zombie level ;)
So I’ll continue to provide devlog entries as I work on the BETA but it may still be a while before I post the BETA to play. However, I’ll continue to support the ALPHA that’s currently up so if there’s any major bugs found then I’ll try to fix it and re-post.
2009-08-10 Bowmaster Winter Storm Beta Status Update
I've decided to focus on preparing the current build of Winter Storm for beta release. I still have quite a few homework assignments to complete before the beta is ready to play but stay tuned for updates. I will continue to support the current alpha release with critical bug fixes, but I've officially created a branch in development. The next major content revision will be Winter Storm Beta (version 0.1.0.0).
So lately I've been spending some quality time with each and every game unit. Some units have been misbehaving, some have been severely malnourished and neglected, while others are clearly overpowered and have been picking on the other units.
I'm balancing and play testing each unit individually. I've been tweaking the AI a little here and there. I've even just added the ability to tell your catapult or trebuchet to move to a particular spot on the map. I may add this functionality to other types of units.
Once I’m done with the first round of unit balancing and AI tweaking I'll move on to balancing the profile upgrade system.
Development on game balancing is underway. Currently I'm working on making unit strengths and abilities scalable as the levels increase. This means that the same type of unit will have increased stats and more challenging AI as the game level increases. For example, a low level shielded grunt will not block as often as a high level one, and a low level archer will not move around as often or as a fast higher level one.
Another cool update I plan on having is that you'll be able to visually identify the rank of a unit via a rank icon below their health bar. This way you'll be able to see which units are higher in rank than others so you can better prioritize your attacks (or know which ones to run from).
Right now I plan on having ten ranks per unit type. As levels progress, you will see a random set of rank 1 through rank MAX, where MAX is the max rank for that level for a certain type of unit. Hypothetically, at level 28 you might see archer units from rank 1-10, but dragon units from 1-3. The max rank per level changes per unit. Hopefully this design approach will provide variety and ensure the difficulty doesn't drastically jump up when a new unit is introduced.
As I work on game units, I'll likely work on finishing the design for how the user summons allied troops. Right now this aspect of the game is lacking some much needed features. The current version has automated code that doesn't allow any control over when units are summoned and of what type.
After I finish integrating and balancing unit rank progression code I'll move on to balancing and costing the skill upgrades. And after this is done I may release the game as BETA along with some new content. Stay tuned!
I've been working on some real cool stuff lately for Bowmaster Winter Storm (Introductory chapter to Bowmaster 2). I'm almost finished with version 0.0.1.7 which should add a bunch of new content (Dragons!) and fix some bugs. Stay tuned for this exciting new update. Soon I'll transition from Alpha to Beta and do a bit more to promote the game. Thanks for the feedback on any bugs you find. I'll do my best to fix them. Just a reminder... the game is not balanced yet. Right now I'm focusing on overall stability of the game so feedback on balancing issues should be deferred until after you've played the beta or final version.
Wow it's been a while since my last post. And yes I do remember the quiet announcement. Just to remind people, winter doesn't really end until March 20 ;) But today is your lucky day because I've decided to release Winter Storm sometime this weekend. I can't say when exactly but this is how it will be released... It's kind of a new approach so pay attention. The game "Winter Storm" will be released as an exclusive "Alpha" site-locked to my website. This means you'll only be able to play it on my site. The reason for it is because it's still a work in progress. So what's an alpha? It's like a beta but the code is even more... fresh per se. I'll give more details and disclaimers when I post the game which will be here. After I post it, I will continue to update it most likely on a weekly basis, adding new features and content while fixing bugs and balance issues. Now go tell all your friends about it and Stay tuned!
I'm quietly announcing "Bowmaster: Winter Storm" to you right now. It will be released this winter as a introduction episode to Bowmaster 2. There will be two modes of play: Story mode and Arcade mode. Story mode will have a set of levels with specific objectives. You'll upgrade in a way that is similar to Bowmaster Prelude. Arcade mode will allow you to fight a never ending battle with all of the available skills already acquired and upgraded and the goal is to last as long as you can as the difficulty slightly increases.
Our Hero has added a tower to his property just in case :)
The purpose of this episode is to let people see first hand many of the features that Bowmaster 2 will have. Hopefully it will also enable me to improve the quality of Bowmaster 2 through user feedback from Winter Storm while renewing interest in the Bowmaster saga.
Creating a smaller full project like this has also really got me focused and motivated. Among all of the normal holiday madness, I've been working on a lot of fun stuff like animation, graphics, and AI code. I'm super committed to finishing Winter Storm soon so stay tuned for more news.
Election madness. Economy madness. Bowmaster madness. It's been pretty crazy these last few weeks. I just want to reassure you that I'm still in business. And as a thank you for your continued support I have released a new game which you can also download FOR FREE! Yes, you do not have to pay money. It's probably one of the most economical things you can do right about now.
Check out my new space game.
Since this is the devlog after all, I'd like to tell you about some of the cool features implemented in the game. For starters, you can see that it's similar to the background space battle on my main page. This was really at first just a tech-demo prototype for camera focusing/panning. What you didn't see in that version is the ability to instantiate multiple cameras! ... it's exciting, trust me. What I mean by this is that there can be any number of views of the same game world. For example, in the game, you see your top down view and a symbolic radar view, but I've created a generic view system that allows me to make any number of views I want.
This was an exercise in the Model-View-Controler design pattern. Essentially the game logic works completely independently from the views that exist. I could create no views, and the game will run perfectly in memory (including all of the collision detections). I accomplished this by using my own bounding box collision detection system and relied only on MovieClip functions when updating registered camera views. Check out a demo below of a single battle being viewed from three different cameras. The bottom right camera uses a "low detail" mode and stays focused on a fixed position.
Yes I'm still working on Bowmaster 2. Most of these past few weeks have been spent working on Bowmaster 2. I just can't show you anything since most of the work has been on the main build (no little demos or animations to show).
Specifically I've been working on integrating the bomb effect code and debugging how units react to getting hit with blast waves. It's working well with my current damage system, as I'm able to give explosions specific elemental attributes (e.g. frost bomb).
Another cool feature I've been developing is context-specific death animations. So no more generic death animation. Units death animations may change depending on how they died. For example, I currently have code that can freeze a unit mid animation -- it looks like it is covered in ice cubes. You can then hit the frozen unit with an arrow and it will crumble into many ice chunks. Or my favorite animation so far is if you freeze a unit while he's in the air, when he hits the ground he explodes into many ice shards. I also have code for "slice in half" animation which shows a cross section of the unit with bones and 'redness'. The graphics are still pretty toony, so it looks more like a ham being sliced in half, but the effect is still pretty cool.
Here's a demo of how BM2 explosions are going to work. It's slightly different from previous game explosions. In the past, I used instantaneous explosions that inflict all enemies within the blast radius. This demo shows how in BM2 explosions expand out in real time and only do damage as enemies are hit by the shock wave. This demo shows simplified graphics and the explosions rates may vary in the final release of the game (here you see slow shock wave expansion rates).
Another feature demonstrated here is the concept of blast resistance. In this demo, notice the red and gray bars under each soldier. The red indicates health and the bar indicates blast resistance. Soldiers with a low blast resistance value are more likely to be flown into the air from a shock wave. This doesn't necessarily mean that units with low blast resistance take more damage. Damage is calculated as a function of other factors.
The new ability to launch enemies using explosive abilities adds a new level of strategy. In Prelude, explosions just inflicted damage, but with BM2 explosions can be used to delay the approach of certain units by knocking them back.
Click anywhere on the screen to create an expanding explosion.
I’m making great progress with the upgrade shop. I’m working on an info-box popup that shows important information about the skills available to you in the shop. All you need to do is mouse over the upgrade icons and lots of useful information will be displayed about that skill. For example, the info-box will tell you if you have enough gold to purchase a skill if you don’t already know it. If the skill is a bow-shooting skill, it will display the stats of the arrow that is shot when using this skill. The info box will work similar to the mouse-follow text in Cupid’s Revenge upgrade shop, but it will be much more detailed. Compared to Prelude, this design approach is much more intuitive and frees up screen real estate for more upgrades! Prelude’s upgrade window just had a huge text field at the bottom of the page which worked fine for that game, but this new method allows you to read information closer to where you’re pointing the mouse. The info-box text will also be color coded so you’ll be able to make visual associations about what elemental/magical attributes certain skills have.
While implementing the upgrade menu I was thinking about how the game should handle skill rank increases (leveling-up skill ranks). In Prelude, the rank of the skill was determined purely by xp which was awarded by repetitively using the skill. I’m thinking instead of depending solely on this approach, I would allow skills to be upgraded even after they are purchased from the upgrade window. For example, prior to having Fire Arrow, when mousing over the Fire Arrow icon you’ll see the info box say “Fire Arrow available for purchase for N gold” and after purchasing that skill the info-box will say “Fire Arrow Rank 1. You can upgrade this skill to Rank 2 for N gold.” I like the idea of upgrading ranks using gold. I haven’t decided if I want to use this method only and do away with individual skill rank increases via xp. This is a balancing/design decision. It might be cool to have both methods available, so if you want to increase skill ranks by earning xp you can do that to save gold, but if you have a lot of gold and want to quickly become an expert Fire Arrow shooter you could do that too at a certain cost. It just wouldn’t be a good idea for you to purchase the skill rank increase if you’re just a few xp away from leveling up for free.
In the process of making colorful pretty looking text, I’ve also been formalizing the developer documentation for adding skills to the game. To review, a “skill” is anything that you can purchase from the upgrade menu. This can be anything from passive abilities like health bonuses to bow shooting skills (e.g. fire arrow). The process for adding basic bow-shooting skills is quite simple so it’s been fun creating new types of arrows for you to shoot. I can literally create a new type of arrow in fifteen minutes with just a few lines of code and some new graphics. Some of the more advance arrows, like the ones that have special spell summoning abilities (e.g. chain lightning) will require more time to integrate, but I’m pretty happy with the design so far.
My next steps are to formalize the developer documentation for adding non-shooting skill upgrades like passive skills (e.g. faster cooldown times, faster mana regeneration rate, etc.) and instant cast abilities like unit summoning. I’ve been focusing on skills that shoot stuff, so these other types of upgrades will require some new code.
-Jason
Q: Developer Documentation…What do you mean by this Jason?
A: This is documentation that outlines procedural steps for maintaining the integrity of the code while adding a new feature to the game. For example I have a document called “Skill Adding.” Such documentation helps ensure that I don’t miss important steps. There’s a lot of code in this game, and I’m just one dude making it all, so sometimes I forget why I coded something the way I did. Writing this stuff down is just a way to remind myself how this crazy game works. You, the game player, will never get to see this documentation (because it’s top secret of course) but just know that the game will be super cool because I’m using a formal maintenance process to keep Bowmaster 2 in the best shape it can be! A bonus feature about having good documentation is that I’ll be able to easily add new features long after the game is released even if I’ve forgotten how to program. Yay for documentation!
Lately I’ve been working on the action bar user interface, skill book, and user profile saving system. The saving system will work similarly to Bowmaster Prelude in that data is stored to your computer via Flash Shared Objects. I’ve currently finished integrating code that automatically saves the user’s action bar configuration. This may sound exactly how Prelude worked, but there are new features to BM2 that required some extra programming. For example, since your skills may have skill-modifications (mods: rapid fire, multi shot, no-grav), the game saves what current mod is selected for each skill. So when you use quick keys to switch between multi fire arrow, and rapid fire ice arrow, the system will know to activate the active mod when switching between the fire and ice arrows (instead of defaulting to single shot). I’m working tirelessly to ensure the new action bar user interface is as intuitive and useful as possible.
I’ve also played around with some new unit animation techniques. For example I’m planning on having multiple death sequences for the same unit. Depending on how the unit dies, there may be unique animation specific to that situation. I’m still researching the complexity of implementing the types of animations I want, but chances are I’ll have more than just a single death animation per unit.
With the action bar, skill book user interface, and profile saving systems nearly complete I’m now starting on code for the Skill Upgrade Shop. What’s different about this shop compared to Prelude is that there will be certain preconditions that you’ll need to meet before you can purchase certain types of skills. For example, in order to have access to Skill D, you’ll need Skills A, B, and C and with at least hero rank 5. So now it’s not just about how much gold you have. Skill preconditions will add an element of strategy to the game. The precondition system is similar to the tech-tree systems found in Diablo or WoW.
Another cool feature of the upgrade shop is that I plan on having more than just bow shooting and troop building skills available for purchase. Now you’ll be able to purchase such upgrades as hero-stat bonuses and castle upgrades (e.g. hit point increase). My current skill system allows for endless possibilities – I could create a perk that when purchased makes it so that any time a demon dies it summons a cloud that rains bunnies… but I’ll have to defer the decision to implement that feature until after I’ve completed all the main game systems ;) There’s also a ton of game-balancing work that will result from creating all of the upgrades and perks so I make no promises as to what they will be just yet (the bunny-cloud perk might be too powerful).
I’m making good progress these days. Every day I get one step closer to completion. Right now I’m in what might be considered the “boring” phase (I find it interesting… but it’s hard to explain multidimensional arrays and event listeners in an exciting way). This means that I’m working on a lot of the behind the scenes code that make the game work. E.g. windows management, memory management, physics, maintenance documentation, system testing, etc… I’m closer than ever before to completing this phase.
The next phase is content creation which is where I switch modes from “application designer” to “game designer.” Content creation means I start using the existing framework developed during the application development phase (game engine) as the tool for making the complete game.
This involves such tasks as:
Upgrade creation
Spell creation
Final AI programming
Graphics, animation and sound integration
Level design and game pacing
Game testing and balancing
The content creation phase is where I spend as much time playing the game as I spend developing. This phase is where I have the most fun developing too. I’m so excited to be so close to this phase because there are so many new features that the BM2 engine supports. Particularly, the collision detection system I’ve created allows for the most precise detection I’ve ever created for a projectile based game (In my Test Battle, notice how shielded units can block, but they are still vulnerable at their exposed regions). This system alone will enable me to create some very interesting enemies.
My elemental system is new an improved when compared to features in my other games. Having elemental magic is a common theme among many of my games, but BM2 has the most sophisticated elemental system of all of them. And my intention is not to make game players have to memorize a complex fantasy periodic table of elements. The true purpose of the system is to allow for new types of spells and attacks. Certain spells and abilities the player can use will be unique to a certain type of magic and will act completely differently than other spells. “Chain Lighting” is way different than “Poison Plague” which is way different than “Flame Wave.”
Of course there will be enemies that have elemental weaknesses and strengths, but I will not severely punish players for making the wrong choices. Obviously an ice arrow will do less damage to an ice golem but rather than result in no damage, the other attributes of the projectile will come into play. For example, if a huge comet hits a tiny ice resistant frog, it makes no sense to have the frog go unscathed – the frog should go splat from the brute physical force of the comet. My damage system considers both physical and magical attributes between the two colliding objects and determines what sort of reaction will result.
I could go on and on about the features in the current game engine, but I won’t. Just know that I’m excited to start the next phase. Most of my other game development projects were like hand crafted clay pots – fun to make but difficult to modify. For BM2 I’m using a different design approach… It’s more like a Mr. Potato Head*. I spent all this time making the parts (sometimes I even slapped them together for demo purposes). I have a general idea what the final product is going to look like. And most importantly, it will be easy for me to make adjustments. I can’t wait to start playing with my new toy… but not before I clean my room.
Thanks for your patience. Stay tuned for more news.
-Jason
* Google Image search “Mr. Potato Head” if you’re not familiar with that toy. You may remember him from Pixar’s Toy Story.
It's been a busy past couple of weeks for me lately. I went to two family reunions, went on vacation with my fiancee, visited with my brother who came back from Japan for for a week, and hosted a crazy LAN party... all while actually being quite productive on BM2.
So I don't have any cool new demo for you guys but I want to let you know what I've been working on and give you some more details about how skills/upgrades will work in the game.
Currently I've been finishing up the Saved Game Profile system that works similar to Bowmaster Prelude. I redesigned the code from the ground up to meet the needs of the exciting new skills/upgrades system in BM2. The skills system is currently being developed and I'm making great progress on the front end user-interface design of the action bar and skill book. If you've played World of Warcraft you'll notice a similar design.
In Prelude you had a user interface that allowed you to setup your action bars with skills using a window that showed all of your action bar rows along with all of your available skills. You could drag and drop skill icons into the action bars you wanted them to be in and then when you exited to the game window you would see the changes reflected in your lower action bar. The current issue with that method for BM2 is that I plan on having so many skills available for the player to use that they may not all fit on a single page...
The way it works in BM2 is similar but way more intuitive and allows for many more skills. Now you have a skill book that is tabulated by elemental type (e.g. fire, ice, light, dark, etc.). While in the game you simply click on your skill book button to bring up the skill book while in game. Clicking on a skill book tab will show you the available action-skills that are available for you to use in your lower action bar. There are other miscellaneous tabs for other stats too, but for now I'll focus on the skills and action bar.
Using the skill book you can drag and drop action-skills to the action bar. You can also drag action-skills from one spot on the action bar to another and easily swap two action skills (e.g. place ice arrow that is in spot 1 at spot 4 where fire arrow is, now fire arrow is in spot 1 and ice arrow is in spot 4).
Perhaps the most interesting thing about my planned design is not the action skills alone (e.g. fire arrow, ice arrow) but the ability to purchase modification upgrades. For example, every profile will start with at least the basic arrow skill. A skill modification would be something like "multi shot". You've seen something like this before in Bowmaster 1 where you could upgrade how many arrows of a specific type you could shoot. Now I plan on having other interesting skill-mods, and the ability to purchase them for all sorts of different skills opens up several combinations of upgrade configurations...
So just to re-cap, I have several base elements in the game... Fire, Ice, Wind, Earth, etc...
Every element has a basic arrow type skill.... fire arrow, ice arrow, etc. These skills start off with the ability to fire a single shot at a time. With the new mod system, you can purchase abilities that will be applied to a specific skill.
Here's a few of the skill mods:
Multi Shot: Allows you to shoot two or more of a type of projectile at once in an even spread.
Rapid Shot: Allows you fire multiple projectiles at the specified angle and velocity.
Power Shot: Allows you to fire a stronger version of the projectile. The shot has a delay and will be fired at the angle you specified when you released the bow.
Homing: The projectile will have the ability to home in on a specific target.
No Gravity: The projectile will not be affected by gravity.
You'll be able to purchase several mods for the same projectile type. E.g. your fire arrow can have multi-shot and rapid-shot, while your ice arrow can have rapid shot, homing, and no-gravity mods.
Mods will also have a rank level (that increases through through repeated use or by purchasing upgrades). So rank 1 multi shot will start you off with two arrows per shot, and with each increase in rank you will be able to shoot more of that projectile. The affects of increased mod rank will depend on the mod type. A low rank homing mod will just not be able to turn the projectile as fast as a high rank homing mod.
Note that not all skills will have access to all possible skill mods. I'll be making sure nothing gets too overpowered. And to do this, I'll be adding an element not seen in previous Bowmaster games: Mana/Energy. Skills will still have cooldowns like in Prelude but now certain abilities will require that you have enough energy in your mana pool to perform them. The use of mana will add a new element of strategy to the game. I promise to balance this element so that it doesn't seem restrictive -- Mana resources just need to be considered when you ask yourself, "should I use Fire Storm or Ice Storm?"-- in Prelude, as long as both cooldowns weren't counting down, you could use both one after the other.
The skill mods for each skill will be displayed just above the skill action bar. When you select a skill in the action bar to activate it, you'll see the list of skill mods available for that skill. All projectile skills will have the single-shot "mod" listed first, and all additionally acquired mods will be displayed after it.
Figure 1: Basic Arrow, Single Shot Mod Selected
Figure 2: Skill in Button 2 Selected, Multi-Shot Mod Available
Figure 3: Skill in Button 3 Selected, Rapid-Shot and No-Grav Mods Available
Check it out. First ever BM2 interactive demo. Note: this is just a demo of a small set of features that the overall game may have. If you find any bugs please let me know. Enjoy!
Check it out now. Funk soul brotha. There's a lot I can say about this demo but I'll just let you figure it out for yourself. Enjoy. (NOTE: this is just a few of the many features of Bowmaster 2).
Here are two tech demos for some new features I've been working on for Bowmaster 2. The first is circle vs line segment collision detections. I know I talk a lot about
collision detection but it's not a simple topic. In this example I show how a line segment can intersect with a circle. Just drag the red and green dots around to see where the intersections occur. The code for this demo is useful for determining fast moving projectile collisions against circular objects.
This next demo demonstrates a constant (stackable) "aura" effect.
Imagine a defensive boost aura similar to something found
in World of Warcraft. All the party members within a certain proximity of the aura provider are given a bonus. In BM2 you might see "commander" or "elite" type units that give off auras that boost stats of allied units. You'll likely want to take down these units first to make weaken the overall strength of the enemy army.
I've been working on some new unit animations for Bowmaster 2. I created animations for a catapult (different than the trebuchet -- it will be similar but I plan on having different ammo options for it) and a ballista weapon which will shoot heavy spear-like ballista bolts that do massive pierce damage. I also created a new unit animation for the Lycan unit. Check it out below.
I just posted the game to it's official location. I'll post an official link on the main page in the near future. Let me know if you find any bugs and I'll do my best to fix them. Enjoy :)
I'm almost done with the final boss level. It's coming along nicely and it's a lot more elaborate than the other boss battles. I don't want to spoil so I won't show you any pictures. After I finish the boss which should occur sometime this week, I'll do the very final balancing and finishing touches and then I'll officially release it. After this project is complete I'll be back to focusing more on BM2 and you'll see more devlogs with BM2 updates. Stay tuned!
I've released a near complete version of Moon Master RahKon.
Click here to play. This version includes high locally stored high scores (for each difficulty level). It also fixes some bugs: invisible lasers, your ball keeps moving if you click off screen somewhere.
Right now this high scores are saved, but the scoring may change in the final release and the high scores will be reset. Also, I plan on having a final level with a new (never before seen) boss. Currently, in this version it can go on for ever even after you kill the basic bosses.
As I said I would, I have released a new game. However, I was up late working on the final touches, and since I may still need to balance certain things and further test the game, I decided to release the game as an open beta version. This means I have not yet posted the game into the main game links page. So if you are among the cool fans who read this devlog then you are now rewarded with an exclusive look at the almost complete version of Moon Master: RahKon. Enjoy! Feel free to give me feedback about game difficulty, bugs, features, or whatever you want. I still may be able to adjust the game to fix issues you discover.
Sorry it has been a while since my last post. Despite not reporting anything recently, I have been making good progress on my projects. I recently upgraded my computer in an attempt to make my life easier. Instead it made my life really difficult for two weeks. I finally got everything working now and transferred the important files and installed Flash 9 so now I'm back in business. And boy have I been busy. I am pleased to announce a new game I'm soon to release "MoonMaster: Rock On." It's a mix between Katamari Damacy and my Gun Master. It's a highly modified version of the last AS3 engine demo featured in a previous devlog entry. In this game, You'll take control of a highly maneuverable green rock. Moon rocks are falling out of the sky and threaten to crush you. On top of that there is an alien race that is trying to blast you to bits for some reason (some sort of conspiracy). Luckily you're a special kind of rock that can fire lasers. The game is about 85% complete and I hope to get the last 15% done before the end of the week. However, I may take the next weekend to play test and balance the game before releasing it. The game is fairly simple but it's not just a typical shooting game. It has some interesting gameplay features that add new challenges and strategies that I think you'll like.
And the purpose for making this game is to practice developing with Action Script 3.0 and to get warmed back up for developing robust code for Bowmaster 2.
After making the switch from AS2, I realized there were a lot of things I still needed to practice before I started making more code for Bowmaster 2. Specifically, I discovered that user interactivity was quite a bit different in AS3. In an attempt to practice, I was inspired to make a new game. The code is super ugly looking and I probably won't remember what the heck I was doing two weeks from now, which is why I better finish this side project ASAP before it all implodes into an AS3 blHACK hole.
Action Script 3.0 is making more and more sense as I convert old AS2 code over to the new standard. The code is much cleaner and I can definitely see a performance improvement with my core game engine. This isn't to say I'll be cutting corners though. I'm continually making sure I don't add any "expensive" code or animations that eat up all the CPU. I've successfully converted several of my unit AI and physics code so it's starting to come alive. I feel like Dr. Frankenstein giving life to simple rag-doll flash sprites... they even exhibit some pretty dumb behavior at times ;) but that's all part of the process.
After playing the "Quake: Enemy Territory" demo and having it run slow on my 1 year old computer with low settings, I vowed to do everything in my power to make sure I never release a game that can't run well on a current average computer. For flash, this means making the transition to Action Script 3.0. Bowmaster Prelude's game engine is created entirely in Action Script 2.0. I'm taking this opportunity to create a brand new, highly optimized engine based on the Prelude design but implemented in AS3. Before making this decision I created performance tests to compare the difference between AS2 flash 8 and AS3 flash 9. The difference was quite significant as the AS3 version outperformed the same code and graphics of the AS2 version by up to 5 times the speed.
So what does this mean for Bowmaster 2? With AS3, BM2 will have more targets on the screen, more projectiles flying through the air, more advanced physics using Vector based collision detection (no more arrows passing through things -- unless of course you're using the pierce arrow ;), better animation and graphics, but more importantly BETTER PERFORMANCE FOR EVERYONE!
Check out the demo below to see the power of Flash 9 and AS3! Muahahah...
Specifically, this demo features the new "boulder" collision detection code that can be applied to any spherical object such as catapult ammo, loose boulders, or debris from castle explosions. This demo also features a more advanced projectile collision detection system that can allow arrows to hit targets at ANY speed. See for yourself by clicking anywhere on the screen. A super fast "test" arrow will be fired from the top left corner and will collide with the FIRST object it comes in contact with (be it a boulder, foot soldier, or the ground).
Please note that this is just a demo and not the final game engine. Unit animations, terrains, unit stats/behavior, gravity, projectile speed, background artwork and graphics may appear different in the final game.
I'm currently not bought off by nVidia. You will not see at the beginning of BowMaster 2 an animation that says "nVidia... the way it's meant to be played" and I will not require Window's Vista or Direct X10 to play the game.
The unit AI and animation integration is coming along nicely. I've been running automated tests over night and have been pleased to see that the game continues to run nicely and the unit's are staying smart :). The new game modes are working well too.
You may remember from my ninja demo a few weeks ago I showed new units jumping around the map. That was just a demo, but I successfully created a "ninja" test unit that acts pretty smart. It will jump towards an enemy until it is in range and then walk until it's close enough to attack. When his health is below half, he will jump back in retreat until he has regained more than half of his health back. I also made it so that the ninja can only jump when he has enough energy (separate from health) so he can't just jump all the time. This is just a test unit at the moment, but with my new Animation and AI architectures combined with my improved physics engine, I'm able to implement pretty cool AI behaviors fairly quickly.
Happy Birthday Pat. Below is a dire wolf graphic and animation I created. Check out his majesty. I call him Fang, after my WoW pet (who is almost 3 years old... they grow up so fast). This week I spent a lot of time working on animations such as this (I don't want to spoil the surprise), but I also spent a lot of time with some very important code I've been neglecting... I'm planning on having the next Bowmaster game support multiple game modes (not just Capture the Flag like in Prelude) so in order to do this I had to re-code a lot of the "hard" coded features in the old Prelude code. Codie co decode code. Say that 10 times fast. Basically I was able to create a very nice foundation for supporting multiple game types and unit AI's. For example, in Defend your Castle mode, you need to keep your castle alive and kill all the enemies. The enemy AI will advance towards your base at all costs and they will have no castle on their side. Your AI will defend your castle at all costs, attacking any nearby units, but perhaps staying closer to your castle (exact AI behavior is still being worked out).
Stampede! I'm having a lot of fun pretending to be an animator. As you can see I've improved the horse animation significantly from the original. Animation is a long a tedious process but the end result is cool to look at. It's going to be worth the effort though. I've been working on other animations as well, but that's top secret information. If I tell you I'd have to ... try and convince you not to tell other people.
I've improved the archer animation so that they now aim towards their target. See how the archers adjust their bow angle to try and hit the baby red dragon. I'm using simplified AI for this demo and the arrow physics may differ (gravity and velocity) from the final game.
I spent most of this week working on unexciting documentation and file prep. I am trying to create a "lite" development version of BM2 that doesn't take 7 years to compile. I'll do this by temporarily removing items from the library that aren't being used (such as backgrounds, cutscenes, music etc.)
Check out the new character animations of the stealthy Jonin. Featured here are the Fist, Sai, and Katana Jonin. Notice their amazing mobility; landing arrows in these targets may prove quite challenging. Also watch how they pass off the fire orb artifact as an example of their ability to quickly escape with valuable items. The Jonin have a combination of basic attack moves and a special melee and jump attack. The basic moves cause blunt damage (from fists and feet) and the special attack damage is different for each weapon type. For example, the Katana Jonin's special moves inflicts slice damage whereas the Sai Jonin's inflicts pierce. Your allied troops and structures may be weak or strong against certain types of attacks.
Check out some new and exclusive character animation and background artwork. Feel free to right click and zoom in to get a better look. This is just a sampling of the many types of units I plan on having in BM2.
This week I spent working on revising my requirements documents. Specifically I worked on formally defining the magical elements and weapon types. I also started work on my new damage calculator which should take into effect physical and magical attacks. I'm planning on having basic single arrow types available for all of the magical elements. These arrows you'll be able to fire at a faster rate than the fire and ice arrows in Prelude (almost as fast as normal arrows) but they'll have reduced pierce damage; however, different types of enemies may have certain elemental weaknesses that you can learn to exploit. There will also be a series of upgraded magical arrows as well as class specific magical arrows (and super arrow spells).
Dang it's hot. Not the most fun time to be programming in a room full of heaters (that's what I call my computers). Anyway, despite the weather I've managed to get a lot of work done on the not so fun stuff about making games... optimizing. Well it's kind of fun to see your games perform more efficiently, but at the end of the day, 10 hours can go by and all you have to show for it is the same exact game (hopefully without many extra bugs) but one that runs a bit more smoothly. So unfortunately I don't have any cool new flashy animations or graphics to show off, but I can say that you'll start to see more fun stuff in the coming weeks, so stay tuned. But I did manage to dig up my fireworks demo from last year and integrate it with the main page. Now you can change between the Spaceship Demo, the Plague Demo, and now the Fireworks Demo.
I got a lot done on optimizing the collision detection of arrows against objects. I was trying to get away from using hitTest on the character movie clips and instead use my own BoundingBox class which works with my Vector class. In short, I can now better detect fast moving object collisions so things shouldn't appear to move through things at high speeds. I don't have a demo of this in action, but I did modify my current build of Bow2 by increasing the Hero's bow power along with the gravity. I was just playing around, but the end result felt a lot like the fast moving arrows of BowMaster 1, and there was a greater sense of power when you released a fast moving arrow -- something very satisfying about it. Nothing is definite, this inspired me to seriously consider allowing you to upgrade the bow power like in the original and maybe slightly increase the gravity in this next version so things fall at a more realistic rate (but not too real so you have time to dodge enemy fire if need be ;).
Another thing I've been working on is this "plague" effect that I plan to make implement as part of a new ability, perhaps for the hunter or mage class. I created a non-interactive demo of this just for fun, and the actually implementation in BM2 may vary. To see it click on the green orb at the top right of the main page above.
Just to explain a little about the demo: The blue squares are host cells (pretend they are footsoldiers or something living). The green orbs are virus cells that feed off of the host cells while slowly killing them. Then just for the heck of it I added some medicine cells which heal host cells and kill virus cells.
The cool thing about the ball particle is that it can be used for many new types of weapons, spells or other reactive environmental effects. For example, imaging a boulder placed at the top of the hill. Perhaps you might be able to dislodge it with a well place bomb arrow, sending it rolling down the hill crushing all the ground troops in its path.
I've implemented it so I can adjust the bounciness and friction levels of the ball and surface the ball collides with. This alows me to simulate very different particles using the same code (e.g. boulder on grass, vs boulder on sand, or rubber ball on grass etc.)
Test Boulder Rolling (meteor graphic)
The other new technology I added is the effect the terrain has on ground unit speed. Ground units now travel relatively faster when moving downhill and relatively slower when going uphill. The amount of boost or slowdown is proportianl to the steapness of the terrain. Click on the image below to see a sequence of screenshots that kind of demonstrate this. It probably would've been more obvious if I used only one type of unit in this example, but I didn't have time to do this just for this demo.
New and Exclusive Bowmaster 2 Character Artwork! This picture shows you the three playable character classes in BowMaster 2. Each class will have special unique abilities that help them defeat their enemies. The big dude on the right is an expert in demolitions and heavy siege weaponry. The lady in the middle is a mage with fierce magical attacks. The young lad on the left is a cunning hunter and expert marksman.
Bowmaster 2 Character Artwork
The skill upgrades available in BowMaster prelude will, for the most part, all be available in BowMaster 2. Several of the common skills will be shared among all three classes, but each class will have new skills and perhaps attribute enhancements for some of the common weapons (e.g. the mage may get a bonus to ice and fire arrows, while the demolitions dude may get a bonus to the bomb arrow, even though both classes may use these abilities).
It's been a busy week, but I managed to work on a few things in my free time. I worked on an animation for a battle mage unit for BowMaster 2 (seen below). I worked on illustrating another background for BowMaster 2 but I can't show you because it's top secret ;). I also was toying around with a zombie game idea I had. I'm only releasing this early screenshot now, but I may have a non-interactive demo in the near future. Oh and a few were confused about the previous week's update, those screenshots were of BowMaster 2 which has not yet been released.
This week I've implemented two new skills to Bowmaster: Rapid Shot and the Chain Lighting. See the screenshots below for examples.
Chain Lighting causes bolts of lightning to stream from enemy to enemy, causing lighting damage. This is useful for damaging enemy troops
that are spread out along the terrain or in the air. There is some randomness in how each bolt jumps from one enemy to the next, but for the most
part they choose whatever enemies are closest and within range. Right now the arrow needs to be detonated like the flak bomb.
Rapid Shot causes several arrows to be shot in succession at the angle and velocity you choose. The arrows are shot out at slightly different
angles than you original shot.
I updated the space background with the ability to zoom in and out using -/= keys. You can also cycle through the ships with left or right arrow keys. You can now also aim and shoot the turrets of the Destroyers (medium sized single turret ships) using the mouse. The motherships now have Devastator Laser Cannon in addition to their four turrets.
This week I spent time working on the "multi-shot" arrow which works like the original BowMaster. Also I've been optimizing the code and fixing some bugs. I may post an update to the original Prelude to fix some of these minor issues.
I have been playing with new backgrounds and graphics. I made a multi-fire-arrow and cranked up the max arrows. I was in the desert scene and it looked really cool with ground littered with dancing flames. I might just feature something similar in the final release. Take a look at this exclusive screenshot.
prelude desert
With respect to the space game, I already have code developed for manually piloting the small fighter units. You can fly around with the WASD or arrow keys, shoot lasers and homing missiles. You can target enemies. I plan to have mines and flares too. Mines you can drop behind you and flares will distract enemy rockets that are fired at you. Currently the enemies only fire lasers dots.
And the last thing I worked on today before posting this was the ability to control the Medium sized ships turrets. I may post an updated version of the background demo so you can play with it. You can't control the ship and where it flies, just where it shoots. It's kind of fun just playing as the gunner, trying to take out the fast moving small ships as they whiz by. Kinda feels like being in the Millennium Falcon shooting down ties (in a more simplified 2D environment ;)
What is the DevLog? It's shall be a journal for the progress
of my current projects. I'm not sure how often I'll update
it, but the goal is to keep me in the habit frequently updating
my site.
Lately I've been working on updates to BowMaster Prelude.
I have a really great artist helping me with the project
and the end result will be really special. I may release
some new screenshots when I'm closer to release.
I've also been working on a space game on the side. I may
release it relatively soon actually so stay tuned for that.
I need to focus on BowMaster, but this space game is so
much fun to program... I've never done a true "scrolling"
game before so it's been an interesting challenge.
Back to BowMaster... I watched the Movie 300 again this
weekend (probably the last weekend it's on the big screen,
now that Spider Man's here). That movie made me want to
make a Spartan-like unit with Phalanx squad AI (of some
sort). I love how they alternated attacks between blocking
and spear thrusting. We'll see.
