Akradion Demo 1 Released!

After a short delay, I've finished the first(only) demo of Akradion! You can get it on the games page, as always. I don't have much to write, since it's only been a couple of days, but I did make a few changes:

• No more than 30 balls can exist on screen at a time, in order to avoid stuff like this:

This is from when I was stress testing the split powerup

• Added an ending message
• Added a help message that can be toggled with H
• Got a better font
• Fixed an issue in Windows builds that caused massive ball acceleration
• Made a new title image
• Added a new sprite for the volatile powerup
• Added a new sound for starting the game

I think that's it. Have fun!

Akradion Update 5

Changelog:

Akradion

• Levels are now loaded from files created with Tiled Map Editor. This makes building levels so much easier.
• Levels can define the colors of groups of bricks.
• Made the ball's "hit a block" tween more consistent.
• Added a powerup that doubles the number of balls in play.
• Made some new sprites for powerups.
• Added a powerup that creates volatile balls. These balls explode everything they touch, but accelerate extremely quickly.
• Changed firing mechanics. Left-click fires a ball left, right-click fires right, and middle-click fires straight up.

DFEngine

• Made half of a change that will probably save me tons of pain in a few months.
• Scripts can now receive keyboard input.
• Scripts now actually display their error messages.

You might be wondering what the 'half change' listed for DFEngine is, and why I only made half of it. Wonder no longer! This change relates to scripting, specifically how I implemented Lua in my engine. When using Lua, you have to manage a lua_State, which represents the environment that a Lua script runs in. With the state, you can add, remove, and otherwise manipulate data. However, transferring all of that data from one state to another is very difficult and slow. Thus, the best way to run multiple scripts that use the same data is to run them inside the same lua_State. This is the sensible way of doing things, which is naturally not what I originally did. When I added Lua, I built a new state for pretty much every script I needed to run. 

Now, I'm trying to bring everything back to a single state. There are a few other benefits to this, but moving data around is the biggest one. For starters, once I finish this change I'll be able to fully remove the storage components from the game. Next, I'll be able to use any data type, not just numbers and text. I'll be able to make full lists, structured hierarchies of data, and more. Right now, keeping track of a set of things is all but impossible, but this change(when finished) will fix that. 

Right now, only the main game object can take advantage of this feature, so only global script-defined variables get the special treatment. The second half of the change will apply this to the individual entities in the game as well. However, I'm not adding that to the engine until after I finish Akradion. Akradion is rapidly approaching the same tipping point that AMAZE reached, where making changes gets harder. Thankfully, since Akradion is more sensibly designed I won't have to worry about making large changes to the gameplay, just the underlying engine. Anyway, this just means that the engine probably won't be getting many more updates until Akradion is done.

Speaking of which, I have some good news: The first(and only) demo is almost done. I could release it today, but I still have some things that I want to add/change first. I'll probably either release it this weekend, or early next week. Either way, it's coming. The game itself is actually quite close to completion, I think. I doubt it'll need more than another couple of weeks to reach completion, thanks in part to being so small. Still, it's difficult to believe that it's only been 2 months since AMAZE was released!

Akradion Update 4

Changelog:

Akradion

• Added a title screen
• Fixed a ton of physics glitches
• The bat can now be used to alter the ball's direction a bit. This makes it possible to aim the ball at bricks(somewhat)
• Added indestructible walls
• Added exploding bricks. When hit, they destroy other bricks in a 2-block radius
• Added a nice animation for when levels end

DFEngine

• Made a bunch of minor tweaks to the codebase to make it easier to work with
• You can now directly add forces to physics objects in scripts
• Added GLSL support
• Global data can now be tweened by giving the entity id -1
• Global data can now be forced to immediately update by giving the entity id -1
• Started working on getting a cross-compiler set up

Oh man, this post is really late! Sorry about that. I've been quite tired recently, and finishing this post up is proving to be much harder than expected. Hopefully things will work better next time. The game is still coming along well, and I got it running on Windows, so no issues there.

Akradion Update 3

With another productive week over, I'm feeling pumped! I haven't felt this good about a project in a very long time, maybe even as far back as the old rpg project. With any luck, you should be able to expect a demo some time in the near future. If it doesn't come next week, it'll almost certainly come the week after.

Changelog:

Akradion

• Added Powerups! Currently there are 3: extra life, speed up, and speed down.
• Added support for multiple levels! Clearing a level of bricks now takes you to the next after a short delay.
• Made things a little bit prettier.

DFEngine

• When creating physics components, you can now set collision masks. Basically, this lets you control what the entity can/can't collide with.
• Added timer components.
• Added some basic sound support. No streaming yet, and only wav files can be loaded, but it's a start!
• Added sprite support. They're not as advanced as they were in AMAZE yet.
• All game assets(sprites, fonts, audio, etc) are now loaded from lua scripts.

Timers:

Now that objects can have timer components, a whole bunch of new possibilities have opened up. Also of note is that switching from AMAZE's 'delay' function to an asynchronous setup is intentional. Had a system like this been in place to begin with, that one crash bug from the factory stages would never have existed. Of course, this engine alone is a massive improvement over anything AMAZE was capable of, at least on the scripting side of things. Anyway, I've started using timers to try and add some more animations to things. Bricks now 'pop' a little when hit, for instance.

Sound:

Another feature that's improved the game tremendously is the addition of sound effects. I've started putting sounds in early, because putting things off in AMAZE was a terrible, terrible idea. Specifically, it made adding new aesthetic features to the game's levels extremely difficult. Rather than naturally adding things as I went along, I ended up having to go back through every level just to add these sorts of things, and then test them all again.

Finally, I should address the asset files. In the previous iteration of DFEngine, I spent lots of time and energy designing specialized asset files for my games, and yet this time around I currently only have support for regular image/audio/font files. In short, the specialized assets won't be going away, but I've realized that it really makes no sense to require them. I won't be adding them during Akradion's development, but they'll probably get put in some time this summer. The problem with only having specialized assets is that every time you make even the smallest change to the base file, the whole thing needs to be recompiled. This makes rapid development and testing much slower than it would otherwise be. Thus, I think it's best to use regular files when working on a game, then package them up once I'm ready to put up a build. That way, I can get the best of both worlds.

Akradion Update 2

Changelog:

Akradion

• Added a score counter
• Brick score values are set individually, allowing the creation of hard to reach high-value bricks.
• Added lives
• Launching extra balls can be done at any time, but each one costs a life.
• Added Tough Bricks, which take several hits to break.
• Smoothed out ball movement a bit.

DFEngine

• Added a 'draw' script callback, which occurs when the game redraws itself. 
• This is for more complex display stuff that the graphics component doesn't cover, like text
• Added global script variable support
• Added the ability to retrieve and modify object data from any script, given the object's id
• Viewports now only display what the game wants them to, but scale the output as much as possible and letterbox the rest.
• Mouse coordinates are now a percentage, rather than an exact pixel position. They are also clamped to the game view.

This week didn't seem too productive, but I guess I was wrong! It's now a whole lot easier to get work done thanks to some of the engine upgrades

Global Variables

Currently, this is one of the best ways for objects to all share data. All I had to do was give the game object one of the same data storage components that all of the entities use. Now, the game can hold important information, like lives or score.

Data Retrieval

This is really useful. Basically, it lets any object access another object simply by knowing its' id. This means that:

1. Objects can make new objects, and give them specific info that they have (e.g. spawning something at their current position)
2. Objects can exchange ids to always stay in touch, and can send signals and other data between each other.

As you can see, this is pretty sweet, and is another great feature that makes DFEngine's second incarnation easily beat the original in terms of power.

Views and the Mouse

This change should've been here originally. Now, the view only shows what the game wants, and makes this as big as possible without drawing things outside of the screen. The letterboxing and clamping mostly exist to prevent cheating and confusion, but they also make fullscreen look much nicer. Next, I'll need to make the game's view more dynamic. Being able to smoothly switch into a widescreen view for a cutscene, or zoom out for an impressive set-piece would be pretty sweet.

The Game

It feels like I can do so much now. I think within a week or two I'll be able to focus on adding tons of content, and then I can finish up Akradion. That would be impressive, and I hope I can finish it up by my birthday of June 25th. That's not a hard deadline, but I'm feeling pretty optimistic about this.

Making games is fun again!