The A-Engine: A new Beat 'em Up game engine

[A-Man]

I am sorry, but I can't give a date as I really don't know myself. I recently started a devblog which you can check in my signature, and I've been posting there in detail regarding what I'm working at fairly often. Once I am close enough, I am sure it will become clear.

[A-Man]

Edit: An example that shows how shaders can change how your graphics look:

[A-Man]

Spoiler (Click to View)

It has always been an increasing function of flexibility plotted against complexity when it came to developing tools; thus with every additional feature, you can only expect the complexity of that tool to increase (supposing you're willing to learn everything about it of course). The A-Engine is no different. As it supports additional features and extends with its tags, it's only natural for it to be viewed as a more complicated tool by developers. This complexity can cause a steeper learning curve, and that's when sensible naming conventions help a lot.

Simply put, I'd like to state and discuss the current naming conventions when developing for the A-Engine. Here goes the planned:

#1: Components:
All original components are fully lower case, with a '_' character to separate between words when needed:

Code:

set_hitbox[] #a frame component

{info} #info section opening tag
{/info}

#2: Tags:
With a few exceptions, all the original tags and component tags are lower case, with a '_' character to separate between words when needed:

Code:

center= 34, 99, 10 # a frame tag
add_hp= 50

The exceptions are limited to:
1- Tags which value can't change once set. These are tags which you can only set to a constant expression or value. For example: (the frame and the sequence tags are changed to upper case for the sake of staying consistent)

Code:

#works:
[F=100] #frames; while a frame is actually a component, "F" is somehow considered a tag which you provide it with an id
[/F]

#works
[FRAME=100+3] #an alternative more verbose frame tag (suggested by Rhino.Freak)
[/FRAME]

[F=$reg + 2] #doesn't work; will throw an error
[/F]

{info}
STANDING=0 #constant value
WALKING=10
{/info}

2-Input related tags. Because there are so many buttons on your keyboard, and so many options for input methods, tags related to that follow a special syntax: X<Z>
X being either "c" for clicks, "h" for holding, and "r" for releasing the key Z.
Z can be either 'up', 'down', 'left', 'right', '0', '1', '2', '3', '4', '5', '6', '7', '8' or '9' which correspond to keys set in the option menu for the controlling player, 'K_' + keyboard key name for a specific keyboard key, or 'MOUSE_' + 0, 1 or 2 for a specific corresponding mouse button. For example:

Code:

h<up>= 10 # go to frame 10 if the Up button for the controller of the object is being held
c<K_ESCAPE>= 20 #go to frame 20 when escape key is clicked
r<MOUSE_0>=30 # go to frame 30 if the left mouse button is released

#3: Switches:
All switches are fully uppercase, with no separator between words. A switch is to be placed in the beginning of the component's opening tag, and each switch should be surrounded by a pair of '|' characters :

Code:

{info}
|IGNOREGRAVITY|
# other tags
{/info}

[F=10]
|STANDING|NOSHADOW|
 img = 10 center = 10,10
[/F]

#4: Variables:
Variables begin with the character '@'. Like tags, variables are all lower case with words separated by a '_' character, except with input related variables, which are equivalent to the tags' but with a '@' at the beginning:

Code:

add_hp = @max_hp - @hp
goto = IF (@h<0> == TRUE) THEN (50) ELSE (10); # goto frame 50 if the action button 0 is held, else goto 10

#5: Registers:
Registers are prefixed with the character "$". Registers come of 3 types:
-Local registers: By default, registers through a to Z are available.  By default, registers through a to Z are available (upper and lower case), but you can add named registers with extra procedure.
-Global registers: Registers which value is shared between all objects and stages. Their names begin with 'G.' or 'g.'. By default, g.registers through 00 to 99 are available, but you can add named g.registers with extra procedure.
-Permanent/Preference registers: Registers which store values beyond a game's session (permanently saves values in a file). Their names begin with "P." or "p.". By default, p.registers through 00 to 99 are available, but you can add named p.registers with extra procedure.

Code:

x_vel=$a # local register
y_vel=$G.my_register # named global register
z_vel=$P.05 # permanent register

#6: Constants:
As of now, there are only 3 constants available: NONE, TRUE and FALSE. All upper case.

#7: Comments/Remarks:
Comments or Remarks in .a files is possible. For a single lined comment, just precede it with a '#' character. For multiline comments, they begin at a '/#' and end at '#/:

Code:

#this is a line comment
[F=10] # land from jump (can serve for description)
/# This is a
multiline
comment

ends here#/
 img=10 #other tags
[/F]

#8: Other Info on a .A File Structure:
In general, a .a file is composed of components of 3 types:
1-Main Components:

Code:

{main_component}
 #tags here
{/main_component}

These are usually used to enclose a main important portion of a .a file. A notable example of main components is the "{info}{/info}" component.

2-ID Components:

Code:

[id_component=id]
 tags here
[/id]

These are used for components which usually occur in lots and need to be recognized via ids. An example of an ID component is a frame "[F=id][/F]".

3-Sub Components:

Code:

sub_component[
 #tags here
]

Those are components which occur in lots, but don't usually need an id. An example for a sub component are all frame components; e.g "set_hitbox[ ]"



Changes and implications with the new naming rules:
1-Changing frame tags from lower case "[f= frame id][/f]" to upper case "[F= frame id][/F]" because frame ids can't change once set as noted in #2 exception 1.

2-Previously, we had:

Code:

{info}
 HP = 500 # starting health
 MAX_HP = 500
 #..etc
 [img] #images
   sheet[ dir="folder/spritesheet.png" w=100 h=100 rows=10 columns=10]
   sheet[ dir="folder/spritesheet2.png" w=100 h=100 rows=10 columns=10]
 [/img]
 [mdl] #models
   obj[ dir="folder/models/cube.obj" scale=100]
 [/mdl]
 [snd] #sounds
 [/snd]
 #..etc
{/info}

Now, because '' and the other tags don't need an id (only one of each is to be used when needed), they will become main components instead. Also, because "dir" and the other tags inside can't be changed once the assets are loaded, they need to be all upper case:

Code:

{info}
 HP = 500 # starting health
 MAX_HP = 500
 #..etc
 {img} #images
   sheet[ DIR="folder/spritesheet.png" W=100 H=100 ROWS=10 COLUMNS=10]
   sheet[ DIR="folder/spritesheet2.png" W=100 H=100 ROWS=10 COLUMNS=10]
 {/img}
 {mdl} #models
   obj[ DIR="folder/models/cube.obj" SCALE=100]
 {/mdl}
 {snd} #sounds
 {/snd}
 #..etc
{/info}

What do you guys think of the changes? And what would do you further suggest?

[NightmareX1337]

Here are few things I'm puzzled by:
- How does your shader implementation blend with the engine? How can someone use uniforms and such in glsl without altering the source code? Is this going to be easy? Do you have a default shader program hardcoded in engine?
- Do you really think blending 3D models and 2D sprites going to feel natural? Isn't it unnecessary complication?
- Do you have any idea how hard 3D modeling is?
- You seem to be trying to finish everything at once. Why don't you finish a small subset of engine and make it playable as soon as possible so people can start experimenting faster and you can incrementally develop it as time goes by?
- Still not using source control?
- A-Engine seems like it's going to be way too complicated. Is there any plan on simplifying it? (it almost requires fair programming skills for anything serious)
- How does your engine handle memory management of your a-scripts?
- Being able to do string processing in a-script seems too dangerous and unnecessary...
- Did you ever thought about using Lua as your script backend (or whatever suits)? Lua is designed embedding in mind and it's known to be the fastest script language (people write nontrivial games with it)
- Do you actually want to make it open source?
- Is this ever going to finish?

[A-Man]

lol, before I get to answering the questions, I want to say that the A-Engine project has been rebooted (since a while ago).

How does your shader implementation blend with the engine? How can someone use uniforms and such in glsl without altering the source code? Is this going to be easy?

For the user, setting a uniform is as simple as surrounding it by an ID component and linking it to a tag:

Code:

#version 150

in vec2 textureCoordinates;

uniform sampler2D uTexture1; //first texture; "image = " tag in A-Engine

[TAG_NAME="saturation"] // "saturation = 2"  in .a files will set this value to 2
 uniform float uSaturation;
[/TAG_NAME]

int main()
{
 vec4 pixelColor = texture2D(uTexture1, textureCoordinates); // fetch the pixel color off the texture
 pixelColor = pixelColor * uSaturation;
 gl_FragColor = pixelColor ;
}

varyings/ins/outs I don't expect people to want to change them. But if they do, I'll think of something similar.
Loading shaders is done via the A-Engine data.txt equivalent.

Code:

{shaders}
 [ID=1]
   TEXTURED = "folder/folder/textured.frag"
   LIGHTED = "folder/folder/lighted.frag"
   TEXTURED_LIGHTED = "folder/folder/textured_lighted.frag"
 [/ID]
{/shaders}

3 because:
-First for rendering images ignoring lighting
-Second for rendering models with no textures
-Third for rendering images with lighting

You may leave one or 2 of the 3, and the A-Engine will fall back to a default one for those cases.
Using them is as followed:

Code:

{media}
 {images}
   sheet[DIR = "sheet.png" W = 100 H = 100 ROWS = 10 COLUMNS = 10 SEPERATOR = 3 SHADER = 1 ] # set as default wne you load it
 {/images}
{/media}
[F = 100]
 image = 10 shader = 1 # or you can declare using it for one frame
 xy_center = 39, 79 delay = 3 goto = 101
[/F]

Do you have a default shader program hardcoded in engine?

There is a default, but it's not hardcoded :P. It wouldn't be a bad idea to write it in the source.

- Do you really think blending 3D models and 2D sprites going to feel natural? Isn't it unnecessary complication?

It really doesn't in most cases (the screenshots I've provided). But it does look wonderful at times if done right (Paper Mario!); if all models and sprites have same texture detail, and the fov is not very small to help make things flatter with perspective projection. Plus you can still use 3D models with orthographic projection if you want to flatten everything.

But just to show what the A-Engine has to offer anyway. You can keep at 2D-only or 3D-only if you wish.

- Do you have any idea how hard 3D modeling is?

Not as hard as quality sprites, but they're hard indeed. It's even harder to do game-optimized ones, but I couldn't care less :P. I write an engine that can load 3D models, not a 3D magic modeller.

- You seem to be trying to finish everything at once. Why don't you finish a small subset of engine and make it playable as soon as possible so people can start experimenting faster and you can incrementally develop it as time goes by?

That has been the goal, and I've reached stages where I could make something playable with it (and I actually did release something playable before, but not under the name "A-Engine"). But yes, really, this is the plan next.

- Still not using source control?

oops  :( I really plan to. I'll put what I have on GitHub soon.

- A-Engine seems like it's going to be way too complicated. Is there any plan on simplifying it? (it almost requires fair programming skills for anything serious)

I don't really see where you'd NEED programming skills if you're not into something that can't be done otherwise. An A-Engine character file looks very similar to LF2's. Just like LF2, everything is controlled by frames, and a lot of the tags are analogous (next: and goto=, wait: and delay=, pic: and image=, centerx:, centery: and x_center=, y_center=, dvx: and x_velocity=, opoint: and call_object[], itr: and hit_box[] ..etc). The difference is that you've got various new tags for lots of new stuff, and that tags like LF2's "state:" and "kind:" which gave fixed properties and constraints has been replaced by "switches" and other tags.

Things need to get complicated if you wish to do something complicated too.

- How does your engine handle memory management of your a-scripts?

"Memory management" is a scary word (phrase), I wouldn't use it to describe what I do XD.
But yes, first, before you make programming-phobic folks here run away, I should mention that a-scripts will very often not be used for things other than AI (and even AI will have a simple optional layer to make a character do simple things). This is one way you can use it:

Code:

<<-use_hp_for_mp
 if (@hp > 100) then
   @hp -= 10
   @mp += 100
 end
use_hp_for_mp

[F=123]
 <<use_hp_for_mp()>> #call script/function
 image = 120 xy_center = 10, 10
[/F]

Another option is to write the script body inside the frame's "<<>>". That would have made the script/function not usable outside the frame, and you wouldn't need to name it. But regardless, you could have also just used the "add_hp=", "add_mp=" tags instead (safer, since you don't need to worry about going over the max hp or something; the tags handle it for you):

PYTHON-Code: [F=123]  image = 120 xy_center = 10, 10  add_hp = (@hp > 100) ? 0 : -10  add_sp = (@hp > 100) ? 0 : 100 [/F]

But to actually answer your question, I just allocate memory for all variables in the script when its run (in a simple std::vector<AValue<float>>; AValue is the main (dynamic) type), and its freed automatically when the script finishes running. There are other details concerning scoping, but the gist of it is that its just a hierarchy of a vector of pointers from the above vector for every level.

- Did you ever thought about using Lua as your script backend (or whatever suits)? Lua is designed embedding in mind and it's known to be the fastest script language (people write nontrivial games with it)

I did consider python and Angel Script for a while, but the latter is slow, and the second.. Well, I'm not coming up with an excuse. I'll just say making my own little thing sounded more exciting XP. I'm not much worried about performance, because A-Script does very well I think. I admit I'm guilty for not checking out other options further, and I really could have saved myself some time. But I learnt a lot.

- Do you actually want to make it open source?

Of course. It'd be nice if you can take a look at it and give me some tips then.

- Is this ever going to finish? :D

It will. I don't know about "finish" since I plan to actively work on it for a while more afterwards, but it'll be released as something usable soon.

[Happy Clown]

Download link please??
I tried searching A Enging in Google but I didn't go