Saturday, December 15, 2012

Sticking with Blitzmax

One of my biggest problems is when it comes to game coding I have this nagging feeling I'm always doing everything wrong. The grass is always greener on the other side. I'm investing all this time and effort into something that isn't the best.

In my last blog I talked about GameMaker and was thinking of switching to it. The only reason being is because making a game in GM allowed it to be packaged and exported to other platforms such, mainly IOs and Android. I have very little interest in Android, personally I love it and use it but there are different versions out there, different screen sizes, who needs it. That leaves the all empowering ipad. It's tempting but is it worth it?

I did some reading on what people thought of GM. Yes, it's been around forever no doubt. I read some of the reference manual to learn about GML (the scripting language it uses). The language seems pretty powerful and can probably do a lot of things that Blitzmax can do as well. I have no doubt GM can make great platform type games in a short amount of time as well as other genre's.

Then I started to get that feeling again. A long time ago I was trying to make a game using Torque2D. Same premise, it's a 2D engine that *can* be used to make any type of game you wanted. Even when I had a full handle on T2D and knew a lot about how it worked, it was a struggle to get things to work how I wanted. There were a lot of hurdles and it became exhausting after a while.

When I imported a bunch of sprites sheets into the editor, the editor memory usage spiked up to over a gig then crashed. This was a huge, huge problem. I talked to one of the dev's about it, it was kind of a bug or at the very least a shortcoming of the product. He emailed me a fix, which worked well but not great. I was able to bring in all the sprites without crashing but the editor slowed considerable. Clearly. T2D wasn't design for large levels and hundreds of sprites.

They released an update with a bunch of bug fixes and enhancements but to my surprise the unofficial patch that I received wasn't part of it so the memory problem happened all over again. Now don't get me wrong, T2D is a fine product if you are making a game on a smaller scale but it just wasn't suited to what I needed to do.

Now back to GameMaker. I'm sure it's a fine product but there are limitations. I read it has slow loading times and such would be a real pain to work with. I can see trying to get past coding hurdles just to make things work the way they should. I can see running into even more problems when I have lots of levels with lots of sprites. And for what? Just so I can sell my game on the Ipad?

So yea I'm over it. I also have to kick myself another kick in the ass to stop doing this to myself. There are a million products out there, all of them are good but the crucial point is if it's a right fit for what you are doing. I'm sticking with Blitzmax and my goal for 2013 is to make a damn good old school RPG!









Saturday, December 8, 2012

Toying with Switching to Game Maker Studio

Yes I'm back to torturing myself again in deciding what's the best route to develop an old school RPG. I love Blitzmax and I think it's great. I love the fact that it's a language so I can create anything I want with it rather than a level editor. The other day I was reading PC Gamer and they had a section on indies and the software they use to create games, needless to say I couldn't read it fast enough.

Game Maker, I've known about it for a while but never paid it much mind. Game Maker was featured in one of the articles and what caught my eye is it can build a game on IOs and Android as well as PC and Mac. Hmmm. I know for a fact that Blitz will never have that capability ever. A few weeks ago I was reading up on XCode and just thinking to myself if I ever made a few games would I want to port it to the ipad? I would have to learn XCode which will require a lot of time and effort. For someone that isn't doing this full time and won't be doing this full time for a long time to come, if ever, it probably won't be worth it.

I know the developers of Blitz made a new product called Monkey but hear the syntax is horrible and overall it doesn't really interest me. On the other hand working with Game Maker will be confined to an editor of someone else's making. I'm adamant on not going with Unity, it's 3D orientated and I know I'll have to jump through a lot of hoops to get things to work for me. Using Blitzmax is still a viable option but it doesn't afford me to make a game past the pc and mac.

I'm probably going to do more research and maybe spend some time learning GM to see if it can do what I need. The prospect of making a game for traditional platforms as well as the mobile ones is hard to pass up.


Monday, November 26, 2012

Making an overhead map

Unlike classic RPG's of old, I want to keep as much info as possible off the game screen and keep that real estate for the actual game. I don't have any interest in a small overhead map in the corner of the screen that will create clutter and only be looked at some of the time.

I actually struggled with this for a while since I really had no idea how to code it. I posted in the Blitzmax forums asking for ideas and one of them (and a pretty good one) was to create a pixmap sprite. A pixmap sprite allows you to manipulate every pixel in it terms of color and what's the draw. One idea is each pixel would represent a single tile on a level and either draw that tile had or perhaps shade it so objects would be one color and the ground would be another.

After thinking a lot about it I think I have it figured out, in theory anyway. When I read in a level it populates several data structures. Basically, you have square at X and Y and I store the data. What coordinate does that square represent, what sprite gets drawn there, etc. When I render the screen I just loop through those arrays and draw it.

So why not pull in that same data but scale it! When I draw a level, I start at a fixed point for the first square at it's center, say X 0 and Y 0. The next square gets draw at X 32 and Y 8 and so on. If I wanted to draw a mini map of the entire level I could scale by size and coordinates. Let's say we have a 64x64 sprite. Zooming   out by a factor of 1 would make it 32x32. Now, instead of drawing it at the same coordinates I will draw it at X 16 and Y 8. If I wanted to zoom out more I could keeping halving the numbers.

Of course this is all in theory. Fleshing it out in this post sounds like it should work but there is only one way to find out. Since I don't plan on constantly refreshing the map I would only have to loop through all the items only once so bigger maps shouldn't be a problem to draw. Once I get this coded and hopefully working I'll post more about it.

Sunday, November 25, 2012

Why a post-apocalyptic theme RPG

I just finished driving 22 hours straight from Florida to NJ with my girlfriend so if this post sounds a bit like rambling I will apologize in advance.

As a kid I played Dungeons and Dragons over the years, pen and paper style of course. In my early 20's we used to play every sunday afternoon. Don't get me wrong, I like fantasy just as much as the next guy... but there are only so many goblins and orcs someone can kill in their lifetime!

I always had a fetish for end of the world scenarios and sci-fiction, I love it. A mass disease that wipes out the human race, a nuclear war, the zombie apocalypse, love them all. I have zero interest in making yet another fantasy RPG about so and so magic user trying to find the kidnapped Princess in some dungeon somewhere.

Give me guns and bullets, they are fun to use, not crossbows and arrows. With a post-apoc RPG you can make it pretty gritty, read: not a "pg" family orientated game. I also think that if I make a deep story driven post-apoc RPG series I can create a niche market for myself. That remains to be seen but I want to be known as that post-apoc indie guy someday :)

Like I said my other passion is sci-fi. I can totally see cranking out some sci-fi rpg's taking place in a futuristic city with cool weapons and alien races. I think that would be received well since there aren't many turn based rpg's in a sci-fi setting out there. There could be all kinds of cool stuff I can do, evil corporations, a desert wasteland with some experiment gone wrong, alien races with various attributes. It would be pretty cool.

So in closing, no more magic spells and no more castles, let's fire off a few nukes and have some fun.

Tuesday, November 20, 2012

Turn based combat system: Building the classes

My girlfriend and I are currently vacationing in Florida for the Thanksgiving holiday so I haven't been coding at all. This does however give me time to think about the game mechanics and how it's all going to come together.

My combat system is all in spreadsheets with all the stats, skills and other character attributes. Of course this is a raw system that I made up on my own and completely unproven. I have no doubt once I see it in action there will be a lot adjustments.

Since my game isn't fantasy based upon I felt I was really restricted on making classes. For fantasy classes you can have a fighter, mage, cleric, thief, barbarian, paladin and so on. My game setting is post apocalyptic so I originally decided to not have classes at all and let the player build up the character stats as they saw fit, four characters in all. I also originally had it real old school with basic stats such as strength, endurance, etc in their own separate container that would receive their own points to upgrade with on each level up.

So I got to thinking and the more I thought about it the more I realized I wasn't really thinking outside of the box. The above system would still be fun but it's kind of one dimensional and doesn't allow for a lot of possibilities or tactical decisions in a firefight.

Here is what I came up with so far that I think will really open up the possibilities. The classes will be soldier, demolitions, sniper, heavy weapons, and locksmith.

The soldier would have bonuses for automatic weapons and be well rounded. Demolitions would have a love for explosive weapons and be able to set and disarm traps. Sniper would excel at longer range fire. Heavy weapons will be for heavy fire support but you would have to use those weapons wisely since ammo use will also be an issue. A locksmith will be a key master, able to hack terminals, open locks, steal, etc.

In addition to each class having their own specialities I'm also going to make certain upgrades available to only that class in leveling up. I can also see designing missions where you can pass them no matter what you have but a particular class would help a lot. It might also allow the player to build a party that is suited to their playing tastes. I also like the fact that if I create 6 classes but only allow four characters in the group it will force some decisions to be made. I plan on having a dozen or so characters that can be picked up along the way.

I'm confident that this new system, even though it's still only on paper, will allow much greater playing choices. I can't wait to see it in action.

Friday, November 16, 2012

Writing the perfect code, why do I torture myself?

I wonder if other people do this or am I a unique being. Today I went to work on the turn based combat system since I've barely scratched the surface. I quickly realized my inventory screen was broken because other changes I had made a few days ago. Fine, then I noticed for each character's inventory I had a 25 cell array. This annoyed me because I was using a Tlist in most cases and wanted things to be consistent. Since I had to fix the inventory anyway I changed it to a tlist.

Fast forward over an hour later, fixing things because I changed the type of inventory system. What did I gain from this? I'm not quite sure really, other then I'm using a Tlist instead of an array. So the question I'm going to ask out loud is why? If it works, leave it. There is no perfect code or structure, of course it's going to be a bit sloppy no matter what I do. No matter how I write it, a time difference of 2 milliseconds isn't really going to matter.

I need to tell myself to stop tinkering, stop going backwards and stop wasting time. Ok I think I'm done lecturing myself, next.

Thursday, November 15, 2012

To Blitzmax or not to Blitzmax

I've done this to myself many times over the last few years and figured it was an interesting topic to talk about and I wonder if I'm just a weirdo or perhaps other aspiring game makers do this too. Ok I'm probably a weirdo regardless.

Given the pace that I'm making this game I always think there might be something better that I could be using, such as Unity 3D for example. Over a year ago when I took up Blitzmax I was confident it was what I was looking for and wanted and something I could stick with. I was using Torque Game Builder before that but it wasn't a good fit. Recently a thread was created on the Blitz forums about how there aren't any updates left to it and wondering of Blitz is going to be obsolete in the near future. I also read comments how Blitz is sorely lacking some essential features like AStar and items like that.

Now of course I read it and it fed the always present self doubt that I have about the time investment I'm making and if using Blitz is still the way to go. Maybe I should take up Unity 3D so I can eventually get my game published on the ipad really quickly and other platforms with one code base. Maybe Blitz could be a lot better and it's past it's life span.

I ran some searches on making a isometric rpg with Unity and found very little. I saw some posts asking if you "can" make an isometric rpg with Unity and the answer is the generic "you can make anything you want".  I also read a blog of an indie that has actually made a few games and he is into Unity and he talked about how there are a lot of "tricks" to making a good rpg with Unity.

It took me about a day to realize I already had been down that road before and forgot the lesson I learned. I'm not a very good programmer by any means. I can't look at source files in an engine and figure out what's going on (or at least with any ease) or make any modifications to it. I had really struggled with the Torque engine because while it has a lot of great features a lot of the work I did was figuring out how make feature X work with design Y. It really did get exhausting after a while, always jumping hurdles to figure out how to make it work.

I'm sticking with Blitzmax and I'm not letting a few forum threads influence me. Just because something can be bigger and better it doesn't mean it's really for you. I remember reading that Cliff Harris still used I believe Directx 7.x to make his games until recently where he upgraded one version. And I also thought about people's comments how Blitz is lacking features like Pathfinding. I already made a pathfinding system in Blitz that works great and it's coded to exactly what I need.

So yea I'm sticking with what works for me and what I'm comfortable with and I'm not going to adopt the "grass is always greener on the other side" motto.