Pixelated Gravity

Project Axe Fight Update #001

2016-08-28T23:01:00.001-05:00

Started a new project, sort of, it's really just a continuation of a game I started over 1.5 years ago with a friend as our attempt for the Ludum Dare #31 game jam. We started off writing the game in C++ using SDL, but that didn't work out so well as I was a bit rusty with both C++ and SDL at the time. Recently I've decided I would try to actually make the game but just using something simple, i.e. Game Maker Studios.

Here's a video of the game's current progress after 1 weekend of work. Art was done entirely during the game jam 1.5 years ago, so this weekend was spent entirely on current functionalities and design.

Project Axe Fight (title is definitely a work in progress) is a simple multiplayer competitive action platformer, similar to Tower Fall. Players can move and jump around the level, contained entirely within game's screen, so no camera movement. Pick up weapons and power ups, to fight. During the game jam we decided to stick with just 3 weapons to start off with, the Axe, the primary weapon with which only one spawns at the start, the Hammer, and the Bomb.

The Axe is thrown in an arc and upon hitting another player, that player is killed.
The Hammer is thrown in a straight path, meaning it isn't affected by gravity, until it hits something.
The Bomb is also thrown in an arc but after a short duration the bomb explodes, killing all players near it, including the player that threw it (up for debate whether suicide).

The movement system consists of simply walking for horizontal traversal, variable jump speed (hold button down to jump higher, and wall jumping.

There are also bouncy pads that can be used to jump higher, faster, and will even affect thrown weapons.

There is currently no health system planned as it's entirely one-hit kills.

~ RogueTemplar

Heart Realm Update #013

2016-01-31T18:30:00.001-06:00

As mentioned in my last blog post I have returned to Heart Realm, I'll be moving the game over to Unity, away from Java and all that. Along with that change I'll be making some changes to some systems, some of which were never really set in stone.

The reason for the change to Unity is partially due to my desire to work on the game more than the engine and the game, something I was doing when writing everything in Java. I've been using Unity now for the past 5 years now, working with it on and off on various smaller projects and so I feel comfortable enough with where it's at for me to work on this type of game using it.

I've also thought that by changing to Unity I could potentially add a network portion to the game, maybe have some kind of co-op, but that's all dependent on where the design of the game goes. There's really a bunch of little reasons as for why the change, but ultimately it's because I just want to focus on making a game rather than an engine and the game in a language that isn't the best for games, i.e. Java.

On the design side of things there's a few changes that I'm currently hashing out. In the current system the player's attributes would start off at 10 each: Vitality, Strength, Dexterity, Agility, Wisdom, and Intellect, you would get 3 attribute points every level to distribute however you please among these stats that then affect a variety of things. The problem with this design is that the player's power level keeps growing infinitely, potentially, while the enemies power levels do not, they may a little, but not like the player. To get away from that I've decided to take a similar approach to what Dungeons and Dragons 5th edition does (probably occurs in previous versions as well) and to put in a cap for the player's attributes. I've decided that a soft cap of 25 should be fine, with a soft cap of 35 or 40 for NPCs (enemies and such). There will be ways to increase beyond that cap with the help of skills, equipment, and temporary buffs, but the player will not be able to increase it through normal leveling up. Making this kind of change also means I'll have to rework how each point in an attribute affects everything.

Along with the change to stats having more impact on the player, I want the equipment to have more impact on the player's move speed and attack speed. Equipment weight will affect move speed greatly, and a little bit on attack speed. Weapon weight will affect attack speed as well, though the weapon's attack speed will probably just remain it's own stat on the weapon itself rather than having the weight of the weapon affect it too. The weight of all your items and equipment will also limit the player's movement with the inventory limiting what you can carry based on weight, so no bottomless bag. With this addition there will most certainly be some sort of storage system in place so you can drop off your unused items to come back to at a later date.

Before I had abilities on scripts, well now I'd also like to have weapons have their own scripts as well, basically giving each weapon multiple attacks. For example, with a long sword I can have a slash dealing entirely slashing damage for a primary attack, and a thrust dealing entirely piercing damage for a secondary attack. Each of these attacks would be bound to different buttons, e.g. left click - primary attack, right click - secondary attack. By having multiple attacks for each weapon I can do something interesting like have a primary attack be a thrust with a spear, and maybe a ranged throw for that spear's secondary, or maybe a swipe that does strike damage and applying a speed debuff to the target. Basically primary/secondary attacks would be like abilities but are inherent to the particular weapon and are based entirely on the stats of the weapon and player using them.

Another change I'd like to make is to the items giving them multiple levels of information displayed for their descriptions. What information is shown on an item could be based on the player's Intellect stat. You could learn more about the item in question, more about the world or potentially prevent yourself from equipping an item that's cursed (something I'd like to add as well, cursed items). I could hide some stats from the player if their Intellect isn't high enough so they'd have to use the item or equip it in order to see the effect of it.

All these changes listed above are ones I'm definitely making, but there's another that I'd like to add provided it works with the current design, though I think at the moment it'll work with everything else since there's no system in place preventing it, and that is a weapon/armor/magic skill system similar to that of the Elder Scrolls where as you use a certain class of weapon, armor, or magic you become more proficient in them. With this sort of system I could include a tree of abilities and spells for those skills, like the perk trees in the Elder Scrolls except more active abilities/spells. Right now I don't have any system in mind for how the player would acquire spells or abilities anyway so something like this would work. Of course I can also have spells and abilities be purchasable or learned from "spell books", which would work great with the previous change. A spell book that teaches the player a spell provided their Intellect is high enough to learn it, or maybe you can learn it but you won't know what you're learning based on the description because your Intellect isn't high enough.

There's all sorts of things I can do with these changes and I'm excited to get them implemented and working. Of course with the change to Unity I'll have to get all the old stuff implemented first. For now that's enough of update. I'll be back for sure with more updates in the near future. I don't want to go 2 years again without updates.

~ RogueTemplar

The Return

2016-01-31T15:56:00.001-06:00

It's been a while since I've posted here. Why is that? I just honestly haven't made it a habit to write here and I've just gotten caught up in life in general.

To start off I'm now officially working in the video game industry (for more than a year now). I started off at a company by the name of Phosphor Games as a QA tester working there on two different contracts for 9 months with a 2 month break between those contracts. At Phosphor I started off testing a game called WARP for Android and iOS that was unfortunately cancelled prematurely ending my contract with Phosphor. I returned 2 months later to work on a couple games one that was recently released, Gemini: Heroes Reborn for Xbox One, PS4, and PC, as well as Heroes Reborn: Enigma for Android and iOS that was released last fall. I also did a little bit of testing when needed for the game Corpse of Discovery, released last August for PC.

After working at Phosphor Games I was looking to continue working in the Chicago game industry. A few weeks later, back in August, I started working at Wargaming, as a QA tester, where I'm at currently, working on the console version of World of Tanks for Xbox 360 and Xbox One.

So far it's been great working in this industry as it's exactly what I expected to be, just a bunch of cool people who make or contribute in some other way to games being made.

Work life aside, I've participated in a few more Ludum Dares, with only one with which I'd consider a success in completing a game. Other than the Ludum Dare game I've already posted about, Rush Delivery, I made a game called Goblin's Plight.

I have also started and set aside various other game projects, one of which was a board game I started over a year ago that was based on my game Flame and Steel Tactics. I started working on it, made cards in photoshop, wrote the rules, printed off the "board" on some paper for some test sessions, but never actually tested it out. I hadn't touched it in over a year until I was gifted a copy of Tabletop Simulator a month ago. With the power of Tabletop Simulator I imported all the cards, and pieces and started playtesting by myself. It turns out, the game is in a very rough state, no surprise. The first match lasted over 3 hours, way too long for what I wanted, so I modified the rules slightly and played again. Second match lasted a little over 2 hours, again too long, so now I'm planning on reworking some things, as to what, I'll save that for another post at a later time. Link to Tabletop Simulator Workshop item. Link for playtest data.

Another project I've been working on, was a website dedicated to counter picking heroes for Dota 2. I started on it in October 2014, but set it aside until recently (this past month) I've returned to it to continue working on it. I've only worked on it here and there for little spurts at a time so it's nowhere near finished, but this is what it looks like in its current state, example of Pudge's page. I'm currently going through and doing all the tedious data entry type stuff, entering hero abilities, while occasionally working on the site itself. It's no where near ready for public use, but I'll just leave it at that. I'll get into it a bit more in a later post some time, definitely when I "launch" it at version 1.0.

The big thing now is that I've just started working on Heart Realm again. It's a game that I'm definitely still interested in and so I've decided now to continue working on it again. Though with some big changes. Firstly, I've decided to make the game in Unity instead of in Java with a bunch of various libraries and whatnot. Secondly, I'll be reworking some of the various systems and stats. I've taken notes over the past year or whatever it's been since I've last worked on it, on various things I feel need to be changed so that's something that will be coming. I don't want to get too in-depth about these changes in this post as it's already getting pretty lengthy so I'll just make a separate post for that.

Another new thing for me is that I've recently gotten into the genre Melodic Death Metal, so I've been listening to a few new favorite bands of mine a lot: Be'lakor, Insomnium, and Omnium Gatherum.

With that I'll leave you with an appropriate song for this post. The Return

~ RogueTemplar

Lasers and Fish

2014-04-08T22:32:00.002-05:00

I've realized that it's been a whole month since I've last posted here and there's a reason for that. One of the reasons was because I hadn't worked on Heart Realm in a while, another reason is because I was busy working on something else in the meantime.

I had made the decision a couple weeks ago to take a short break from Heart Realm, not because I wanted to get away from it, but because I wanted to work on a short-term project. A few weeks ago I had decided to look into LibGDX, it's a library for Java game development that seemed pretty cool too. So after checking it out and fiddling with some basic tutorials I decided I would attempt to re-work some of Heart Realm's code to work with it. There were many reasons for why I would do such a thing, something I can't quite get into at the moment as it was weeks ago and don't remember all the reasons, but basically it had a lot of cool and useful features one of the big ones being that it was using OpenGL, something I wasn't using. Unfortunately I did not succeed in implementing it yet, though I will attempt again in the near future.

In the meantime, working with LibGDX was great, it had it's quirks like all frameworks and libraries, but I enjoyed it, so much so that I decided to create an Android game, something I hadn't truly attempted. So I set out to create a simple game with the goal of actually publishing it within a week or two of starting. I wanted to get the experience of actually publishing something for once, something I hadn't yet attempted. So I created a simple side-scrolling "shooter" called Laser Fish.

Laser Fish is a very basic game where all you do is move your fish up and down while the ocean background scrolls by with other fish swimming towards you. Your goal is to simply "fry" all incoming fish getting as many points as possible without letting 10 fish pass you by and survive your powerful laser beam attack.

I treated this little experience as something similar to that of a game jam in that I had a set deadline... sort of... with the goal of actually publishing it upon completion and as I'm writing this, it's going through the submission process at Google to be added to the Google Play store. Link to game.

Now that I'm done working on Laser Fish, I think I'll go back to working on Heart Realm, or maybe another simple game. I'm not quite sure just yet. Fortunately another Ludum Dare is coming up and I hope to take part in that, though I can't guarantee anything.

Heart Realm Update #012

2014-03-04T01:13:00.001-06:00

There's been a decent amount of progress since the last update including some minor changes to the damage/armor system and some basic spell casting functionality. That being said, this post is going to be quite wordy as I cover these things in detail.

Damage/Armor Change

To start off with I'm going to talk about the changes to the damage/armor system. Originally the way damage worked was there was a range of 2 numbers and the damage would be random between those two values. For example you had a weapon that had an attack damage of 38-45, it would deal an amount between 38 and 45, so like 42 for example. That random number would then be calculated against the target's armor in a fairly simple formula. The result of that formula would then be broken down into multiple numbers based on the attack elements, for example an Iron Fire Sword that had an attack of 38-45 with 70% Physical, 30% Pierce, 30% Fire (the percentages didn't have to add up to 100%). So with that result of say 31 after the armor calculation and the randomly chosen number from that range, that 31 would be split up based on those percentages. You'd have 21.7 Physical, 9.3 Pierce, and 9.3 Fire damage, each of those numbers would then be reduced further based on the target's resistances. For example a goblin with 5% Physical, 0% Pierce, 0% Fire resistance would reduce that 21.7 Physical, 9.3 Pierce, and 9.3 Fire to 20.615 Physical, 9.3 Pierce, 9.3 Fire damage. Those numbers would be added up: 20.615 + 9.3 + 9.3 = 39.215 then converted to an integer for the final amount, 39.

Random number between: 38-45, 42
42 calculated in a simple formula vs target's armor value = 31
31 split between 70% Physical = 21.7, 30% Pierce = 9.3, 30% Fire = 9.3
Array of values reduced by target's resistances: 21.7 * 95% (5% Physical Resistance), 0% Pierce and 0% Fire Resistance.
Add up values: 20.615 + 9.3 + 9.3 = 39.215 = 39 (converted to integer)

That was changed to a more direct damage and armor system. Now all damage is an array (well hashmap, technically) of values in their element's respective index with no range (the random element is still present). So for example that Iron Fire Sword is now: 22 Physical, 9 Pierce, and 9 Fire damage. Those numbers are then calculated in the same way armor was originally calculated, except vs each of these values and instead of having one armor value it's just the resistances array and they are no longer percentage reductions. So for example that Goblin with: 15 Physical, 15 Strike, 5 Slash, 15 Pierce, 0 everything else, would be calculated against each of the damage values from the attack. With a result of: 13 Physical, 3 Pierce, 9 Fire damage, added up to 25. That number would would then have a variance value applied to it, of say 15% so the total could be anywhere between 21.25 and 28.75 (25 * +-15%). Of course all of this doesn't include the stat scaling from Strength, Dexterity, and Intellect, which would occur before the resistances are calculated. That 22 Physical damage could go up to like 32 with a decent Strength scale, for example.

Why did I make this change? Well it's easier to articulate how effective a piece of armor is vs certain damage types compared to other damage types it's applied to. The different attack elements have more weight in the actual outcome where before resistances were percentage based which is fine for higher values, but I didn't want a low level Goblin to resist 15% of all physical damage on top of the base armor. It's just simpler to see a single number to represent all physical damage reduction, or fire damage reduction, etc than having the armor value, plus the resistances which were percentage reductions (not the best decision initially). I can now have a piece of armor that does really well at protecting against lightning damage, but terrible at everything else, before that, since it was percentage based, that level of protection would vary based on the incoming damage.

Abilities

Enough about the damage/armor change. Let's talk about the progress on spell casting and abilities. In the previous update I believe I mentioned some basic spell casting. At that point the one spell I had was stored in an XML file, which more were going to be stored in as well, but that limits the potential of spells and abilities I could have as I would need to write a whole bunch of java classes with a variety of functionality for the number of possible abilities.

I now have it working where there's just a very basic ability class that calls a cast function on an ability's script that is tied to that object. I would have multiple basic ability objects with a script tied to it each with their respective ability scripts. For example 1 script file for Magic Missile, 1 script file for Force Push, 1 script file for Fireball, etc. The game would have 3 different ability objects each tied to one of those script files and would call the cast function on their scripts. The script would then handle any logic necessary. I could have a spell that does the specific thing of moving the player up 2 tiles, then left 3 tiles if I wanted to, all of which would be in that script.

Dumping the logic of each specific ability into a script file allows for much more freedom in the types of abilities instead of creating a Java class file for each ability or an XML file that stored some data on these spells that were based on some basic spell archetypes. XML files work just fine for static types of content like a weapon or armor where there is no interaction with anything in the game world or entities, but for something like abilities where you'd want some kind of interaction with the game world or whatever, scripts work wonderfully. That being said, I'll be using Lua for all scripting which would be for things like AI, abilities, possibly dialog, basic world generation (the setup at least), etc. I will be using XML for the more static types of content like items, armor, weapons, and enemies. Fortunately, if I wanted to, I can link any of these static types of content to scripts as well. I could have a weapon that when it hits an enemy knocks them back, or teleports the player 5 tiles to the left, of course that's not very practical and just doesn't make sense, but it can be done.

Scripting is a beautiful thing, and I'm glad I finally got around to implementing Lua. It's been a bit challenging working with Lua as someone who's new to it, trying to fix problems that I won't know about until I test it out, but I've been improving and it's been going great so far.

To finish off this lengthy update, instead of including screenshots, I've decided to include a video which sort of demonstrates the bare-bones spell casting system, showing off like 4 or 5 different spells, as well as the inventory and character screens.

Note: I'm going to try and include labels for these posts from now on. I think it will improve the organization of these updates. I've also gone back and added labels to all my previous Heart Realm updates.

~ Rogue Templar

Heart Realm Update #011

2014-02-11T02:41:00.001-06:00

Since the last update I have finished the first version of the character screen. The purpose of this screen is to display the player character's stats, equipment, etc. as well as allow the player to distribute stat points that they receive upon advancing in character level. Obviously all User Interface stuff is temporary and will be updated throughout the development of this game. This current version is fine for getting it's point across.

Aside from the character screen I also got the basic AI working in Lua scripting, so I'll be expanding upon that when I get to a more complex enemy type. It took a bit of figuring out how to work Lua before getting it right as I'm pretty new to the language.

Besides AI and the character screen and the typical new content, as in new enemies, equipment, etc. I just got started working on player abilities/spells. I've got a very basic projectile magic attack working, but there's a few bugs to work out. I'd like to use Lua for that kind of stuff as I think spells can probably get pretty complex, too complex for just Java classes, where I'll need to create a bunch of classes for the various spells, which isn't the best thing in the world.

Finally, here's a screenshot with some skeleton warriors and the magic spell being fired off.

Until I post the next update, I plan on working on these abilities and hopefully integrating them with some kind of enemy type in their AI so I can have mobs running around shooting off spells or attacking with ranged projectile attacks.

~ Rogue Templar

Heart Realm Update #010

2014-01-29T18:33:00.002-06:00

I recently got back into working on Heart Realm after having been away from it for about a month or so. I had been working on another project which I started with the intent of it being a short term project, as in I don't plan on working on it as long as Heart Realm and would hope to finish it in a much shorter time.

Since the last update I had worked out how I would go about implementing Lua scripting into the game. I came across a Java library called LuaJava which I had some trouble implementing due to some compatibility issues. Turns out it was just something stupid. The .dll and .jar files were compiled to run with a 32-bit JRE, and I was running a 64-bit JRE. My initial solution was to run the make files provided with the source of LuaJava to make a 64-bit version, but I had no luck. I then realized that the problem was in fact the JRE version I was using being 64-bit. I had the 32-bit version on my computer but was not using, for some reason, so I switched the project over to using the 32-bit JRE and now it's all good.

With the implementation of Lua into Heart Realm I am currently working on converting over most data files into Lua scripts to allow for more depth in them. Right now I have the few enemy types converted to Lua scripts and I'm now working on implementing the AI as Lua scripts instead of having a whole bunch of Java classes. So far it's been a whole bunch of trial and error since I've never worked with Lua before, especially with Java so it's been tricky. Fortunately I'm starting to get the hang of Lua and LuaJava specifically. I'm realizing how great it will be not only for just simply static enemy, items, and equipment stuff, but for all kinds of things like adding extra effects to items or equipment that would have required a series of classes to get the same effect. I can use Lua for any UI related stuff if I'd like to, which I will probably implement at some point. There's a number of things I can now use Lua for in Heart Realm.

~ Rogue Templar

Ludum Dare #28

2013-12-15T04:30:00.004-06:00

I've been a little busy lately, so there hasn't been any progress with Heart Realm.

This weekend I participated in the Ludum Dare competition for the first time; Ludum Dare #28. I went in by preparing the days prior working on little warm-up projects using the various software that I planned on using for the competition.

For this project I used Unity3d writing the code in C#, using Paint.net for graphics, Audacity and Fruity Loops for audio.

This current competition had the theme "You Only Get One" so I decided to make a little game where you're driving a delivery truck, think Postal/UPS/FedEx type truck with the goal of delivering a heart for a transplant to a nearby hospital in a crowded city. You are given one minute (this is where the theme comes in) to reach said goal, but you have to avoid pedestrians and other vehicles on the road that get in your way. There isn't any difference in what happens at the end of that timer or upon reaching the goal except for a single Game Over message, questioning your decisions if you ran over some pedestrians and whatnot.

You can check out my submission HERE.

~ Rogue Templar

Heart Realm Update #009

2013-12-04T17:30:00.001-06:00

Since the last update, I haven't had a lot of time to work on Heart Realm. I'm actively searching for work so that's been taking up a lot of my time.

This past week I've focused on reworking how data is imported into the game. I was using XML files to store all the necessary attributes of the various item/equipment types and enemy types but figured it was unnecessary to store any redundant data of similar objects. For example, there's no point in having multiple data objects of two similar Goblin enemy types when I could just make one Goblin base then create variations off that, inheriting all it's parent's attributes and simply changing whatever I need. Here's an example of what I mean:

<name>Goblin</name>

</enemy>

<base>goblin</base>

<name>Goblin Warrior</name>

</enemy>

The point is, I don't have to re-enter all that same data multiple times, the game will just load the base object then make any necessary adjustments.

So that change in how I stored these pieces of game data will help keep the data files smaller, getting rid of any unnecessary redundancies. This past week I also looked into implementing Lua scripting into the game, again focusing on the game's data. I figured I could create various little scripts for a wide variety of things, from AI code, to spells and items. The point being it'll be much more flexible than creating a Java class for every spell type or AI type. Sure, I created an abstract class for something like attack effects like, Life Steal, Mana Burn, Armor Penetration, etc. but this will allow for more complex stuff so I don't need entirely new classes for all of these things. Each script can be almost entirely unique with a few necessary input functions.

That's about it for this update. I haven't really accomplished anything that's visually different, except adding the armor's data to the inventory screen now, so it displays that. Oh yeah, I also created a new enemy type, an Orc, though I'm not sure if I did this before the previous update or not, either way, here's a couple screenshots.

~ Rogue Templar

Heart Realm Update #008

2013-11-25T22:44:00.002-06:00

It's been a while... let's just leave it at that. Quite a bit has changed for Heart Realm since I've posted last; a change of location for one (in real life), change of job (had one, now I don't and I'm looking). Personal stuff aside, I've been working on this game on and off for the past few months so there's been a bit of change since I've last posted.

One major new thing is the inventory menu, it's very simple at the moment and don't want to go too complex with it at the moment.

The inventory can be accessed by simply clicking on the button that is permanently at the bottom of the screen, anchored in-fact. From the inventory screen you can click on an item to select it to display it's stats, (only have weapon stats displayed, and just descriptions for everything else). You can press "Enter" or double-click on an item to Use/Equip it.

Then there's the basic loot menu. When you kill an enemy a chest will be dropped (not sure if this delivery system will be in the final game) and upon interacting with said chest, it'll open up a little menu.

From that menu, simply hovering over an item will display its stats in the window to the right, clicking on it will add it to your inventory, as well as the "Take All" button which adds all the items present into your inventory. It's fairly straight forward.

Something that you can see in the previous screenshots but has yet to be mentioned is the player's health and mana bars being present in a HUD (Heads Up Display) at the top left of the screen.

Finally, I've reworked the combat system a little bit. I've created a time system where all your actions take x amount of time to complete and are affected by your character's speed attribute. Regular actions like using an item, moving, and interacting with an object in the world will have a set base time cost while things like casting spells and attacking with a weapon will be dependent on that spell/weapon. After the time cost of the action is calculated, the enemies in the world will then be given a number of action points based on the time elapsed from the player's actions. So for example if the player swings a heavy, slow weapon an enemy with a relatively high speed could potentially take multiply actions in the process of the player performing that attack.

Prior to this new system, enemies would make a single action or not based on their relative speed to yours, so if you were much faster than them, they had a decent chance of not acting. If they were faster, they would have a higher chance to make an action. With this new system, there is less randomness and is more dependent on the character's attributes and actions they take, making the game more tactical. With this new system I've been able to introduce a weight system for the equipment where the heavier the equipment you had on, the lower the player's speed. The player's speed is influenced by potential skill buffs, equipment weight, and their agility. This will now allow for deeper customization of character builds, instead of going for the highest damaging weapons and the strongest armor, there will now be trade offs for each weapon and armor type.

Aside from these few things, I'm sure there's other stuff since I last posted that I forgot to mention. So I'll end by also adding a few extra screenshots.

~ Rogue Templar

Heart Realm Update #007

2013-08-28T20:29:00.001-05:00

It's been a while since I've posted an update. First off, I started working on a board game version of one of my other games at the beginning of June. Then in June I started a second job so I was working two jobs and figured it'd better to spend my time developing a board game in the little amount free time I had so I continued doing that for a little while. Last week was when I finished working at my previous job so now I'm just working one job and so I have more free time to develop. Since I have more free time I continued working on Heart Realm.

For the past week or so I worked on a few things. For starters I worked on line-of-sight based vision where it basically just blacks out anything outside the player's line of sight where objects can block the sight. Currently it's in an early stage so the game does take a little bit of a performance hit. The game doesn't run really slow or anything, but there's definitely a big difference in performance with it compared to without it.

Aside from line-of-sight I made a very basic form of a dialog window. Right now it's just a generic looking window that shows up on screen with custom text and can be displayed for a time limit or until desired. I will probably do something where you simply just press a key to close the window, click the window, or whatever.

I also worked on map transitions where you can step in into a portal and it instantly transports you to a new map. Besides these few things that's about it. I have a feeling that these updates will be a bit shorter than some of my previous updates due to me working more than I was a few months ago, so there is less free time for development.

~ Rogue Templar

Heart Realm Update #006

2013-05-22T00:45:00.002-05:00

This week I decided to focus my time on combat. In doing so I started figuring out what happens when an enemy/the player is hit by an attack, and all necessary calculations that came with it. I also worked on the combat layer, which included some kind of AI for the mobs as well as a way for combat to actually start. To finish off the week, in keeping with the theme of combat, I added health/mana bars to the player and enemies (just health bar) and damage numbers when hit.

I'll go into detail about how the attack effect works first. When trying to solve the problem of what happens when a character, be it player or enemy, is hit, I need to come up with some formulas that calculated what happens in that instance. What came with that was figuring out all necessary calculations that needed to take place for whether you actually hit, how much damage you deal, and how critical hits work. The formulas took a little bit of time to figure out. I had to come up with a way that made sense in the context of this game and so it took me a few weeks figuring this out. Ultimately I came up with some formulas that I liked, which is what matters, and I felt were balanced, though we'll see as time goes on. Rather than just going through some long in-depth explanation of all the calculations, I think it'll be easier to just list them here as they're fairly straight forward.

1) Chance to Miss = (Defender's Agility + Defender's Reflex) ^ 2 / (Attacker's Dexterity + Attacker's Base Hit Chance) ^ 2 * 120
1a) Base Hit Chance is based off the player's weapon for example: with a slower heavier weapon like a great two-handed hammer it would have a lower Hit Chance of like 60, while something quicker, easier to hit with like a shortsword, it could have a Hit Chance of like 90.

2) Attack power = Random value between Minimum and Maximum basic attack damage
3) Damage = (Attack Power x Attack Power) / (Attack Power + Armor of defender

4) Correct Damage based on Elemental weaknesses/resistances. For example Dragon has elemental set of 100% Physical, 35% Fire damage for it's basic attack against the player who has 0% Physical resistance and 15% Fire resistance.
4a) For each element in the attacker's element set add the following result to the initial value of 0
4b) Result = 0
4c) Result += Attack Element Value x (100 - Defender's Element Resistance) / 100
4d) Result /= 100
4e) For the example: Result = ((100 x (100 - 0) / 100) + (35 x (100 - 15) / 100)) / 100
4f) That would come out to... 1.2975 which is what you would multiply the current Damage value by

5) Chance to Critical Hit = Bonus Crit. Rate + (4 * Attacker's Dexterity / Defender's Agility)
6) If Crit Hits: Damge is multiplied by: (200 + Bonus Crit. Damage) / 100

Then the result is what is subtracted from the defender's health.

I now realize that writing that all out takes up a lot of space when explaining things too, which I said I wouldn't, but oh well.

Next we have the combat itself. When the player is within an enemies sight range and has line of sight (not yet implemented) the enemy will be added to the combat "encounter" meaning they will then perform an action as a response to your actions. In the game's current state I only have one AI type and it is a very basic melee enemy AI package. That's also something I'd like to mention. I hope to create multiple packages for the various types of AI that enemies can use making it easier to add in new ones without having to re-write a lot of code. I'll probably have a data set too so I can import more from data files like all my other content in the game. Going back to the melee AI, the way it currently works is the enemy will either move towards the player, or attack when it performs an action. The way it decides on whether it moves or not is a random chance based on the player and enemies Agility differences, slower enemies less likely to move, faster enemies more likely to move as well as a static "Initiative" value. If it decides not to move it will then see if it can attack the player, if is within range and not affected by some restrictive status condition, otherwise it'll just stand still doing nothing.

Finally I added in health bars for characters, which was quite simple as well as a mana bar for the player (don't want to show enemies mana pool) and numbers that pop up above the character's when receiving damage. For the damage numbers displaying them wasn't too hard in that I had to come up with a way to display text on the screen in a more manageable way, which was quite simple, but the hard part was positioning them in proper location. Ultimately it boiled down to how I used one of the functions I created. I was calculating the offsets wrong which can be a bit of a pain to figure out sometimes.

For this update rather than posting some screen shots, which wouldn't show you much other than the health/mana bars and damage numbers, I figured I'd upload a quick video showing both that stuff and the AI in action.

~ Rogue Templar

Heart Realm Update #005

2013-05-12T00:55:00.001-05:00

So it's been two weeks since the last post, I just never got around to posting earlier because I felt that the progress I made wasn't worth posting about too much as it wasn't too glamorous.

Over the past two weeks I've been working on ways to implement enemy mobs and some of the various things associated with them.

1) I had to create a base class for the character stats which is utilized for both the player and enemy mobs, then create two child classes each with their own variations of the Character class to incorporate the differences they each have. For example, the player has equipment that can affect their stats while the NPC mobs don't.

2) Created a way to import enemy types and store it somewhere so they can be used.

3) Loot Tables, a simple way to store the types of items that can be dropped by mobs, can be reused by multiple mob types which can help cut down on memory usage, having to recreate the same loot tables.

4) Entity Manager a way to handle the many entities and to allow for easier communication between entities.

5) Rendering the enemy mobs, which means including any animated sprites that would be need to render them.

With all those set in place, I faced a slight issue, the way the render function worked for my Entity Manager class was it would loop through all the stored entities and render them in the order with which they were entered in. The problem was that you could have some entities overlapping other entities that shouldn't be overlapping, simply because it was created prior to the other one. To fix this I had to come up with a way to sort the list of entities and what I felt was sufficient was to simply sort them based on x and y location. An entity with a higher y value would be rendered after one with a lower y value, which give the effect that objects higher up in the screen were further away which works for this sort of semi-top-down perspective. I figured I'd do the same for the x coordinate as well, just because (no real difference in performance by adding in the x coordinate).

After fixing that issue, I faced another issue. The tiles were too small, when the player was standing next to a mob of roughly the same size they would be practically standing shoulder to shoulder, which is something I didn't want. To fix this, I decided to increase the tile size from 16 to 24 allowing for more detail and as well as more space for the two entities to stand next to each other without touching. This on its own brought on a few interesting set backs as I had to fix a bunch of things that I had hard-coded. I originally planned for the game to utilize 16x16 square tiles, but because the player is a 32x32 sprite it really screwed with the amount of space for objects to sit on a tile.

That's all for this update. I hope to add in health/basic attacking of enemies and maybe some basic AI by the time I post another update, hopefully in a week rather than two.

Oh yeah, I also messed around with fonts a bit and drawing text on screen. I still haven't come up with a robust way of doing so as right now I had to hard-code that text in the main game class, something I definitely will not be keeping.

~ Rogue Templar

Heart Realm Update #004

2013-04-28T01:30:00.001-05:00

This past week's focus has been on getting weapons into the game. Like the previous update where I focused on importing armor items into the game, I did the same this week but with weapons. Weapons were a little different in that I also had to come up with a way to import animations and store them in memory while the game was running.

So far I've got a data set of armor, weapons, and animations as far as content that I've loaded via XML files and stored for easy access during run-time. Like the armor, I also had an overlay on the player's sprite for the weapon. Unlike the armor, the weapon overlay also animates with the body, while the armor overlays are just a single frame, though that may change as I introduce more animations for the player. Other than that weapon importing wasn't too bad as I had the armor importing as reference so not too much extra work.

Something I've noticed, pretty much from the beginning, was that there wasn't enough contrast between the player and background causing the player to blend in a little. First thing I tried doing was messing with the level tiles, particularly the ones causing problems with the contrast. That didn't go too well as I figured I'd have to go through all tiles, existing ones and future ones, and test to see how it looks which could take quite a bit of unnecessary time. I decided to come up with a different solution, to give the player a black outline. Originally I thought, I could try maybe adding the outline to the player sprites and any equipment sprites, but that didn't look all too good. So I spent a bit of time combining the pixels of both the player's current frame of animation and any current frames of any equipment animations. Essentially that turned these individual sprites into one single sprite with a single array of pixels, similar to how the Screen class functions by just manipulating whatever pixels it needs to get an image drawn on screen. After combining all the sprites I then created an algorithm to find all transparent pixels that are nearby opaque pixels and set them to the color black, essentially making a black border.

Aside from programming those two things I also added in a few more items and reworked the player sprite a bit, it looked a bit ugly, I think. So I now leave you with some screenshots for the week.

~ Rogue Templar

Heart Realm Update #003

2013-04-22T03:12:00.001-05:00

Another week has gone by some progress has been made. This past week or so I've focused mainly on ways to import data files, particularly for the armor item types. I initially tried just trying to create my own format in a text format, but ended up just using XML as it was what I was most comfortable with. The first thing I did once I actually got the data files working was create a few pieces of armor to mess around with. I constructed a few basic pieces of armor with all the necessary stats that I knew a piece of armor could have. I added in a way to also attach sprites for both the icon which you would see in the inventory and other menus, as well as the sprite that would sit on top of the character's sprite, drawn in the world, if applicable.

While these sort of additions weren't all that particularly new from a player's perspective, they are necessary to the game's overall structure and will allow for actual content to be made in addition to just art assets and maps.

Like Dark Souls, I've decided I wanted to follow suit in how items are described, with bits of lore in them. In the creation of those first few items, I started writing a few things in my new text file for the game's design called the Lore Bible.txt. This will contain any bits and pieces of lore about the game's world, it's inhabitants, and any possible fiction revolving around it. In the future when I have much more substantial Lore Bible, currently only have a few lines of text, I may make a post about it. I wouldn't want to go too in-depth as I don't want to put all the lore out there and want it to remain a mystery some. I very much like the approach Dark Souls takes with story telling by not shoving it in your face and only giving you bits and pieces here and there allowing for those interested in it to go exploring for it. Also, the nice thing about this approach is that you don't need to have too much detail for the world as you can intentionally leave things a bit vague and obfuscated to leave things up for interpretation, much like the real world with many events in our history.

I will now leave you with my current selection of armor icons, which coincidentally also look exactly like they do when drawn in the world on the character, as well as another screenshot.

Hopefully next time I post will be a bit sooner rather than later.

~ Rogue Templar

Heart Realm Day 4... 5? I Don't Know What Day It Is. I'll Just Start Labeling These As Updates Instead. Update #002

2013-04-11T04:05:00.002-05:00

So it's been a week since I last posted anything in the subject of Heart Realm. To be honest I was going to, except I felt that the progress I made over the past few days of actually working on the game wasn't too significant. It turns out trying to program while watching various youtube videos or movies on the second monitor can sometimes be distracting. Despite the distractions, I still spent a decent amount of time programming a bit and drawing a few sprites.

The reason there wasn't a post earlier was simple, there wasn't much visible progress. I pretty much spent the past few days laying out the Character, Item, Weapon, and Armor classes that are used for handling the player's stats and the various item types, respectively. Basically I felt it was too boring to really talk too much about as one day I spent just creating a few of those classes and naming some variables, that's it. Aside from that I also worked out how I'd like to handle the weapons in the game. Like many new designers, or just a lot of designers in general I suppose, I took inspiration from one of my favorite games, Dark Souls. I decided I wanted the weapons to work in a mix between Dark Souls and Dungeons & Dragons; version 4.0, I'm not too familiar with older versions as I've never really played D&D in general, plus the weapons are more straight-forward in 4.0 compared to 3.5 I believe.

What this all means is a weapons damage will be split into two values, a minimum value and a maximum value, giving the player a range in which the weapon will deal damage, like D&D. For example, in D&D 4.0, a generic Long Sword has a damage value of 1d8 which means it'll have a base damage of 1-8. Likewise Heart Realm will have such system. Coming from Dark Souls I very much liked the way weapons scaled off your character's attributes, Strength, Dexterity, Intelligence, and Faith (Faith won't be present in this game). I decided that it was appropriate to include such a thing as well. Like most RPGs, weapon damage typically scales off the character's attributes but the game I felt does it most interestingly is Dark Souls. Each weapon will have a scaling parameter of either E, D, C, B, A, or S on any of those attributes mentioned earlier, increasing more and more from E through S, respectively.

On top of figuring out how I wanted weapons to work, I figured out the attributes for the character. Taken directly from my Game Details.txt file:

Health - How many points of damage you can receive before dying
Mana - How many points you can spend to cast spells
Vitality - Increases Health and Fortitude Defense
Strength - Increases Unarmed damage and scales weapon damage.
Dexterity - Increases Chance to hit/critical hit and some weapon damage
Agility - Determines how frequently you can act in combat and determines Reflex Defense
Wisdom - Increases Mana reneration and Will Defense
Intelligence - Increases some Magic Damage and your Mana pool

Basic Damage - How much damage you deal with a basic attack
Attack Rate - How likely you are able to hit something with a basic attack (Used to make large heavier weapons feel slower, despite the turn-based combat)
Armor - How much damage you mitigate when receiving physical damage
Fortitude - Defense against some stuns, slows, poison, burn, and many negative status effects that affect the body
Reflex - Chance to dodge/block basic attacks, various projectile type weapons and some offensive magic
Will - How much damage you mitigate when receiving magic damage and some negative status efffects that affect the mind
Resistances/Vulnerabilities - Reduces/Increases incoming damage of the various elements. Elements include: Acid, Lightning, Poison, Fire, Frost, Necrotic, Thunder, Radiant, Psychic, Force, Arcane

Though I've listed quite a few elements (taken from D&D 4.0), I'm not sure what will end up in the final game, but that does give me a nice sampling to work with. If I feel I can justify having all of those, I will keep them all in, if not, there's no point keeping them in.

That being all said, I have got each of these stats working in the game, though most have no functionality tied to them yet and won't until later systems are implemented.

Now I leave you with a couple new screenshots showing off the new armor sprites, and some weapon icons that will be used on the inventory screen.

I think that's enough for today's post.

~ Rogue Templar

Heart Realm Day 01

2013-04-04T03:04:00.005-05:00

While this may say Day 1, it's technically Day 3 or 4 of development. I started writing down the concept of the game the other day, but didn't actually start programming or anything until today. So, the game, as of right now, is called Heart Realm as you'll start off in this single hub type place and be transported to other various locations and dungeons which will primarily being procedurally-generated as most Rogue-Like games do. I decided to go with the name "Heart Realm" because you will always have this central hub-type realm you visit for shops and whatnot and can transport yourself to various locations via portals or whatever. I'm not 100% sure of all the details of the game. As far as the character goes, I'm also not entirely sure what I want to do, but from what I've decided so far is that you will play a generic player character which as you proceed through the game will evolve in whatever way you may see fit through the equipment, attributes, and spells you build into this character.

I've decided that I want to have a nice variety of practical equipment that doesn't become a linear curve of "A beats B, B beats C, C beats D, etc." I want the equipment to grow in strength over time through the player's own doing, with upgrading. Though that doesn't mean you won't find some magically enchanted weapons and stuff, they just won't be as common. A nice example of what I'm talking about can be seen in the game Dark Souls. There's weapons that are better than others in certain situations but there isn't like a single weapon that beats all, they all have their own uses and play-styles that fit accordingly.

That being said, it's going to be a bit difficult for this particular game as I plan on making the combat in somewhat of a real-time/turn-based style. What I mean by this is, every time you move or perform some action when enemies are around, they will also perform some kind of action in kind. If you sit there without performing any action (moving, attacking, casting spell) the enemies will also just sit there and perform no actions. This will allow you to play at whatever pace you'd like. If you want to take your time and plan out your moves you can, if you want to just run in there swinging your weapon wildly, you can. There's a few games that have similar combat systems, but one that comes to mind is Dungeons of Dredmor.

Since I'm not entirely sure on all the details of the design just yet, I think now is a good time to mention what I've accomplished so far. The game is being programmed in Java, for no particular reason other than just I feel like doing this in Java. I've got a basic map loaded up that gets its tile info from a small bitmap and reads determines what tiles to place where based on the pixel data. I've got a simple character that draws on screen, moves around with keyboard input, and can perform a simple attack animation with the click of the left mouse button. I've also got some basic tile-based collision detection so you don't go through walls and such. For now, that's all. Here's a couple screen shots of what I've got.

Well, that's all for now till the next update, which hopefully will be somewhat frequently.

~ Rogue Templar

New Project And Happy Fun Time

2013-04-04T02:30:00.002-05:00

Since it's been a while since I've last posted here, I figured it'd be a good idea to post something of this sort. Reason it's been so long since last post? I just forgot to come back, really. I'm not one for writing something frequently, I tend to write longer essays than shorter blurbs. That being said, I've started and put on hold many projects since I've last posted here.

One of my more recent projects being a local multi-player game where you and another player build a team from a list of fantasy units and fight it out in 2D, turn-based combat, similar to the Gameboy: Advance game Advance Wars, minus the building/conquering. It had a decent variety of units, some ~25 units (planned out twice that) with their own pros/cons and castable spells and abilities. The game was planned to be made in a month for a little challenge I wanted to try out called OneGameAMonth. I ended up continually coming up with more and more units so I decided to extend the length of development an extra couple weeks to accommodate it and as a result I held off finishing it within that first month. Ultimately I spent maybe 5-6 weeks on it. There are plenty of things I would like to go back and change or add, but that's for another time, for now I'll just stick to what I started today.

Today, well technically two days ago, I started working on a new game that is going to be a rogue-like RPG with very basic 2D sprite-based graphics. I've played a few of these types of games over the years and I figured it's about time I try making one. Recently I was inspired to revisit a game I enjoyed as a kid Castle of the Winds only to be disappointed by the fact that I couldn't run it on my Windows 7 64-bit operating system. It turns out it was a 16-bit application and doesn't work with 64-bit systems, so I'll have to find some other way of playing it in the future. This also fits nicely with the recent Java programming I've revisited. I've done a little bit in the past and followed along The Cherno's Java Game Programming video series on youtube this past week to refresh my memory. Thanks Reddit for bringing this series to my attention some months ago when he posted his first video there.

Anyways. I'll go into a bit more depth about the game in another post. For now, that's all.

~ RogueTemplar

Long Time No Post

2011-09-23T20:33:00.002-05:00

Let's see, it's been about 4 months since my last post... I've done a bit since then... sort of. Over these past summer months I've worked on various projects.

I've continued work on my RTS (Real-Time Strategy) project briefly which I mentioned in a previous post, it's an RTS made in C# using the XNA framework. I didn't do too much with it, only reworking some of the tools which I will be using/have been using for my Top-Down Shooter of these previous posts, Project Red Rex, as well as cleaning up some of the code a bit. Some day I'll get around to fully working on this RTS of mine, probably just start off, or at least redo a bunch of the code as it's quite messy. The project wasn't a high priority project of mine, it was just something I felt like doing at the time so I started that project.

I worked a bit on Project Red Rex a bit more, though not much has changed since my previous post about it. I don't remember exactly what's changed but not much. When I get around to working on it again I'll post an update about it with any possible changes.

I've also started 4 new projects over this summer.

One being a game similar to Worms... sort of... basically it was to have two sides and you played as a wizard who would sit atop his fortress casting spells at the enemy wizard who was sitting atop their fortress on the other side of the screen. The game was to include some RPG progression, multiple types of spells, possible spell/skill trees to advance further into as well as some items that boosted various attributes of your wizard character. Unfortunately I didn't get too far into that yet, only some basic ground work going so far. One of these days I'll go back to it. I tend to cycle my projects around.

Back in July I had applied for an entry level game programming position and was turned down due to my lack of C++ knowledge. Having used C++ all throughout my college career and even in my last year of high school as well as in my free time, I was a bit confused as to why I was told this, so I started working on some C++ tutorials using SDL. I quickly finished some tutorials with that which I found at LazyFoo.net. Around that time I was playing a lot of Minecraft and as well as playing some Dwarf Fortress and Dungeons of Dredmor for the first time. One thing these all had in common was the random worlds you play in which was something I liked. I had also been playing a lot of Titan Quest prior to those as well which is a game similar to Diablo. So I decided to use that recently learned knowledge of SDL to create an Action-RPG similar to Diablo and Titan Quest with some randomization in the environments like randomly generating dungeons as well as in the loot system. I'm still working out the design of this game but I've been programming this for the past month quite a bit, well actually almost 2-3 months if you count the SDL tutorials which I worked off of and eventually molded into what I have now. I also added in OpenGL support some time in August as SDL didn't cover all my needs, it's a very basic library, powerful, but still too basic for what I need. So far I've only done some engine work and progress so far with that has been great.

Some time about mid-August I joined a group of indie game developers as the lead programmer as they didn't have any programmers available at the time. I joined as lead programmer to work on their very first project as a group and we're still working on this project. Over the past month we've been working on a side-scrolling platformer game using the Unity game engine. Progress has been great so far and I won't really talk about it much other than that as this blog will only include my own personal projects or projects of the team I am apart of, as in one I create(d). So I'll keep other studios work out of this blog if possible. The great thing about this project is I'll be compensated for my work when possible, they're a start up team so no budget right now but after release I will be. I'll also be able to add it as a bullet point on my resume.

With my student loans coming up soon as well as other bills to pay and me still not having full time work I've decided to start creating my on Android games to sell on the Android market to bring a bit of income while I search. I hadn't thought too much about making Android games, but after seeing my Uncle this past weekend he was telling me about one of his sons' friends who had created his own Android/iPhone apps and even made enough money doing so he was able to quit his day job. That convinced me to start working on my own Android games, not iPhone as I don't own one so it'll be difficult for me to create something when I can't test it much, also I don't really like Apple for many reasons. So the other night I was having a hard time trying to sleep, it was something like 6am and I was just lying in bed trying to fall asleep when I decided to start developing for the Android platform. So I started doing a bit of coding in Java for the Android and I hope to have a full game created within a week. Not necessarily a week from yesterday when I started, which all I've done was go through a few tutorials to familiarize myself with the Android SDK, but by the end of next week I hope to have a playable game that I can put up on the Android market. I plan on just starting off simple and then working my way up to more complex games over time, but hopefully I can use this to generate a bit of income while I work on my projects.

I'm now at 3 current projects... currently, the Action-RPG in C++ using SDL and OpenGL, the Side-Scrolling Platformer using Unity for this indie development team I mentioned, and now this new Android game made with Java. This Android game I'm not entirely sure of what I want to create, though I have some ideas and hopefully it goes smoothly so I can get it out there as soon as possible.

Well that's long enough of a post, I'll come back more often hopefully to leave updates, for now, that's all.

~ RogueTemplar (a.k.a Icedmetal57)

Project Red Rex Progress Update 0102

2011-05-24T04:37:00.000-05:00

Although there have been a lack of updates this month, I've still been working on Project Red Rex just as much as I have in the past if not more. Since there haven't been any postings for the past month, there's quite a bit for me to talk about, so I'll just start with what I did in order of what I did first.

Over the past month or so I've created a basic Damage System editor that allows me to make my own damage tables. I'll proved you with a quick example.

	Damage Type A	Damage Type B	Damage Type C
Armor Type A	75%	105%	120%
Armor Type B	115%	55%	130%
Armor Type C	80%	155%	65%

What's the purpose of this sort of thing? Well, all weapons in this sort of game will deal X amount of damage, I'm not sure if I want to include a bit of randomness to it or not just yet, but for now we'll just say each weapon has a set amount of damage, and of a specific type. Basically, all damage from any type of weapon deals damage of any type of damage available on this damage table, then upon receiving damage, all objects that can suffer damage have a specific type of armor based off this table. So say I use a weapon that deals 30 damage of Damage Type C to something with an armor type of Armor Type A and an armor rating of 11. This is a basic damage/armor system, I don't want it to be too complicated and basically all objects that can suffer damage have an armor rating. So to continue with that example using the game's simple formula:

Total Damage = (BaseDamage x DamageMultiplier) - ArmorRating

25 = (30 x 120%) - 11

The reason I want it to be this simple is because balancing between the various weapons I want to put in will be easier for me to handle. So as I mentioned all things follow this basic formula, players/bots (if they're in), vehicles, and I think that's it as far as things that suffer damage, not sure if there will be anything else. So right now this damage system is in, it currently does nothing since I've yet to include anything capable of damaging, aside from the player.

Now onto more stuff... I don't think I mentioned anything about sound effects in my previous posts, but I've added sound effects, at least for the 3 guns I currently have in which are basically just 3 generic types, Handgun, Assault Rifle, and Sub Machine Gun. So what I did was I created a basic audio manager/player that allows the game to load a sound file and play it whenever I choose to without having to reload it multiple times if it's used more than once. The sound effect file it plays is something that's derived from the weapon's data file which I've been utilizing for all things relating to these weapons as that's how I plan on making these weapons, from a template.

As mentioned in the previous post, when the weapons fire the bullets spread a bit due to recoil and other factors that would affect a guns accuracy. The problem I had with the previous version was that I basically used some arbitrary number to determine the direction was fired on, of course with some moderation it wasn't completely random. I fixed that by using some actual trigonometry to rotate the direction the bullet travels based on a random number which is the degree of rotation, or a max amount of rotation in either direction, left or right of the barrel. That having been said, I also used this to create a better system based off an old shotgun bullet count system I had from a previous project. What this means is I can create shotguns with ease, in the data file I just have to say I want this gun to fire 6 shots at once and it'll randomly spread them out based off that bullet spread to give a shotgun effect.

Let's see... what else? Right so I utilized a couple editors I created from my RTS (Real-Time Strategy) game project I was working on in the past. I used a Tileset generator which loads an image that you browse for from your computer, input a few things like width and height of tiles, and number of tiles in the x and y direction, though I probably don't need the inputs for the x and y direction counts. It's a basic program that does the job just fine, though I'll have to "re-create" it to work better for a few updates I've made for the tileset system I've got in Project Red Rex. Another editor I'm utilizing is something to go with that Tileset Generator, a Tile Map editor. Basically you load a tileset created with the Tileset Generator then create a layer or two, or any amount really, and start placing within the viewport where you want to place a tile. Essentially it's a basic map editor. Right now all you can only place a tile one by one, as in left click to place there's no left click and drag to create a rectangle of where you want tiles drawn, or a paint bucket filling feature, I'll probably work on that later when I work more on actual maps, but there is an erase button which is just like the click to draw function except the opposite.

Screen Shot of Tile Map Editor

So... with these two new editors to be added to the collection of content editing tools I've got it so the game loads a map along with the tileset it utilizes, which can easily be swapped for a different tileset, of course it could have some weird effects on the map since not all tilesets will look alike. So to go along with this map loading in game, I included an actual scrolling camera that scrolls with the player, though it currently isn't set up to "follow" the player just yet, maybe it will be by the next time I post on here.

So as of this most recent update I've probably worked on this game more so than I have in the past and over the past week I've probably worked on it like 3 or 4 different days, which is definitely good. I've been finding myself more motivated lately to work on this game. I worked on this game last night, and then when I went to bed, I wanted to continue working on it today and so I did. In the past I would just randomly find motivation to work on it. But recently I've gotten more motivation which is great. Maybe that was the problem with my RTS game I tried making a year and half ago, I spent many hours over basically a weekend and over that following week working on it. I spent too much time on it right away that I got tired or bored of working on it and so I stopped. Maybe. I suppose I should continue with this approach with my future projects, start off slow so I don't get tired of working on it early on or anything like that.

~ RogueTemplar (a.k.a Icedmetal57)

Job Searching and Project Red Rex Progress Update 0101

2011-04-28T23:33:00.000-05:00

Well... as I've already mentioned in a previous post, I'm not much of a blogger or writer for that matter which is why there haven't been any posts for a couple weeks. So lately I've been a little busy doing some job searching, looking for some kind of programming position, and have received a few offers here and there, one of which seemed fairly promising but I was turned down, unfortunately. Whether I get a job or not anytime soon won't affect my progress on this project of mine, which is as of right now called Project Red Rex, named after a little red T-Rex character I created when I was messing around with changing application icons, the ones that sit at the top left corner of application windows.


Red Rex Logo

Anyway... here's a little screenshot of what the "game" looks like right now.


Screen Shot Update 0101

As you can tell, there isn't much to it right now, most of what's in it is not exactly too visual. Right now it can load a weapon data file which includes all sorts of data including weapon name, projectile image, projectile speed, base damage, damage type, reload time, fire sound effect, etc. Overall there's some 20+ pieces of data that describes each weapon. So what this game can do in it's current state is read from a weapon's data file and explain to the game how it works. Like right now you can fire a clip or more of ammo, reload at a rate based off of what the data file says it should, fire at the rate the data file says, with a little bit of bullet spread, and play a sound effect for when the weapon fires, also mentioned in the data file.

In this game's current state, there's nothing network related, that's something I'll work on at a later point once I get more of the basic game in there. You've probably noticed from that screen shot above that there's some text in the upper left hand corner, that's just a temporary HUD (Heads-Up Display) that I'm only using for debug related stuff. Also it says in big letters in the middle of the screen, "SCREEN 1". I have that there to differentiate between multiple game screens which a "Screen Manager" manages to make sure the game only updates, draws, etc. a select few, or just one, screen(s) at a time without having to recreate each screen every time you want to access the menu, for example. As for that little red circle entity, that is my place holder player sprite.

All of the things I've mentioned thus far about this project, Project Red Rex, I have been working on for the past month or so, usually a few hours for one or two night(s) each week, which is at a pretty slow rate. But tonight I've actually been working on something new, along with fixing a few bugs, as I've been writing this post, which has been for about 2 and half hours or so now... I've been working on a basic editor application tool that I can use to create damage systems, which is really just a table of the different armor and damage types that will be in the base game. I guess the purpose of this tool is so people, including myself, can creating custom damage systems which will affect weapons, and whatnot. Also I wanted to get a bit of a head start for when I start creating some of the more complex editing tools.

Well that's it for now. I'll continue to post more updates as I go along, hopefully more frequently than I have with the past few posts.

~ RogueTemplar (a.k.a Icedmetal57)

Long Posts and A New Project

2011-04-05T22:46:00.006-05:00

So this post was originally going to be a part of my previous post, but since it was pretty long I decided to split them up. From the post editing page, it doesn't look like too much, but once I preview it, it looks like I've written a lot more than I actually did.

I have been working on my own personal project recently, though my team, Last Day Studios, will continue to create games together. I've been working on a 2D game engine coded in Java, I'm still in an early stage of it, but it's coming along nicely thus far. After looking around on the internet, though with not too much research, I've found that there aren't a lot of 2D game engines out there because they're generally simple to make compared to a 3D game engine and they're usually made for a specific type of game too. For example, RPG Maker is used for RPGs, though through some modification in the coding/scripting it can be used for other types of games, but it's built to be used on RPGs only. Another 2D engine out there is Game Maker, but it's far too simple for my programming needs, which is why I've never really liked it compared to like XNA using C#, or more recently Java, which is a new language for me. Some of the main reasons I'm using Java instead of some other language is: it's been easy to learn so far, it's fairly easy to use, I've always wanted to learn Java and this gave me a good excuse to learning it, also it crosses many platforms.

With all that being said, this engine of mine I'm building using Java to be a 2D engine that will be used in a Top-Down Shooter type of game similar to the Battlefield series in how it plays, or at least that's how I envision it. Right now there aren't a whole lot of Top-Down 2D shooters out there, aside from say your Galaga style game, but none in the similar competitive nature as the Battlefield series or many of the 3D First-Person Shooters out there. I wanted to capture that type of gameplay but using a Top-Down perspective. Of course this won't be a Battlefield clone just in 2D, which alone can be different enough as a game as it's own. Also, I plan on releasing all content creation tools that I'll be making with this game, map editor, weapon editor, class editor, vehicle editor, and any other sort of tool I create to make modding simpler. Of all the different types of games out there, one thing I know that brings people back to games that seem like they could be stale after awhile are the mods that are available for that game. By allowing people to create their own weapons, maps, vehicles, etc., with ease, you could end up playing a completely different style of death-match. So far I plan on making this game with a modern combat theme, but it could easily turn into a Star Wars themed shooter, or a medieval death-match game with knights, archers, footman, etc. I want this game to be a modular style game, because those are the types of games many people love, like myself. As for available game modes, I plan on this being a multi-player game, though I do hope to get bots in there sometime, but player versus player gameplay will be my first priority and I can always create some kind of single-player campaign later on through some kind of expansion if things go well.

As the weeks go by, I'll try my best to post some status updates on this project as well as screen shots, videos, etc., if any, because I haven't been posting much on here and this will give me a chance to get feedback from people early on.

~ RogueTemplar (a.k.a Icedmetal57)

Laziness and Little Hellraisers

2011-04-05T22:41:00.000-05:00

Well, I've been a bit busy lately... or lazy, either way I haven't posted much on here. I guess I'm not much of a blogger or writer in general for that matter. To start things off, I've graduated from college, and have been for a little over month now. Upon completing school, my team, Last Day Studios, has also finished an "Alpha" version of Little Hellraisers, the project I mentioned in my previous post. Well... we finished that project the day before graduating and haven't worked on it since, though we're not sure if we'll go back to it at least any time soon. Since it was created using the wonderful engine, Unity3D, it allowed us to create a web playable build, as in you can play it within your web browser. I've uploaded it on another site which I'll use for any sort of demos, trailers, etc. that I can't have up on this here blog site due to the lack of a file management system. If you'd like to check out the demo it can be found at http://pixelatedgravity.webs.com/ under the Projects section. I'll upload the trailer we made for it as soon as that host allows me to, which they have a 7 day wait period before uploading videos upon creation.

~ RogueTemplar (a.k.a Icedmetal57)

Engine Switching for Senior Project

2011-01-19T23:58:00.001-06:00

Lately (the past two months or so) I've been busy working on my senior project which is a 16 week course that involves myself and my team of 5 other people making a game within that time. As I mentioned in my previous post we were making it in C# using the XNA framework. After the first half of the project (the first 8 weeks) we realized how difficult it was to create something in the scope of what we wanted with our limited experience and our limited time. The day I got back from my two week break from school, which was after the first 8 weeks, I sat down with my other programmer and we realized that we were running into too many problems. If we continued down that path we would most likely not finish the project or even come close due to some major problems with loading our assets and using said assets.
So we decided right then and there, after discussing with the rest of the team, that we wanted to switch to Unity3d which from what we heard was easy to use. The other team in the class was using it so we were able to see what they were capable of, and so we sort of figured that we should use it as well and try to make a better polished product with less time, given that Unity3d was so simple to use. After about the first week of using it, it was the first time for all of us, from what I'm aware of, we realized that it was very easy to use and that we were able to recreate just about everything we had done in 8+ weeks in just that one week. Either we're just that talented, or Unity3d was just that simple to use. For those noobie game developers out there looking for a starting point, I recommend using Unity3d, if you want to make a fully 3D game. Though if you're like me, you would probably prefer something a little more programming oriented and challenging. In that case, XNA is a good place to start, it's definitely easier to work with than DirectX or OpenGL in C++ for example, but it is still more challenging than Unity3d, and you'll probably have a larger sense of pride for what you've created over Unity3d because you probably put more effort into it. Though, that's just me.

Hopefully I'll get around to posting more about my endeavor's and whatnot now that my project is less burdening and I'm getting closer to graduation, five and a half weeks actually.

~ RogueTemplar (a.k.a Icedmetal57)

Introduction / About Me / My Recent Experiences

2010-11-05T20:38:00.007-05:00

With this blog, I plan to post updates and info on my projects relating to game development, and possibly many other things related to game development or video games.

I'm currently in my last semester at DeVry University in Illinois, the Chicagoland area, more specifically, and I, along with a few classmates, are currently in the early stages of developing our senior project due at the end of February. Personally I have been the lead programmer for our small team and have done a bit of programming in my free time, while creating my own personal projects here and there. I have been programming for around 6 years or so, most of it as a hobby, and now I'm hoping to make a career out of it. As I mentioned, the purpose of this blog is to post updates and info relating to my projects, both with my team, Last Day Studios, and of my own personal projects. I will even post some of my older work at some time.

Here's a little time line of my experience within the past year. Why just the past 1 year? Because it's been some of my better work, and is most recent to seeing my experience, which as I mentioned, I'm only a college student.

Recently within the past year I have created a 2 dimensional top-down zombie shooter for one of my school courses, created within the XNA framework using C# as the programming language, which if you're new to programming, especially game programming, I highly recommend you check out XNA, it's a really nice platform.

After creating that top-down shooter, I started working on my own RTS engine, though I only worked on it for a few days, I still got further than I thought I would, I actually had something decent for having only worked on it for like 3 days. That RTS engine was also being programmed in XNA. Why? Because I really like XNA for many reasons, and so I use it a lot. That little project of mine was only intended to last me a couple weeks because at the time it was my winter break, which was only 2 weeks long, but since I got busy with the holidays and whatnot I put an indefinite hold on that project. Though some day I hope to go back to it in the future, as well as redoing my top-down zombie shooter, hoping to put it on Xbox Live as a community game, which is one of the great things about XNA.

After working on that RTS project of mine I kind of went on a programming break for the next 2 months, until around February and early March. In late February and early March I, along with my team members of Last Day Studios, worked on another 2 dimensional top-down shooters, this time we created a multi-player tank deathmatch sort of game, which we created with the intention of bringing with us to the Game Developers Conference (GDC) in San Francisco that March. With only having worked on that game for a week before the conference and the week we were in San Francisco the following week, we managed to get some basic playability which was actually sort of fun. Though we never did go much further than basic drive around and shoot at each other on an open map, which was just a field of grass, the game was actually some what fun, especially when testing with 4 people. After our visit to GDC we did not return to that project, unfortunately. Like the other projects I mentioned thus far, this was also created in XNA, and again, I hope to some day finish this project of mine.

After that little tank game we created in 2 weeks, I have been on a break, pretty much since, though I have done a little bit of programming using the engine RPG Maker XP, which is what got me started with programming games. But other than that I haven't done anything serious since that tank game, which really had no name, from what I can recall.

That leaves us with what's going on right now. Right now, as of last week, we have started development in creating a 3 dimensional side-scrolling beat 'em up similar to Castle Crashers and Scott Pilgrim Vs. the World for our senior project, or our final school-related project, also being created in XNA. Because we are currently working on this project, which we plan on tacking onto our portfolios, I don't want to include too many details until further in development, also because I just don't want to reveal too many details about it just yet.

Well, that's a bit about me and my recent experience with game development as a lead programmer of my team. After having written this, you can probably see why I didn't go through all of my years of experience, even though I currently can remember the majority of things I have done in my past relating to game development. It would take me a while to write it all. That being said, any future posts I make, I won't plan on making them this long, though because this is my first one here, I can't exactly promise that.

~ RogueTemplar (a.k.a Icedmetal57)