Actors

Lots of progress made... First up, basic actors.
For now, I just have a basic soul actor, a floating orb:

The soul actor also has a lightning attack:

Every actor has a path they walk:

So battle routines exist now, and the game controller vibrates a little when the player is hit, or when they player hits something.
However, I'm not entirely happy with the feedback and sounds associated with the battle routines.
This is an area where the player will be spending a lot of time, so it has to be perfect.

//ThGrk

Editor Upgrade & Input

Work has been done to the level editor.
I've expanded it to include up to 72 buttons, and I added in a properties window that implements an input component that accepts keyboard input.
This allows me to change things for the levels in the editor, without having to manually change the level code.
This way, the editor handles all the code formatting for me, which reduces the work I have to do as well as the possibility of errors.

Here is a shot of the editor's new layout:

Here is a shot of a level's properties window:

The property window was required before destinations could be added, which must be written before actors can use them to traverse levels.

//ThGrk

Level Editor - level up!

I just completed modifying the level editor so that I can create level faster. Much faster.
Here are 3 levels that I've completed in the last 3 hours, some were built from scratch, others were modified from existing level data:

The level editor held up quite well creating these levels.
Now I'm on to a very exciting part of the game - enemies, the battle system, and the fx manager.

//TheGrak

Complex Housing

I also wanted to share a shot of how the level manager handles more complex housing structures.
For example:

Level Manager

Today I completed the cleaning and polishing routines for the level manager.

The level manager is in it's infancy now, but basically it's a class that - among many things - creates transition tiles and buildings from level data.
The transition tiles are the tiles between different land tiles that help to mask the tile grid.
The buildings include the building walls and ceilings, which are constructed from floor tiles.
So, I need only to provide basic land tiles and floor tiles (with doors for buildings), and the level generator takes care of the rest.
This also allows me to save levels in a 'compressed' format, and let the level manager 'decompress' the levels using the polishing routines.
I don't necessarily 'need' to save the levels in a compressed format, but I may do so just to get over a pesky xbox 360 bug with lists longer than 9000 items.

Here is an example of a compressed or barebones level:

Here is what that level looks like decompressed:

It's a difference of about a 1,000 sprites: compressed @5k, decompressed @6k.

Game objects have an ID now, so they can be grouped together and used in different ways.
For example, ceilings are grouped according to building now, so players only see into the building they occupy:

I'm really excited about the separation of polishing and cleaning a level from generating a level, because that means I only need to write routines to generate bare bones levels, then I can pass the bare bones level to the polishing routines.

//Grak

Technical Success

Lots of technical advances in the last few days.

I started working on the building constructor, which will create buildings and destroyed buildings based on floor tiles.
Right now it removes duplicate floor tiles, and randomizes them.
The building sheet has also been planned out - there can be 14 different building types. I need 5.
Then I faced a challenge dealing with the tearing of tiled sprites, mentioned here.
I think I have resolved it, but we will have to check on others machines.

Then I changed one single line of code and the levels became persistent in RAM.
This is pretty cool, because you could destroy part of a town, leave for resources, then come back to find the townfolk repairing the damage.
So I stress tested it and put 55 persistent levels into RAM all at once. RAM is around 250mb.

I also figured out to simulate an actor of the game persistently in memory, so there could be autonomous NPCs roaming around causing events.
Then I transferred everything to the xbox 360 and watched as the code thrashed with the garbage collector, pausing the game noticeably every second or so.
In return I refactored several hundred lines to not create garbage. It's pretty easy if you subscribe to the simple rule of: do not create new instances outside of a field, or constructor/load method.

Then I battled with arrays and lists, and became aware of the difference between array.Count() and list.Count.
One is a slowish method, which returns a value. The other is a value of a list.
If you use .Count() in a loop, you can expect that loop to be very slow, because it's calling a slowish method every. single. time. through the loop.
Not realizing this, I spent a few hours with my game on my xbox 360 narrowing down what was blowing up the update and draw loops.
I ironed out several hundred more lines of code, switching from lists to arrays, then back to lists, then back to arrays.
After you code and recode a particular section 5 or 6 times, you start to get a feel for what works there.
The final touch was adding ceilings back into the buildings, which was slowing the xbox down terribly.
This newer routine is much faster, and the next step is to add and ID to each game object so I can group them.
Then only grouped ceiling tiles will become transparent, which means the player will only be able to see into the building they occupy.
I also reworked the zdepth sorting to allow for more specific layers, for example there are layers for clouds and atmospheric effects now.
So, not really any visual updates to show, but lots of fine tuning of the engine behind the scenes.
Here's a new screenshot!

Editor and Building Work

Lots of progress.

First up, I switched out the main menu screen, so it looks a little nicer.

Then I added in buildings. But not just buildings, I added in destroyed buildings as well.
Buildings can be blown up partially, or completely. Specifically, walls can be blown up.
When a standing building collapses, the ceiling collapses as well, creating additional debris (not shown):

Ceilings automatically become transparent when you enter a building:

Finally, I worked on the editor a lot. I did many things, but one important thing I did was to add a shortcut to zoom out for a nice level screen shot:

You can also see the editor main menu items in the above screenshot. Glad I finally figured out what the main menu of the editor needs to be.
Now I can start filling in the missing sections and working towards a 'complete level'.
I also dissected how much RAM the game is currently using, and set estimates/projections on how much RAM the game will use when operating at peak.
Everything is within expectations, and the game should never dip below 60 fps.
Very soon I hope to have enemy and ally actors in the game, giving the player something to interact with.
I've also defined what the game's "Demo" is, which has helped me to put the game's main storyline in a better perspective.
The Demo will be free, the Game will cost a few dollars (less than $10) and be available for xbox 360 and PC, thru Steam.
I'm planning to use the Steam Greenlight feature, and publish on the xbox via the Xna Creator's Club.
Depending on how Xbox One and PS4 handle Indie development, I may port to those consoles.
However, after becoming familiar with the limitations of the xbox 360, I would probably prefer to scale the game up to match next-gen hardware.
We'll see where the road paved with good intentions takes us.

//Grak