Pretty much the only new stuff out right now are some partial tile maps I have been experimenting with. I even took a stab at hand drawn art, and I am not impressed, but not disgusted all at the same time. The hand drawn art I do always seems to dull down the colors, so I have to make a choice of all hand drawn or all generated as the two don’t seem to mix well.

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.

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.

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.

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.

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.