Sorry your browser is not supported!

NOTE: I meant to post this in AppGameKit Chat not here in Showcase. But when I first came here I was checking out the stuff people are working on and then without thinking created this post here.
If someone could move this to the Chat forum that would be awesome. Thanks!

I've been thinking (oh no! That is always the start of the trouble lol) the past few months that although I am not a fan of ood (object oriented design) as in inheritance the "is a" model (I think it is a rigid structure that seriously breaks down as projects grow in scope) I have always liked cbp (component based design) as in assigning behaviors to objects the "has a" model.

In C++ this is done with abstract classes containing virtual functions and in C# Interfaces are the way to go. So basically you get stuff like ISpeakable, IWalkable, IWhatever.

For game programming it is different in that we would be looking at behaviors more along the lines of Child (which basically would be like AGK's FixObjectToObject and my FixSpriteToSprite), Move, Flash, Fade at the lower level and building on some of these along with additional logic have more complex behaviors such as Bullet, Gun and even Turret.

I thought a fair amount back to the time I did a lot of C programming and I thought really at its heart it is just data.... in many ways this is like setting up attributes to describe things such as tiles for example. It is quite common to have bit flags (or constants in AppGameKit BASIC) to associate behaviors to a tile such as Water, Ground or Walkable, Swimmable, etc. So in the same manner automated behavior systems can be created right in AppGameKit BASIC.

My focus here is on creating a variety of Sprite Behaviors in the interest of reducing the scope of work in creating games. Make game dev more efficient.

I did my proof of concept tonight which was implementing the simple Sprite Behavior Move.

I used the demo I made for the Extended API the other day.

This single line provides the same behavior as the original code did to control the sprite that moves vertically up and down the screen.


The signature of the function is:
SetSpriteBehaveMoveLinear(spriteID as integer, xp1 as float, yp1 as float, xp2 as float, yp2 as float, delay as float, xv as float, yv as float, xa as float, ya as float, pingpong as integer)
SpriteID is the id of the sprite to apply this movement behavior to.
xp1, yp1 are the starting position
xp2, yp2 are the ending position
delay is the delay between updating the movement
xv,yv are the x and y velocities
xa,ya are the x and y acceleration/deceleration
pingpong is just an option to reverse the motion once the sprite has reached its destination

Like I said, this one was just a simple proof of concept but even with this there is lot of flexibility to style the movement.
SetSpriteBehaveMoveLinear(sprite4, 640,700, 640,250, 0, 0,-5, 0,0, TRUE) provides a steady movement up and down between y positions 250 and 700
SetSpriteBehaveMoveLinear(sprite4, 640,700, 640,250, 10, 0,-75, 0,0, TRUE) would make the sprite jump, pause a tiny bit, jump again and so forth.
SetSpriteBehaveMoveLinear(sprite4, 640,700, 640,250, 0, 0,-5, 0.1,0, TRUE) would move the sprite every frame at a speed that is constantly increasing.
And so on.

There are 3 functions available to get stats on the movement behavior for a given sprite.
SpriteBehaviorIsMoving(spriteID as integer) returns TRUE if the sprite is still moving and FALSE if it is not
SpriteBehaviorVelocityX(spriteID as integer) and SpriteBehaviorVelocityY(spriteID as integer) return the sprite's current velocity.

There are three other movement behaviors I plan to implement: SPRITE_BEHAVE_MOVE_FORLIFE, SPRITE_BEHAVE_MOVE_ORBIT_POSITION and SPRITE_BEHAVE_MOVE_ORBIT_SPRITE
The first one allows setting a life value for the movement behavior which is decreased each frame and when exhausted the sprite stops moving and is probably automatically removed from the movement behavior list.
The second one allows the sprite to move in an orbit around a fixed location on the screen and the rotation speed as well as radius can be dynamic growing, shrinking, etc.
The third one does the same thing but uses the position of another sprite as the center point for the orbit.

After these simple ones are done I can then go on to do something like a Bullet Behavior which of course would rely on the SPRITE_BEHAVE_MOVE_FORLIFE behavior only it would allow configuring the starting image (or images for animated bullets) and the BehaviorBullet system would accept an array of sprites that each Bullet Behavior would check for collision against and then automatically do it's impact animation when it collides. Because we don't have the ability to do callbacks unfortunately in AppGameKit BASIC I am thinking the high level BehaviorManager will have functions BulletBehaviorApplyDamage() etc that is called upon impact passing in the sprite it hit. So in this way only this one function would need to be updated to handle the various damage types. And any other thing that needs to notify something else in the program will work the same way.

From there it goes on to GunBehavior which can spawn a sprite that has the BulletBehavior and then TurretBehavior which can be assigned to any sprite to allow it to track a set of sprites and fire bullets at them.

The idea here is it is basically one or two lines to assign these behaviors to any sprite and new behaviors can always be added. Flash behavior may be applied automatically to the sprite the bullet hit for example so it can indicate a "hit" was taken.

So all of this just to say has anyone implemented something like this already? If someone has already implemented a Behavioral Component system in AppGameKit Tier 1 and it is posted somewhere around here or in a repo I'd be interested in seeing it. No sense in me duplicating work already done by someone else.

Thanks!

Hi GarBenjamin

I do not think I saw on the forum what you propose.
If I understand correctly, you propose "function" ready to help?

Basically although I modularize my code a lot and use the same patterns and even make use of the managers I write in new projects I find there is still too much duplication of fundamental stuff going on. I tackled a tiny bit of itwith the Extended API I posted over in chat a couple days or so ago. That kind of stuff is just "a given" so to speak and should already be available imho.

Anyway I realized even though I use my BulletManager for new projects and I use the CollisionManager and TileManager and so forth and this stuff does same time. By not having to write all that boilerplate code again & again I can develop quickly as a result... however this is nowhere near as efficient as it could be.

Basically if you have ever seen any of the many GUI Game Engines out there one thing they provide which is extremely good for maximizing the efficiency of game dev time is pre-canned behaviors. Typically they have have things. These things may be called Entities in one engine or GameObjects in another engine and so forth. And simple drag n drop assigns a behavior to an object and then that behavior will have a few properties that can be modified.

I have never liked any GUI-based game engine (GameGuru is pretty darn good) because I am a programmer and prefer to work in the code. So basically my goal is create a variety of sprite behaviors. At first just simple fundamental behaviors that basically any game can use. Then building more complex specialized behaviors.

Basically think of it like shaders. Shader packs can apply a variety of different visual behaviors to a sprite or 3D object by just assigning the shader to those objects. The behaviors I am focused on are logical behaviors that will provide logical behaviors by simply assigning them to the objects.

Another way to think of it is many engines including AppGameKit give us Tweens. And I have started using tweens in my AppGameKit projects recently. What those are doing is providing very simple fundamental behaviors. Movement behavior. The animation system provides an animation behavior. So just think of that stuff and then think what is the next logical step?

Well what if the api provided a Bullet Behavior for example that could be applied to a sprite or 3D object allowing you to configure it being spawned, moving, animating in flight, checking for collisions and impacting another object and then storing the ID of the object it hit setting the property Collided to TRUE and then doing its impact animation and finally turning invisible.

That is the kind of behaviors I am talking about.

Anyway this might be something only interesting to me. Lol I make a lot of games even if only template / example games to help others still a lot of game focused development. And for me I always think as efficient as my game development is I know it can be a lot better.

And I think having a large number of sprite behaviors (and 3D object behaviors) is the next step for me to increase my game dev speed even more. So this is what I am working on now.

Just wondered if maybe there was a library around here where someone had already taken the time to do all of this work.

Well so far so good except I got a bit sidetracked. lol

I added another movement behavior that can be assigned to a sprite to move it by an angle direction with options to initially set the sprite angle to be the same as the angle for the movement direction then added an option to also set a speed to rotate the sprite during movement. And another option to set AlphaBasedOnLife which means as the life of the motion decreases we get a nice fade going on automatically. So that is another excellent motion behavior for a bullet / projectile weapon in a game. I still need to add the wave behavior and will probably do that one some time this weekend.

Anyway, then I started on the Bullet Behavior and thinking through it I thought do I want this bullet to truly automatically be able to handle its own collision checking? It would be quite awesome if a person could really do a simple SetSpriteBehaviorBullet passing in the sprite to apply the behavior to and have the bullet spawn, move as instructed and automatically time out when its life expires (that is all done already) and in addition automatically check for collisions with enemies and so forth.

So I thought... well what would that kind of structure look like. Making a long story short I ended up building my own collision detection system where I can set up collision groups. Basically just using this new function...
SetSpriteBehaveCollideGroup(groupID as integer, groupIDToCollideWith as integer) and then add the actual sprite collide behavior with SetSpriteBehaveCollide(spriteID as integer, GroupID as integer, RefID as integer).
The refID parameter is just anything that makes sense for the developer to use. For me it would be the index value in an array of objects so I can instantly know exactly which item is reporting a collision.

So I thought the new motion would allow me to quickly make some cool looking explosion FX and it does. And I wanted to test this collision system out so I updated that little Extended API demo so now it does this (I commented out all of the print statements from the original version).


The number that appears in the upper left corner is from me calling SpriteBehaviorCollidedSpriteID(sprite4). When 0 there it means the system found no collision otherwise it is the id of the sprite that it collided with. Calling SpriteBehaviorCollidedGroupID(sprite4) would give me the group ID number and calling SpriteBehaviorCollidedRefID(sprite4) would give me the Reference ID number.

It's all good overall but I really don't think I want to implement my own collision checking system. Seems overkill so I think I will back off on this and see how I could do it using the native collision system. I would prefer not to get into the physics system but I might have to. Eventually I will anyway because making sprite behaviors for a platform game having built it all myself every time in the past it is a good amount of work to make everything work well. So I think to create a SetSpriteBehavePlatformCharacter behavior it would be much better to use the physics system for such a thing.

Anyway hopefully this is making it clearer. Basically I am now working on a library of sprite behaviors that can be attached to any sprite and the systems take over and automagically "it just works". Starting with the most basic stuff first of course as I have shown so far.

BUT I really should get back to my tower defense game. I might knock out enough sprite behaviors that I can rewrite the game with them. That was kind of my original idea thinking of the bullet behavior, turret behavior, etc.

The main thing is that you're having fun !!

Absolutely right about that Captain Ouais! I've always enjoyed working on the technical / engine side of game development and for a long time I never actually completed any games because I spent all of my time just building engines. lol I stopped that some years ago to focus instead on completing games and finally started completing them.

So I am back to kind of engine work again now BUT this time it is with a clear focus to lay a strong foundation so I can get back to game development and have it be much more efficient.

I implemented a Bullet Behavior now which works out very well. Mainly it just builds on top of the previous Movement and Collide Behaviors.

So this one line is how the turret on the right spawns a bullet.


That call sets up the Bullet Behavior for the sprite and that behavior in turn automatically sets up a Move Behavior for the sprite and the move behavior actually propels it along. The Bullet Behavior then simply monitors for events such as the Move Behavior no longer being active (means the bullet life burned out) or the Collide Behavior indicating the bullet hit something. In this second case the Bullet Behavior takes care of setting the sprite invisible and setting the Bullet Behavior active = FALSE as well as removing the Move Behavior from the sprite.

The thing with this stuff is there is a fine balance I think between how much to automate and how much not to. I am thinking of adding in BulletMoveAnimation and BulletImpactAnimation that will be automatically handled by the Bullet Behavior as well. But then I think... ah is it really needed? How much time will that save me over just handling it myself such as currently I just use a second line PlayAnim to do the bullet animation in the main program and could do the same for the bullet impact animation.

But then again the point here was to wrap up complete behaviors as far as management of spawning, movement, animation and collisions so probably I will do this.

Anyway, right now most of this is performed by Sprite Behaviors with the main code simply assigning behaviors as needed for the particles and the bullets, handling the firing of the turrets and creating the explosivey acid particle cloud type thing when the moving square hits the square that rotates to face the mouse, and the rotations of the turret blocks which was already in calling those new SetSpriteFace functions.



I'm not sure how far I will take this. I have a concern that I will hit a performance wall sooner or later doing it all in BASIC. It would be awesome to have such behaviors built into the API running at lightning speed. Kind of like instant game components.

....

Actually I never tried to do any kind of library in C for use in AppGameKit only a game project when I made the Mutant Invaders in BASIC and C in parallel. I guess I was thinking each side would be separate so if sprites are created in BASIC then an AppGameKit c program would have no knowledge of them. But if they could be integrated so both the BASIC and the C dll referred to the same sprites, images and so forth then I could simply write this all in C to get about 50 times more speed. Of course I could make wrappers for every AppGameKit sprite, image and animation function etc on the C side basically duplicating it all and then have the BASIC call all of the C wrapper functions to create sprites, load images and so forth but that seems like a ton of work for basically a cludge of a system. And in any case I think the web export wouldn't work using C I'd guess.

I think that agk and our computers are powerful enough to do everything you want to do! Provided you know how to code a minimum.
what slows the games now it's the desktop graphics cards ^^

True but still we have to keep in mind this is compiled byte code and logic processing in the code we write may be a concern as well. But overall I agree and design optimization is something I have always enjoyed doing.

The easiest way for max speed is just program everything explicitly which is what I normally do with my Managers structure and pools of object. Without layers of abstraction and such it is basically raw to the metal as best as can get. And that is why I always use that approach. Straightforward and fast but takes a lot of typing a lot of duplication.

Making Game Behaviors for sprites and 3D objects is by its nature adding layers of abstraction in the interest of making development more efficient. And the performance penalty depends largely on to what degree the abstractions are implemented. Currently in the very simple demo above every moving sprite is handled through a move behavior and the bullets are bullet behaviors. Collision checking and the fundamental level of processing collisions is automatically handled by a Collide Behavior. If we could use callbacks I could make it also call a function when a collision happens. But for now this is manually checked.

Anyway the idea is these systems have been written once and such code will never need to be written again. Well once I have them completed. From that point on I can just include these and maybe can gain enough of a boost to make a solid game in a weekend at some point.

But yeah all of this flexibility comes at a price. There is some degree of overhead but I am designing and implementing it to be minimal in the interest of performance. It will never be as efficient performance wise as me developing the way I normally do writing dedicated code in managers.

Could Always be usefull for someone
I Always tend to have something similar in the background of my own.

Same to a degree Cliff. I used to design more elaborate systems years ago but such stuff was always a large overhead particularly in those days so I changed my approach to just pretty much barebones direct coding of everything as I needed it.

I do have some basic templates such as my AudioManager, EnemyManager, AssetManager and so on that are used in every project but it is more of a structure a template that is detailed in for each project so the code all ends up dedicated for the needs of that specific game. Nothing moves for example unless I am explicitly moving it by updating its position frame to frame in a manager.

I like this approach a lot because it provides high speed with max flexibility and because I use the same patterns again and again and again I can develop quickly this way. BUT not as fast as if there was something like a MakeBullet function in the api itself that basically created a sprite and automatically gave it the behavior (within the options the programmer reguested) of a bullet spawning, moving, animating, handling collisions and so forth on its own.

Just not sure how far I want to go down that road. But I will be doing some dev work today. I'd like to at least finish off the Move Behavior which still has a couple of behavior styles that need to be implemented.

But who knows I might switch back to working on my Tower Defense game instead. I haven't worked on it in about a week now. lol Went down a rabbit hole of thinking about an Extended API and from there to working on behaviors.

I guess I will keep this project as something I switch to as I want to and make use of what I have built in each new game project. Not like there is any big hurry for it and it is coming along great so far.



To finish off the Move Behaviors I need to implement OrbitPosition, OrbitSprite and Wave. With those implemented it will make it pretty much handle anything needed to very easily & quickly implement a lot of different requirements in games. Whether it is having the player pick up a shield that causes several sprites to orbit around them for a certain amount of time or collecting something that sends an invisible sprite moving up and a bunch of Orbit Sprites are orbiting that invisible sprite making a nice little collected FX or a gun is shooting out projectiles that move in a vertical wave as they travel horizontally or vice versa.

I mean of course we can knock these things out by directly just programming them but that is the whole point of what I am trying to get away from. The need of even having to knock this kind of basic stuff out again and again and again.

as you can see with my game Knight ans demons, side small routine, I manage

Yeah your game looks great. Very nice work for sure. Seems like basically you are or have been for many months doing the same kind of thing as I just started on in a more formal way (as in actually focusing on this specifically) only very recently... that is building all of the fundamental stuff systems and so forth. Basically building the engine. And that is exactly all I am doing here except it is not a game specific engine but rather taking the approach of building behavioral code components that are common across many different game projects.

The higher level behaviors would become more genre specific. For now just focusing on all of the fundamentals which even in themselves will make development more efficient. Basically I am just building code components. Conceptually very similar to using some GUI-based development tool dragging & dropping behaviors onto an object to assign behaviors to that object. Since I have always preferred programming the normal way via writing code in text here the behaviors are code components that are assigned to sprites via function calls.

I added two new Move Behaviors... OrbitPosition and OrbitSprite... basically is only one programmatically the only difference is the OrbitSprite dynamically pulls the center position from the sprite that is being orbited.

As you can see that is a huge signature so I at some point I will make some alternative functions with various combinations of the signatures for the most common use cases in the interest of saving on typing.

The red square in the middle is being orbited by two sprites using a multiplex and the sprite being rotated to match the angle of the orbit and their orbit radius grows and shrinks and produces a decent little FX.


The vertically moving yellow square representing an enemy has one sprite with a MoveOrbitSprite behavior assigned to it... this time the radius stays constant and the rotation has the PingPong flag set on it and this orbit sprite also rotates to match the angle of its orbit.


The turrets each have a single sprite with orbit behavior attached to their positions and these rotate with their radius growing and shrinking and the orbit sprites have rotateSpriteToMatchOrbit set to FALSE.




Overall it is coming along nicely and is now at the point where it is usable for some basic stuff. Of course, there are other movement behaviors that games need. One that immediately comes to mind is a FollowLeader movement which programmatically I think I might implement with a SpriteBehaveSetFollowLeader to set the sprite that is the leader and then SetSpriteBehaveFollow on the tail sprites. This would be useful for snakey things as well as ghost trails and so forth.

For now I think I will take a break.

I decided why not have some fun now that it is so darn easy to add these basic behaviors to sprites. So I got back on here again.

This is a demo of Orbiters Orbiting Orbiters Orbiting Orbiters Orbiting the turrets. That is to say there are sprites with Orbit Behaviors assigned to them that orbit each turret. For each of those there are 4 sprites with Orbit Behaviors assigned to them that each of the larger orbiting sprites. And finally for each of these there are 4 sprites with Orbit Behaviors assigned to them to orbit the previous ones.

And just a matter of changing the behavior based on radius growing/shrinking and so forth... to get something like this...

Actually would be a very easy way to make some interesting enemies for a shmup game.

And now I am really done playing around with development for the night. But it was fun to do this and see the results of this work on Behavioral Code Components.

They definitely are very useful! Saves a ton of duplication work already.

Unfortunately I implemented a single radius control that manages both x and y radius and that won't cut it for game development so tonight will break that out into separate control over x and y radius. Then I will be satisfied with this move behavior.

Happy coding c0d3r9!

An early dev session done (this is very good because it means I will probably get in another one before I sleep later tonight!)

I took care of that missing functionality I noticed and now the Orbit Move behaviors offer separate control over the X and Y radius instead of keeping them equal.

And to illustrate this I added 3 new sets of orbiter sprites. One set is simply orbiting the middle of the top of the screen using the Orbit Position behavior. The other two are using the Orbit Sprite behavior to orbiting sprites that just happen to be invisible.
And each of those invisible sprites have linear move behaviors moving them back and forth horizontally.

Now I have to admit at this point with about 500 sprites with behaviors attached to them I am starting to see some performance issues. Not in desktop mode of course but I mean I also test HTML5 builds and after adding this latest batch of another 180 orbiter sprites the framerate became unstable where previously it was stead 60 fps. Ah well I knew it had to happen sooner or later and I am still fine with it because in practice I am not going have anywhere near this number of sprites with behaviors active at one time on screen. A big part of it is the explosioney acid cloud FX that eats away at the red block when the yellow block hits it. That is 180 sprites at work. For a game I would produce that FX and then grab every 3rd or 4th frame to produce an animation that can simply be played instead of real-time handling all of that. That's just common sense like building look up tables and so forth.

Alright enough rambling.... this is what it looks like now... with the top sprites taking advantage of the new separate X & Y radius control.

Moved as requested,

SC

Thanks!

I revisited this initiative tonight.

Added a Sprite Grid...

For this example, i used this code which takes advantage of the new SpriteBehaveGridCreate and SpriteBehaveGridGetSpriteID functions... to create a grid of 50 x 50 sprites each set in cells 12x12 pixels and the offset for their positioning et to -300,-300 which means the entire grid is centered on the moving square. The remaining bit of code then loops through all of these cells, get the ID for the sprite at that cell and then uses it to set the color, size and offset for each cell sprite.
And that is it. It is all set up and done and when SpriteBehaviorUpdate() is called all of this stuff updates as needed on screen. Basically that one call is handling almost everything seen in this demo.


And this grid is attached to the sprite that moves up and down the screen... meaning it moves when that sprite moves and rotates when it rotates, etc. The basic stuff.


My thinking here is having a sprite grid structure created with one function and attached to a sprite will be very handy when creating a dialogue / message system etc... basically when presenting text each cell sprite can hold one character and by having the grid structure predefined it makes it easy to work with for such a thing wrapping words around and so forth. And get the benefits of the movement and rotation across the entire grid structure. I might add scaling to the grid as well.

I think the next update I will add a tracking behavior so a bullet, etc can be fired and have it automatically track to a target sprite. But I don't know for sure. I might just wait til I run into a need with my game dev and then add the needed behaviors from this point on.