Asgard2 - WIP

[Atlantis]

Hi there,

Some of you may still know me from the old Elysium forum where I was the one who created the fast but admittedly quite featureless Asgard Engine.

I'm right now playing around with Asgard2 (A2 for short) and need some feedback. There's no release yet, you will get that when it's done. =)

What I need is some ideas about what I already have and maybe some comments and criticism. And maybe some hype if you like what you read. *g*

Anyway, the engine currently has:
- DX8 based UI system
- DX8 based widget system
- DX8 based sprites
- enhanced graphics with true alphablending (taking into account your image's alpha channel) and advanced texture blending effects
- animations (configurable, reusable, independent from all spritesheets)

Here's how the widget system works:
A2 does away with all of the ugly Windows forms and buttons. That's right, no longer will you have to use grey forms or ugly hacked together boxes. Instead, there are now DX8 rendered widgets that support special effects (alpha/textureblend) and their own transparent color and custom background. Configuring such a widget is really easy, too. 1 line of code, 2 if you want it to be draggable with the mouse cursor. One placed, a widget will automatically draw itself and generate appropriate reactions to clicks and mouseovers. Custom event handlers take only 1 if statement.

Imagine a draggable, partially transparent, animated inventory that won't cause the screen to flicker or leave artifacts. That's what it is capable of.

The UI system is basically what initializes the widget system and catches windows events for the game and the widgets. It is pretty small, hooks into the normal event calls and translates them properly to the DirectX8 game screen. As you may have read before, A2 doesn't use Windows forms anymore for its GUI. (Alright, it does for editing but for nothing that is supposed to look pretty and never be seen by users, only developers.)

Next is the sprite system. This abstraction layer provides easy access and configuration for sprites. Ever looked at the sprite routines in MS? Yes? Found them readable and easy to maintain? Yeah, me neither. That's what this is for. Load any spriteheet, set height and width of a frame, the number of frames and you're ready to go. All other information is automaticallly generated and added, maintained and modified. Probably don't have to mention this but sprites are dynamic. Just pass the size as parameter and the game will know to handle it. Sprites just work.

The animation system is quite similar. It allows you to define animations. What for? Well, there are already 4 frequently used animations. Walk up, walk down, walk left and walk right. Yeah, those are what I'm talking about. Now you can create your own animations for any situation you want to. Make an item that lets characters dance, a swordfighting skill that lets your character show off his ultra 112x combo or areas where players move different. Animated items? No problem since those use the new sprite system as well. (To be honest, the animations are not yet tied to other stuff. They are completely coded but not integrated with items and spells... But they will be, promise.)

To tie sprites and animations together, there's the new entity system. At first this may sound strange and confusing. It is not. An entity is essentially a combination of a sprite, an animation and some little tidbits of other information. The purpose? Being there. Entities can automatically perform predefined animations and animation with any sprite of your choice. Entities are basically all graphical "game objects". Players, Monsters, NPCs, Items and so on. Once created an entity will stay on screen where you put it, redraw itself when appropriate and perform it's assigned animation logic (which consists of one or more of the aforementioned animations.)

Here's some code as a preview, this is where I probably need the most feedback so please comment:

' creating a widget, this is the character info and stats base window (the one with the bars)
Call A2_createWidget("charinfo", "", 0, 0, 64, 272, "charinfo.bmp")
Call A2_setWidgetDraggable("charinfo", True)

' sprite and animation code demo
For i = 1 To MAX_SPRITE_TEXTURES
' create our character sprites. Looks similar to the old mechanics, eh?
Call A2_createSprite("sprite" & i, 16, 32, 32, 32, 12, i & ".bmp")
Next i

' create animations. the 2. and 3. parameter specify the start and stop frames, the 4. chooses an
' animation behavior. 5th is one of two speed factors you can adjust if you want automatic animation

Call A2_createAnimation("walk_up", 0, 2, LoopAndDefault, 1)
Call A2_createAnimation("walk_down", 3, 5, LoopAndDefault, 1)
Call A2_createAnimation("walk_left", 6, 8, LoopAndDefault, 1)
Call A2_createAnimation("walk_right", 9, 11, LoopAndDefault, 1)

' now we can combine those into an entity, this will take care of any drawing
my_ent = A2_createEntity(25, 32, A2_getSpriteByName("sprite1"), A2_getAnimationByName("walk_down"), 1, 255, 1)

The entity we just created will now periodically draw itself, change it's animation frame if possible and take care of it's own positioning. It supports alpha blending, too! =)

Alright, now that I gave you an overwiew, please help me improve it. I am putting a lot of work into these frameworks and I definitely want them to be good.



Greetz, Atlantis

[Labmonkey]

You use to use gamemaker right? I remember seeing a post of yours on the gmc about mirage/elysium. Or maybe im just imagining things.

[Atlantis]

Yeah, I use Game Maker a lot. =)

Not much of a feedback, though. ;p

[Labmonkey]

Seems ok. Personally it doesn't seem like that big of a deal. We've all seen dx8 gui's, etc. I mean like its impressive, don't get me wrong, but I am not sure as to what kind of comments you are looking for. You seem to have everything pretty worked out.

[Atlantis]

There are some things...

For example just now I found a real weakness in VB: You can''t return a reference from a function (ByRef only works for parameters, not return values). Being a C coder this kinda makes me feel... limited. =(

Right now I'm using get/set functions for the properties but the

Code:

UI("widgetname").draggable = true

I had originally in mind won't work out unless someone knows a workaround.

And while you're here... Yeah, DX8 are nothing special but that's exactly why I'm posting here. My goal is to make a "snappy" game that doesn't feel as static as MS usually does. So the UI has to be good and I need feedback, ideas, discussion and criticism for that. What would make a GUI/widget system special for you? Effects? A certain kind of interaction with the game? Controls? A certain layout or lack of it?

I got the basic technology down, now I need something cool to apply it to.



Greetz, Atlantis

[Labmonkey]

For the UI("WidgetName"), I assume UI is a function, you can make it return a type, and then put draggable in that type. Something Like

Code:

Function UI (Byval WidgetName as String) as Widget
    Code
End Function

and

Code:

Type Widget
    Draggable as Boolean
    X as Integer
    Y as Integer
    Height as Integer
    Width as Integer
End Type

Also, lots of alpha blending makes everything look better.

[Atlantis]

That's how I intended to do it, yes. Problem I have: VB does not know how to return a reference to an object. It will always return a copy. And that's not what I want. Been googling this for hours now.

Returning a copy doesn't help much here, sadly, as any changes made to the copy will not apply to the original. Am I overlooking something here or is VB simply incapable of doing this?



Greetz, Atlantis

[Labmonkey]

Instead of making UI a function, make it an array? Then you can in another function, like GetUI return the index of the array.

[Vans]

omg, you are still alive! nice to see you man!

[Atlantis]

Hey Vans, long time no see. ^^ xD Who else is still around that I might know?

Anyway, please stay on topic in this thread as I really want to make some progress. *g* Feel free to open a related talk thread though, I'll be a regular visitor to it. =)

One new idea I had about this problem: Would manually issuing an update command to write the record back to the internal record keeper alright? Something like this:

Code:

my_widget = UI("charinfo")
my_widget.draggable = true
UI_update(my_widget)

This would require every widget to know where it's original record is and it requires an additional, manual writeback command but right now that's the only way I see to avoid messing with the array that holds the originals. What do you think?

EDIT: This is what I have so far...


Code to make this widget work is only this:

Code:

Call A2_createWidget("charinfo", "", A2_WidgetType.Menu, 0, 0, 64, 256, "charinfo1.bmp")
    Call A2_setWidgetDraggable("charinfo", True)
    Call A2_setWidgetOpacity("charinfo", 128)
    Call A2_createWidget("charinfo_d", "charinfo", A2_WidgetType.Menu, 0, 0, 64, 256, "charinfo2.bmp")
    
    Call A2_createWidget("btn_inventory", "charinfo", Menu, 100, 10, 24, 24, "swordicon.bmp")

Only the base widget (the semi-transparent part) is draggable, the frame and button just know that the base widget is their parent and move along accordingly if it is dragged. There's no additionale code required for this widget to work, after these lines it is displayed and can be dragged, redraws itself automatically and you could attach event handlers if you wanted to. pretty neat, eh?




Greetz, Atlantis

[Labmonkey]

Don't use strings for your widget id's. Use numbers, maybe with constants with the equivelent names of the strings. Then just change UI to an array of types instead of a function. Seems like the easiest/fastest way to do it to me.

[Atlantis]

The easiest in making, yes. But not when using it. I want to specifically avoid any passing of array indices. Makes code harder to read and maintain and requires direct use of the internal widget array.

I want to either obtain a reference to the widget I an working with or set the parameters through a function (which I'm doing right now but like less).

The advantage of the function-based approach is clear, I think. All sanity checking can be left to the engine, the actual game running on top of it can rely on the availability of certain features.

The reference based approach would leave the sanity checking to the programmer (unless that is moved to the widget updating logic) but make core very, very readable and maintainable.

You are right though. I'll probably split it into two functions, like this:

Code:

my_widget = getUI("inventory")
my_widget.bg = Resource("UI", "inventory.bmp")
setUI(my_widget)

[Labmonkey]

Quick question? Why can't you just use variables linked to the type? Ie, instead of UI("window") make it Dim Window as UI. Though I did forget what most of your main post said...

[Jacob]

You could do a dictionary object to store all your variables. It might be a little bit slower, but would work out well, especially if users of your engine wanted to easily add different variables to a widget.

Psuedo:

Code:

SetWidgetValue("widgetname", "key", value)
value = GetWidgetValue("widgetname", "key")

So, for your draggable you'd have to initialize the dictionary with a "draggable" key.

Code:

SetWidgetValue("widgetname", "draggable", true)
if GetWidgetValue("widgetname", "draggable") = true then
'drag it
end if

Just an idea.. if you want me to expand more, just ask.