This week Bard to Death hit a bit of a dead spot this week due to employment shifts. I just put 30 minutes worth of time into the game to add some more of Jay Jay’s sounds. Last week however, we managed to get a laundry list of things done. I know I am going to leave something out because it’s not fresh on my mind, but here goes.

New in version 0.2:

• Animated character
• Animated monster
• Menu sounds
• Equipable character (weapon only)
• Equipped items change character (weapon only)
• Random barrel loot (only 2 items right now)
• Load screen
• Smarter AI
• Lots of bug fixes

The next update should be in two or three weeks, give or take five. I just landed a much needed job doing php development and currently have my feet in both jobs right now. Once I am back to only one job work will resume and I hope we can keep this pace going from there on out.

Play the alpha demo of Bard To Death.

When my friend Justin “JayJay” Johnson asked me if I was interested in doing a joint project I couldn’t turn him down. We both think very much on the same wave lengths when it comes to creativity, and we tend to push each other well. We were originally discussing the previously announced project code named “Goat Cheese”, when we decided to step back a little more and make a game that we could finish in a reasonable amount of time.

Bard To Death is a semi-humorous take on rogue-likes. The story and a lot of the interactions with the game world are geared toward being humorous while at the same time attempting to present a very real challenge. One of my personal goals with this is to ease the difficulty a bit more than the originals without loosing that feeling of desperation they tend to inflict upon you.

At this point we are a litte over two weeks into development. JayJay hammered out some sounds and we went back and forth taylor fitting them into the game in an attempt to publish this young preview. We had some good laughs and I was really disappointed that I couldn’t add more of his sounds at the moment. Hopefully in the next few weeks I can share more of these with you.

On my end I whipped up some simple models and pulled in the camera and player controls from Aeges Road and taylored them to fit the new game play style. The rest was whipped up in short order. There are a few bugs left in the dungeon generation code, but none that should cause computer trouble, you may find out what I am talking about as you play the game. It is also far from optimized, so I would probably recoment a 2Ghz processor or better, my 1.3Ghz Athlon XP choked on it.

I am very exited about this project. The sound detail is amazing and the code is flexible enough not only to get the rest of the content whipped up quickly, but will also serve as the base code of future RPG and rogue-likes coming from CodeUgly.com.

OK, after doing a ton of AI work in the old Aeges Road I was thrown a curve that just said opportunity. I had been trying to save up for and justify Unity3d for over a year or so, but hadn’t quite convinced myself that I could finish a game any faster in 3d rather than sticking with 2d isometric. Development speed has yet to see an increase, but art speed is amazingly faster, one of the major hang-ups with the original Aeges Road demo. So I am going to introduce the game and show a few early screenshots of this revamped RPG/SRPG hybrid.

The Visual Stuff

In the editor

This first shot is just an editor shot showing a bit of the progress so far. This is my first time actually working with C# and I was pleasantly surprised at just how java-like this language is. I am also doing a few of the scripts in javascript which breaks up the monotony a bit. But I have spent only half my time scripting, and most of it playing with art to come up with this style of level design. If I were doing this in 2d, and this is in no way an insult to my former engine, I would have never gotten it to look like this without hiring an artist. The art reality of this project is what basically sent me looking for another project to complete in the first place, but art has been easy so far in 3d.

Approaching a bunch of angry looking pinkies.

I debated a bit, and tested both perspective and orthographic projections for the game. If anyone has ever followed any of my development blogs you will know I prefer a 2d style of graphics and game play, so naturally I found orthographic to be more appealing for my purposes. I also played around a bit with some detail mapping, but none of it has fit with the overall graphics scheme yet. Another complaint I commonly have in 3d games is the amount of work a camera makes you do in order to play the game in a 3rd person perspective. So rather than leaving the camera free, I did something similar to Final Fantasy Tactics and Jeane De Arc, and gave the camera 4 snap positions rotating around the characters. There are a few areas in a map where this is not good enough, so I also added some “peek” functionality where you can sort-of peek around the corner.

Peeking around the corner

I still do not have a fully animated character, only 8-13 animations exist so far and I am currently trying to finish the design doc before adding the final animations and creating more characters. I am using Cheetah 3d so character animations are a breeze right now. I tried IK’s once, and liked them to a point, but I was constantly spending hours ironing out the fine details of joint constraints just to watch two identical joints behave completely different. It was too much for my brain, so I decided to go back again and animate them using simple keyframing. A lot of these animations already existed, and I was able to add two swimming animations in less than 20 minutes. In my first rough level design test I did have swimming, I just haven’t designed a water area yet in the new design style.

Shot showing combat grid.

Finally on the art side of things, I got the grid projection working. I am still trying to refine the look, but if history repeats itself I will be doing this until I ship the product. But I have noticed playing games that a grid is hard to mess up visually. Usually the biggest complaints of a grid is that it gives too little feedback on attacks and movement. While I don’t plan on making pretty little arrows that show the path chosen, I do plan on highlighting ranges and effect areas. Highlighting, range finding, and path finding are coming up real soon on the todo list. There is also the topic of slopes, and the debate on whether or not the characters should be able to jump off cliffs or not. Personally I would like to tighten up movement and reject death defying stunts, but then I get into the debate of jumping onto things being a cool exploration element. I imagine I would be better off waiting until after I have play tested combat and exploration before making a final decision.

Fun With Math

Early graphics

RPG rules are a lot of fun to play with. I have several design docs where all I have done is play with stats and rules. The original Aeges Road rule set was a bit hard to test and design. What it lacked was an easy way to write things out then go hack it out, and it used a very advanced TOHIT/Defense forumla that was hard to balance and made huge gaps in stat levels and gameplay. So, every since the game in a year contest ended, I have been studying PnP rules from several different systems and looking into ways of making my game PnP accessible. Now, if I am not missing a design doc, this game marks my fourth stab at a PnP RPG system. Each time I learn something and I have been trying to boil it all down into something that is just as simple as it is advanced.

Earily swim graphics.

On my first stab I just went free for all. No hard rules, just something I could test paper. This game never balanced out. The second game I decided to do in a GURPs mentality and only use 6 sided dice. It almost balanced, and the third set of rules was more or less a major revision of the second. But the third set of rules didn’t really work with this project, but worked well with a modern combat RPG I had partially wrote up a year ago, so it actually found a home.

Finally, the fourth PnP set, still in development, is based on a single D6. No roll at any point in this game should ever need anthing but a single D6. I am sure this has been done somewhere, and really it is not that stellar an idea, just a natural evolution sort of thing. I am sure D&D players are all saying “Hell No” right now, but the ease of development this affords me is gold.

Sample weapon and damage

The idea for damage is quite simple. Each weapon has a set number of attacks available for it. Each type of attack has 6 different summed damages based on the extent of a dice roll minus the stat level below proficiency. Armor is quite the same, with the exception that padding is not summed up, it rolls to static values. For those who simply want the quick basics, it is as simple as 6-14 damage, and for those who want to get into the details and risk management there are plenty of numbers to crunch. I might also abstract weapons from attack types in order to offer more flexibility and faster development. It might also be fun to abstract special attack types to skills or perks.

Other Projects

I did a long post because it may be a while before I post another. There are a few other projects I am trying to co-develope. One is finally getting around to marketting my iPhone game. The game release was chaotic and due to the appstores sporatic approval system my game immediately started at the bottom of the pile effictively killing my original marketting plan. I am also job hunting, so I have considered doing an AJAX version of my PnP system as part of my resume. Finally, I need to do something with this wordpress template. I like the look of the site, but I would rather customize it to look more like one of my old templates.

For a couple years now I have been working on programming an RPG. I started out with one idea which I ran with for a year before realizing I would never complete it with my current schedule. So I tried to simplify everything and start anew, but that RPG quickly got large and out of hand as well. I then jumped onto an iPhone project and finally finished a game, then finished a side scrolling RPG for a competition, then came back and made another RPG combat engine prototype which I am holding onto for a rainy day.

So now I have several partial RPG’s, including one half started 3d game (need more cash first) and no more college waiting on a degree so I can job hunt. So after running aground financially on 3D I decided to review my old design docs and decide on a way to mix them up and finish an RPG. I am still finalizing the design doc and prototyping a bit and getting pretty close to having something that looks fairly impressive. I am also toying with the idea of teaming up with an artist and a sound and music person. I was always hesitant to drag someone onboard before due to my inexperience, but I have learned a great deal over the last two years and feel much more confident in what I can do. And with college no longer a time factor I have been able to accomplish in a week what took me a month and a half in the first competition.

This week RPGDX a 48 hour competion to build a side scrolling RPG. Unable to stop myself I decided to make an entry, Already Dead. Download it it here for macintosh and windows! I will write more on a later post this week. So for now, have fun and leave comments. thanks.

I have been extremely busy. College, work, engines, spammers, rootkits, kids, cars, planes, family, church, and raccoons. Now, for the last 4 weekends I have thought that it would finally be the weekend I turned my game in to Apple for approval, and things just keep getting in the way. This looked like a killer week for it at first, but I have been getting calls and more work work is piling up. I avoided blogging mostly to get more programming done, but also because I needed to take care of a few website problems first, and they are still being worked on so please be patient.

So check back in a week or two and I just might have an announcement of a finalized game. After release I intend to make sure it is stable for a few months before moving on to my next side project. I am still dabbling with The Soldred Kingdom, but I wouldn’t doubt it if I finish several games before it gets finished.

So thanks to everyone who checks out this site from time to time, it is greatly appreciated. Hopefully in the next few weeks I will have comments and the forum re-enabled.

At long last, some more screen shots! As I wrote earlier I have started a side project and am currently working toward an iPhone game. After much debate and a lot of test coding and graphics I decided that the Soldred Kingdom is a better fit on the PC. I believe I will do an iPhone RPG sometime in the distant future, but for now I am going to finish Soldred and see where this new action on the iPhone goes. So, I kicked things back off this week on Soldred and with a rejuvenated step got some things accomplished.

The biggest gaping hole in this RPG is artwork at the moment, so that is what I have been concentrating on. The tiles were drab, the levels were drab and was just getting frustrating. But I finally took a look at some older games such as Popolo Croise and realised a few places I was skimping and didn’t even notice. Grass tile transitions are pretty dull it you don’t take the time and mix them up a bit, and one transition tile per type and direction simply does not cut it. Variety is the key ingredient.

I also spent some time on trees and other objects. I like shadows for the trees, but forested areas seemed to suffer from having one shadow on top of the next, so I decided that it might be better to leave things as they were in the dense areas and use tree shadows only for trees in the clearing. So to flavor up the forest floor I decided that adding underbrush might have a good visual effect by giving the appearance of dense and impassable.

There is also some UI artwork done, but that is for a later blog. The goal of the stats system is to make a complex game as simple as possible. Basically I am shooting for low numbers with only a handful of stats and several skills to complement. That’s all for now, short and sweet.

For some time now I have been watching the community at Garage Games slowly get bled back behind the pages of what seems to be a lot of commercial back scratching. I am constantly reading articles about raising the prices and fan hype cheering them on saying indies can afford it. This immediately says to me that existing users feel threatened by the competition. Just look at the casual games market, it is overpopulated and finding a good title now takes quite a bit of digging.

Now a bit more of my history, interests and lessons learned. I have always hailed the era of DOS-Win9x and SNES as the greatest era in gaming history. That era on those platforms rendered more games that stole away many worthwhile hours of my life. Now the handheld platforms are picking up where they left off and once again I playing games that I feel are worth my time. I had originally pictured Aeges Road a DS game until I priced it. While the graphics aren’t’ by todays standards great, I still find them appealing and acceptable, some times even better than some of today’s graphics. IGN my think Chrono Trigger for the DS should have been 3D, but I beg to differ that point. When I started my project I was of the mind that 800×600 would be just fine for an indie, but after reading some reviews for Eschalon Book I, my confidence faded quickly as I realized I was going to have trouble getting the right details in a 128×128 animated sprite.

Then came along the iPhone. At first I never payed it any attention due to its NDA knowing full well tutorials and instruction were going to be expensive to get to. But low and behold they dropped the NDA as well as the up front charge and simply charge 30% on every sale, very cool! At that point I knew the iPhone needed to be my target platform as I was still struggling with the graphics after nearly two years of working on them. Unfortunately, the development tools I use decided to tag on an expensive up front cost to dive into iPhone development. For about a month now I have been trying to justify paying the price for iPhone development, but the bottom line is, the cash isn’t there and this indie can’t afford it.

I really became discontent and this post at Rampant Games didn’t exactly help me find complacency.So I spent a while looking into alternatives. I am at the end of my Unity demo, and was able to do some cool stuff just playing with it, but Unity is too expensive to get to the iPhone as well. It wasn’t until last Thursday that I began reading forum posts at iDevGames looking for a good way to start from scratch when I stumbled upon this post. There are currently three open source iPhone engine projects, two of which I am looking to use.

SIO2 is a very cool 3D engine for the iPhone that uses blender for level editing! I already know blender, and C is not a far cry from C++, in fact, it is sometimes easier to figure out what is going on quickly when it is C rather than C++. I have been frustrated with isometric tools and have been debating going 3D with The Soldred Kingdom back when it was still Aeges Road. I have always had a vision in my mind of how I wanted it, and even had a jogl prototype and java3d level editor partially working at one point. With blender being the level editor, I can see this being fairly easy to implement.

Cocos2D is just neat, and it gave me an excuse to do something I have wanted to do since I bought a mac, learn Objective-C. I bought the Aaron Hillegass book as suggested on iDev and I love it. I will go as far as to say I think I like Objective-C better than I like Java, and I really like programming in Java. Once I get done with the book I think I am going to update my Guru account and put this as an available skill, sadly I turned a Cocoa contract down last year due to inexperience. But back to Cocos2D. Cocos2D was and is still a python game engine, thus making it cross platform compatible which would gain for me Linux, a target quickly lost with my old tools. Cocos2D was ported to Objective-C for the purpose of iPhone development. Most of the tools associated with Cocos2D, including the level editor, are in python. I played with it a bit, and I was impressed with how small everything is.

Both projects have a lot of tools built in including physics(!!), and they are open source to boot. The iPhone has a smaller resolution making graphics much easier for me to work with, and oddly enough comforming to many of my original visions for the games. After I get all of my tools and SDK’s downloaded (which will take a while) I will be starting with Cosos2D to get my smaller project (which will be shown off soon hopefully) off the ground. I was able to make it functional with 2 fully playable levels in TGB in 12 hours, so I am shooting for 36 hours given my unfamiliarity with the tools, engine and language (granted I had never used more than basic physics in TGB before either). Finally, what is really cool is that I can show all the code on my blog I want as I hope to design some stuff that the two communities might find useful.

Every story, be it a movie game or book, that is worth taking in will diverge through a series of situations leading up to the end result. A good writer can probably outline an entire book simply in situations and then connect the dots with drama lines, action sequences, an array of emotions, or some history. Take for example Star Wars where Luke first fights Vader. A situation arose which lead up to a vengeance action sequence and then on to one of the most memorable movie situations I can think of. The action scene before really built up the suspense and drama and lead beautifully into Luke’s frightening reality.

Now back and take another look at this. What if Vader simply entered the room, put Luke into a choke hold and let him have it with the “who’s your daddy” line. It would have OK, it would have been a little more difficult on the escape, and it wouldn’t probably wouldn’t have been as quotable. The struggle built the drama, Luke was loosing and you could feel, and when you were finally on the edge of your seat the perfect situation had been generated.

Now lets swing over to one of my favorite series that every now and then gets on my nerves. I love X-Files. Great show, I am a bit of a conspiracy theorist myself so I easily bond with the looming plot lines and back story. So as a fan I think I can fairly criticize this one a bit. In the latest movie toward the end there was a moment where Mulder was pushed off the road and crashed. So here he was, someone attempted to kill him, he survived, and rather than calling for some back knowing that this probably wasn’t over, he conveniently never realized his cell phone missing and went after the truth with my mind screaming from the moment he got out of the car to get his cell phone. By the time the bad situation come about I really didn’t care that he just might get killed. For me, that ended the movie, I watched the rest of it, but I couldn’t get that out of my mind.

Now lets plug this into game development. When generating situations for your heroes it is important to remember that the events leading up to the situation are just as important as the situation. If the situation completely dependent upon someone doing something that is going to have the human player throwing the controller at the screen, it is best to do it through an NPC or a temporary party member. Unless you are a truly remarkable story teller, using the main character to do something stupid for anything other than a light hearted humorous moment is likely to make the gamer feel that their role in the story has been eroded.