Americana Engine - Into 2016

"Glad to see it's still alive and kicking."

For months I have considered on exiting the game development market; I have previously made future plans on the basis that after my departure from AD, the game was well on its way with a new Kickstarter and a beta out at the end of 2015, with my efforts gone uncredited and my game engine completely unnoticed since its switch over to Unity.

It appears this was not the case, however, and I have chosen to resume production after looking through this month's statistics.

My career as a software developer may very well depend on completion of the game engine (as well as an optional game) and released for others to see; as many companies take working projects into their hiring considerations, I have determined that it is my responsibility to bring usable quality updates on a timely basis if I want even a remote chance at getting hired.

Upcoming in 2016: (not a complete list)

• Porting to HTML5 - to make it more accessible to web and mobile devices, and also to serve as a means for others to present small demos without requiring the base game.
• Possible open-source release on GitHub
• Customizable GUI (what kind of information you can get, however, will be limited)
• Project Website adjustments

Americana Engine: Redesign

Minor (but important) differences in the script syntax from Beta 3 -> 5, especially for branching statements.

A number of changes have been made to the underlying code as well as scripting format in order to both improve readability and performance. Compiled maps from Engine Beta 3 or below* may not be playable since a lot of crucial triggers will not work properly, making Beta 4 the last official version for backwards compatibility. For more information on what may appear in Beta 5, see the changelog.

Brief list of changes:

• All resources now load outside triggers instead of as actions.
• Strings are now compressed for standalone maps
• Map variables now include strings as well
• Variable pointers are used at the beginning of a variable instead of extra values on an action
• Jump Actions now made into If-Then statements by default
• Locations were reworked
• A lot of internal code was refactored

Next:

• Faster map reloads
• New GUI for terrain editing

Development Comments:

Loading resources were originally placed in triggers since there was originally enough of them would cause lag if they were placed at the beginning. After some consideration, not only does sounds and resources loaded in the middle of a map cause a few inconsistencies, they can also break some parts of a map if a trigger that loaded them happened to be skipped over for some reason, and another trigger loaded them instead. Additionally, loading in the middle will also lag for the time the texture or sound loads in realtime, and is more significant if the file being loaded is large. It's not going to make a difference in compiled maps, since all of the data is loaded at the beginning.

To centralize the location where all resources will be loaded, all resource calls are now outside triggers, and there should now be no question as to where these statements can be placed and if they will run or not.

Jump Actions were implemented because of the way the script was interpreted; You needed to get to a line, and there's a trigger to do so. Originally the jump statement required a number and optionally direction (up or down). During early stages of beta testing, users had difficulty with figuring out where these statements were jumping to, and most of the time was spent fixing issues and having to readjust the code every time a line was added in the middle. I also did not want to promote bad programming practices, and this one did it with spaghetti code. The problem was resolved with conditional statements instead. Jump to line is still there, just using labels now.

A bunch of code was refactored (and placed into separate source files) since it became progressively harder to add new features, and even more so to maintain. Prior versions placed most of the map rendering and editing functions in a single cpp file, and class definitions in several other header files. It was nearly impossible to split the main cpp file up as class methods pulled data from global variables. In larger teams, the same cpp file was being edited, which can get extremely cumbersome as all revisions from each commit had to be merged and reviewed so that it didn't cause conflicts and/or errors in the source file, as well as other classes referencing it.

The Battle Simulator in previous game engine releases is not compatible with the current engine version and will not be included in release builds, however source code for the map will be available as a separate download for anyone interested in updating it.

Americana Engine: Beta 4 Updates

My gear setup on Foster when running the battle simulator.

Americana Dawn has since switched over to Unity and is moving right along on their builds; on my side I have focused on engine development since I need my version working as proof of coding and game development experience. The portfolio maps still occur within the same universe, however, and will share the game's continuity, but I'll have to find or make some assets first. I am dedicated to providing a detailed development process, and will include any major changes and commentary behind them.

(In the month since the engine project page was put up, the number of people visiting it was a lot lower than expected. I may have to break the convention of not actively promoting material and reappear on social media sites to get this noticed and get further up search engine rankings, as well as relying on chance that someone relevant will find it.)

Updates

The following main features were updated in Engine Beta 4 (Released 7/21/15), emphasizing more on character customization rather than straight-on gameplay:

• The status page has been slightly retweaked compared to the original concept image on the Kickstarter; tabbed interface will now display inventory items (to equip gear) as well as skills and passives on the character instead of using separate menus
• Navigation in Status screen now completely functional; See notes below
• Passives are now displayed when selecting an accessory, and Skills when a weapon is selected.
• Carrying capacity was moved up to main statistics
• Caps on maximum inventory greatly increased.
• Mastery gains readjusted

Simulator Changes

In order to test all of the above features out, The simulator has been expanded to include the following:

• You can now access the menu and change your gear via the Status Page in between battles. Your inventory contains a large amount of items to setup your characters however you so choose, and to experiment with various combinations and statuses. Around a dozen different weapons, accessories, and consumables are available in the simulator. I do not know how much variety AD has in terms of accessories, but I can tell you that this place has plenty of stuff.
  • libcurl will be used to automatically update the items/skill database for the simulator as needed; this should keep game engine re-downloads to a minimum (at least until a major update occurs) and keeps everyone on the same version level, but overall don't expect any of the weapons here to be fairly balanced at all.
• Lucille has her own portrait in the menu when available, based off of the concept piece of her. There was no official vertical portrait for Lucille, and she's too far down, so there were two options for this, to recreate it myself, or to find an artist to do this. I picked the former for now, but only as a placeholder. The configuration for non-human type characters hasn't been fully defined yet, so Lucille cannot equip weapons, but can hold 4 accessories and twice as many items.
• Some new enemies are planned to be made based on those in AD that were still work in progress.
• The help file has been moved to the Journal in order to explain most concepts.

Other Notes:

Despite this post taking into account updates from July 10th, this post was originally created on June 28 and will be dated as such.

Navigation between tabs are used with left/right keys. (X) on any item in your inventory will transfer it to the character if possible; (X) on any item on your character will send it back to your inventory.

Skills are attached to weapons (along with a limited number of character skills) and what you equip for each character determines what attacks you can use. You can slot up to two (or more) weapons and accessories, so you'll have a variety of skills at your disposal, and you can get more variety over the course of the game. I'm still trying to think of three/four skills unique to each weapon, complete with descriptions and such.

Weight is represented on an item as 'Wg' (using the same abbreviation as in Fallout games, where the idea for this came from) until I can think of an icon for this. It's not related to lbs or volume, they are instead weighted solely for balance purposes in a battle.

Mastery also works a bit differently in this version. You get mastery for weapon types used in battle, and when you level up it increases your stats depending on the weapon, which may allow you to use more advanced skills. The only difference in this game is that at high mastery levels it also gives an overall percent bonus towards those stat(s), so you can either focus towards skill variety or strong stats in one area.

I did not add status effect support in the initial release of this version, as I am currently working on a way to add them as needed instead of hardcoding them in the game engine (as well as Journal support).

WIP: Americana Engine Beta

Project page styled with a (modified) legacy AD template

With a growing amount of software development jobs favoring a portfolio of prior work over just a resume, I have proceeded to showcase a few pieces of work of my own.

Summary

The Americana Engine is a ongoing game engine project started in 2013 running under Windows. It was originally developed for Americana Dawn to get past a lot of the limitations that RPGMaker had (which the game was originally developed in), adding a higher resolution, finer sprite control (not having to rely on parallax mapping), map portability, and adding native functionality for the large-scale battle system.

The Lead Programmer's version of the game engine (including the editor used to make maps) is now available to the general public, adding a number of enhancements and fixes complete with development notes and custom maps, and is being actively maintained. More information on this can be found on its project page.

Brief Notes: (at the time of writing)

• The engine is currently in active development, and may contain bugs or unfinished features. You are free to discuss it or report any problems, questions, feature requests, etc. at forums.bitbonton.com for now. If you want to directly contribute to the codebase, send a email to me directly.
• Scripting documentation and tutorials will be provided in the near future.
• No assets will be included except for those used for in-game GUIs.
• The engine can run maps from Americana Dawn with limited support, however you will need to provide those maps. Maps previously available to beta testers are included in this zip file (for demonstrating the engine as a portfolio piece), with a number of improvements.

Handling Diagonal Movement in Tactical RPGs

Ignore the Battle GUI - it is a mockup and therefore has incorrect information.

Normally Tactical RPGs do not allow diagonal movement, however I propose a system that handles this while factoring in obstacles.

While designing the war system in Americana Dawn, there were previously a few issues about the move range on a character; because the shoot distance is calculated by absolute distance from the character (instead of grid squares) it would create a disadvantage for some units. Also, it creates movement range more like a circle.

If a melee attacker was hit from a diagonal, it would normally take two turns for it to reach the target. The extra turn is a huge difference - the attacker that could otherwise defeat the enemy may not survive the second turn.

I had a few choices, either restrict attack range, or include diagonal movement. Moving based on absolute distance was considered, but it was ruled out since it can get messy at times and might not find the optimal route when tiles are weighted. So a diagonal is calculated as 1.5 movement points. (It might be 1.4 movement points later if the game requires more precision.)

But this is not factoring in the weights of the various tiles, so this is achieved by taking the weight of the diagonal square that you move to, plus the two adjacent squares that you cross getting there, and dividing by two. Thus the formula is:

Movement Cost = (Tile Weight for upper right tile + upper tile + right tile) / 2, relative to the character.

There's situations where a diagonal move takes up more move points than moving two spaces instead, but the game automatically calculates the shortest distance to a tile anyways so it isn't a real problem.

The drawback is being able to get to normally inaccessible tiles via a diagonal move. Consider it as an advantage - the 'creative designing' process should ensure this happens only when it needs to.

I think more of the creative designing should be the AI script for these battles, which is mostly based on the enemy commander's personality, although it usually looks ahead at least a turn and makes decisions only based on what it can see, and will find cover and ambush if possible.

Fall 2012 in Concepts

Things change - people come and go, and in the long run, the only thing that matters is the big picture - there's a whole world to see and explore. As well as a handful of close friends to share experiences and stories with.

Fall 2012 in Concepts takes a different approach to images - it focuses less on just displaying pictures and places emphasis on various concepts - such as the programming side, covering a variety of topics set for this semester. Although originally started in 2012, this page contains info that goes well beyond that.