Sorry your browser is not supported!

Hello.

I'm going to keep a dev log here for my next game project. I've done a few very simple tiny game projects in AGK2 to test it and I'm happy with the results.

So now I can move forward to doing the bigger game I want to create.

Very early days. In fact, I just started on this officially a few days or so ago working very part-time.

One of the things I wrestled with a lot was the visual style. This is because the absolute quality of the graphics determines the amount of time spent on the visuals. And the better quality / more detailed the work it is in 2D pixel art to animate. This has been a long process where I continually strive to simplify the graphics while also trying to make the scene look interesting.

This game will be very low res at 160x90 and basically solid colored objects for the most part. Some objects will have 2 colors and some may have 4 all depending on the object. Basically anything in the active gameplay (can be interacted with) will have more colors although still be very simply represented.

The idea is by spending less time on graphics I can then spend more time on everything else especially the gameplay.

----------

The beginning of the story... after a bit of thought I saw a lone barbarian walking down a hill. He had been away traveling for weeks on the other side of the distant mountains. When he returned the found horror had come to the little settlement. Of course, there is always that one person who has a few gasps of breath left in them who explained a strange band of misfits, bizarre creatures and powerful sorcerers had arrived killed the men and taken the women and children.

Shocked he hurried on to his home. And found someone very important was missing...

You do the old NES era graphics really well, very authentic.

Looking forward to seeing this progress.

Thanks Ortu. Graphics need to be kept very basic for me to be able to tackle games of a reasonable size due to limited time. I don't like working on projects that last a loooong time.

I am only working on this a couple of hours every other day. Doing this to try to help me to not get burnt out on the project.

That ^^^ means progress may be fairly slow but hopefully not so slow that I say to heck with it all. lol

This is the prototyping stage meaning I am focusing on the important stuff one step at a time.
The character is now represented by a rectangle.

Splitting the project into multiple parts

The full (larger ultimate outcome) game will feature platforming (environmental interaction) and combat.

Instead of trying to tackle everything at once I am breaking the game down into distinct sub projects. Each of these sub projects will result in a tiny game of its own.

I am starting with the combat sub project. This chunk focuses on the control of the player as far as general movement, combat and other interaction with the enemies. It also will have the rpg leveling up aspect that I want in the final larger game.
The tiny game that will come out of this will be the barbarian facing an unlimited number of enemies continually entering the screen.
Right now I am thinking the game will not even have a scrolling screen and instead just a static playfield.
I'll add a little clock or an enemy kill counter. Just something to turn it into a game. The goal being simply "how long can you survive".



The gif shows...

* First is the idle
* Next is the normal jump straight up
* Followed by the moving jump / leaping (which cannot be controlled in air... I am still debating on that one. I do have something in mind for this leap I will talk about a little down below)
* Walking
* Then the normal attack (which actually this is only a beginning... I have something greater in mind for this)
* Finally you see his dash attack

The "barbarian block" is starting to feel pretty good at this point.

Definitely not done with the character control yet but it is a good start. Hopefully, my next dev session I can finish the first draft of the character's combat skills.

I've done the same in Sulium (cannot control in air) and have left it that way for years, lately though I've been considering allowing partial control. Essentially, I'm considering allowing the player to 'pull back/push forward' in flight to adjust the distance covered, but continue to prevent any change in direction (this is in 3d).

This will still fall well short of the freedom to control and move in air that say a platformer gives you, but helps make up for the fact that while in real life, you can make a lot of adjustments to your launch (speed, power, verticality etc) to aim your target landing that don't translate well to a real time game.

Ultimately, I would say try it both ways before deciding. controllable will almost always 'feel' better to players, but uncontrolled may still feel ok and if it is needed to support an intended gameplay design, that is important too even if not everyone is as pleased with it.

I agree @Ortu. I plan to just prototype everything and figure it out based on what feels the best. Normally in a platformer I think being able to control the character in air during a jump is a great thing.

There are some excellent games that did not allow the in-air control most notably probably being the Castlevania games at least the early ones from the 80s and 90s. In those games that was part of the challenge of the game. Not a huge amount but enough to make a person pay a bit more attention to the jumps.

I'll probably end up allowing some tiny bit of in-air control. Your idea of actually limiting the control to the direction the player is facing and not allowing them to change direction in-air is actually an excellent idea. It gives the extra control expected to make it so the controls don't cause needless frustration while also keeping the amount of control within reason.

For me it's about prototyping. I am not sure when I will be to that phase of working on the platforming sub project. That's where I think the control will be handy. For now I am focusing only on prototyping the combat and general feel of the character.

The goal is to make this rectangle feel like a barbarian warrior. If that can be achieved with a rectangle then it's golden. Later graphics can be replaced although I am seriously considering keeping simple abstract shapes.

Animation will be pretty key for defining how the characters feel, particularly with abstract shapes.

Keep the attacks swift and sharp up front with a longer ease-out follow-through/recovery can help them feel like wide powerful swings one would expect of a barbarian

You might play with an upside down trapezoid, giving the impression of broad shoulders/upper body with a narrowerror waist and legs

@Ortu yep animation plays a part for sure. I'm just not very big on the graphics work. For now my goal is limit graphics & animation as much as possible and focus on behavior, control, technique/skills, feel etc to accomplish the goals.

Then at the very end I will take a look at the graphics work and decide how much work to put on that side. I'm to the point with game dev where I'm pretty keen on just using solid color rectangles to make games and leave it at that. But like I said I will sort out the graphics stuff later. Need to focus on the important stuff first (gameplay... making it fun and also feel a bit unique). Graphics can always be replaced at the end.

Just a quick update here. This new strategy of only spending 2 hours on game dev per night and only for 2 to 3 nights per week is working very for me. I'm making good progress without any feeling of hurrying or other stress that leads to burnout.
So basically about 5 hours per week average seems to be good for me.

Alright so I have continued to work on the barbarian character control and skills

Added attacking while in the air, ducking and attacking while ducking


And added the Ground Smash attack.


The player character now has...
* Idle
* Attacking while Idle (or walking but walking is stopped when attacking)
* Walking
* Jumping
* Attacking while Jumping
* Falling
* Attacking while Falling
* Ducking
* Attacking while Ducking
* Dash Attack
* Ground Smash Attack

Of course, the idea is for this game to be a platformer game with more to it than the norm. "Better" combat and also some RPG aspects. The player won't have the Dash and Ground Smash attacks at the beginning and will need to level up to obtain those skills.

Alright that's it for this update. I'll be back in maybe a week with another update.

Liking this a lot, the character controller appears well done, responsive and smooth.

Finally got around to bringing the first enemy to life.

I think I mentioned previously a major design goal here is to make the combat a heavier focus for this platformer game.

No work has been focused on the platformer piece yet.... that will be much later on.

The combat is not live yet meaning the player and enemies cannot actually hit each other dealing damage. I only focused on bringing an enemy to life to try to make for an interesting opponent. Again because I want this to be more than the normal one or two hits one or two bounces on their heads kills an enemy. I want kind of like a mini Mortal Kombat or mini Double Dragon (meaning combat scaled way down from those) feel to the game.





Next dev session I will be focusing solely on some graphics FX just testing out minimal ways to jack up the display.

This looks like it is going to be a lot of fun to play. It will be interesting to see how you implement damage dealing and hitpoints/life.

@Chris thanks for having a look! That's definitely my focus. All on the feel and fun factors. My view is if a game is fun to play with just rectangles then you know you're on to something.

Basically both the player and enemies will have a certain amount of health. The player will be able to see their health but not the enemies. I kind of think the enemies going around with little health gauges floating above their heads can be good but has been way overdone.

What I want to do is achieve the essence of that by the behavior of the enemies. Full health engages readily. Wounded... more cautious. Near death a different behavior. Basically things such as how often an enemy returns to an idle (resting / recuperating) or defensive state. Simple yet still expressive and readable (I *think*) solely based on their behavior.

We'll see how it goes. I just have always wanted to see a little more use of programming and behaviors for games. Some genres do. But there are standards in each that are seldom strayed from.

Amen

Will your level design have emphasis placed on AI character interaction, physics obstacles or puzzles? Or a general combination?

@Chris Tate I'm not sure yet. Right now I'm focusing on just the combat piece and the platforming piece will be later on.

In general I have some ideas but not specifically designed any levels yet. Basically it will have the normal platforming stuff of moving, jumping, etc. But one of my goals has always been to focus on interaction which I believe is the essence of a game. "More interaction and better AI" are important to me.

That doesn't mean I am going to waste countless hours building complex systems. Just means I want to carefully choose where & when to focus on these things. And hopefully it all ends up to a meaningful difference over the majority of games.

I never really cared for physics-based games. But the essence of those as far as some interaction... move object to this point... that may well be in there. Because that I see as just a way to make the levels more interactive. But I am not using any canned physics system.

How are you approaching the AI?

Rather than myself trying to anticipate and provide detailed responses to various situations and actions, I tend to prefer breaking things down into a set of very simple input decisions and defined abstract behaviors which can combine more organically into complex actions and behaviors.

AI never seems to be something discussed much around here

@Ortu Basically everything I do for game programming comes down to state management.

For example, the first enemy is nearly complete as far as their general behavior and combat are concerned.

This first enemy has 9 different states:

Idle (just the normal standing still idle animation for the enemy)
Advance (to within attacking range of player)
PauseBeforeAttack (for playability the enemy delays a slight amount before actually attacking)
Attack (this enemy has only one straightforward attack)
Retreat (this is so there is some back-and-forth interaction to the combat which is one of the key things I am going for... after the enemy attacks it then immediately retreats in an attempt to avoid an anticipated counter-attack)
Injured (this is just the injured animation for the enemy)
KnockedBack (when the player has hit an enemy with enough force it is pushed back a ways)
KnockedDown (when an enemy's health is below a certain amount and it is hit... OR when the player performs the special Ground Slam attack.... enemy is knocked to the ground... it may also be pushed away as well)
Dead (this is just the death animation for the enemy)

The actual delay in the PauseBeforeAttack state is based on the health of the enemy. Although it probably seems backwards from a playability aspect it worked out better to have the enemy pause delay decrease as its health drops from being injured.
Of course, in any case, if the player dilly dallies too long before attacking or moving out of the way they will be struck by the enemy.

But yeah basically I have always broken down complex behaviors into a series of different states. I never knew I was using a State Machine until I came across the term many years later.
To me it was just a natural evolution in my game programming. I knew that trying to see everything as a whole and implement it that way was either unfeasible or greatly over-complicating things.
So I came up with the idea of breaking the complex behavior down into a series of distinct actions. And by chaining each of these simple actions together into one or more sequences (Action Chaining is what I called it) I could produce as complex behavior as I wanted to.

There are a couple of other benefits that comes as a result from this approach:

1. It greatly simplifies the code making it easier to debug & enhance because I can concentrate on any one state at a time and in some cases may decide to break a state down into two states. That was the case with the Attack which became PauseBeforeAttack and Attack. Each dedicated to performing only that specific action in the chain.

2. Performance. Each frame the only code that needs to be executed is the code within the current state. Obviously, some code to sort out the overhead of which state routine to call but that should be super fast. Generally SELECT CASE structures are turned into Jump Tables. Not sure if AppGameKit treats them them way but anyway sorry got lost in a ramble. Oh yeah, each frame the only things that need to happen are processing to handle the requirements of this current state such as incrementing a timer, performing an animation and checking for only those things that are possible to do from this point in time from this specific state.

So... together this is extremely flexible and powerful.

So all of that just to say I simply use states to manage the AI. I decide how I want an enemy to behave and then I model that behavior through a series of specific states each handling one tiny piece of the overall behavior.

I also use States for the player control and basically everything else as well such as a GAME_STATE which may have Title state, GamePlay state, GameWon and GameLost States, etc.

EDIT: That all may not have really addressed how I approach the AI I guess. lol It tells how I implement it by breaking it down into a number of tiny action components.

From the high level view... basically, the way I approach games is I design an enemy. And I define certain abilities and limitations for what this AI character can do. Then I put myself into the role of being that enemy and using what I have to work with (the abilities I decided on earlier) and keeping the limitations of my abilities (decided on earlier) in mind I know the behavior I want to model. So when an enemy is in my game it is basically me... lol... it is what I would do if I was that enemy and had their abilities and limitations to work with.

So, for an enemy in a dungeon walking across a platform for example... that is me... and in real life I would walk to the edge and look around for intruders (perhaps in the context of the role for this enemy) so that enemy will walk to the edge, stop & look around... then I might turn around and walk back to the other side of the platform OR maybe (assuming the enemy has that ability) I decide to jump down from the platform and patrol the area below... so in this case unless I have some other data to base the decision on it might end up being like an 85% chance that the enemy will turn around and walk back to the other side of the platform and a 15% chance the enemy will jump down and check out the area below. If the enemy decides to walk to the other side of the platform this repeats again... stop... look around... decide what to do next. Of course, if the enemy can hear sounds they might drop down to investigate, if they see something below they might drop down to investigate.

I don't use waypoints and pathfinding systems. Instead the enemies navigate their environment the same as I would. They look and see where they can walk. They know when they are at the edge of a platform. Basically they have all of the information I would have if I was them (again within the limitations I set for them).

It might be an odd way but this is how I have always approached it (unless I am making something super simple with canned enemy patrols this area walk back and forth and that it is, enemy flies across the screen and that is it). Each enemy is actually me. Basically inside that creature and using the abilities it has I decide what my options are within each action step and I program it accordingly.
But of course, it may be a very simplified approach because again I place limitations on these enemies. An enemy doesn't need to actually be like a real-life humanoid.

Hi GarBenjamin, just come across this thread, missed it as I normally look in the AppGameKit WIP section.
Looks like a cool project and the first GIF in the first post caught my eye as it reminded me of Shadow of the Beast at first

Will keep looking in on this thread as it looks very interesting, good luck with it.

@SpecTre thanks for dropping by. Glad you find this project interesting so far.

I didn't know there was an AppGameKit Work In Progress forum?! I only saw a Showcase which I thought was for finished & released games.

Oh heck yeah... you know come to think of it I do remember seeing many WIPs in the Showcase.

I guess when it came time to create a WIP thread for this I must have looked for a forum with WIP in its name and ended up here.

Heh, yeah this board is mostly used for older DBpro WIPs that are still pushing along such as Chris Tate and myself, nothing wrong with putting it here of course, but you would probably get more traffic/attention in the AppGameKit showcase.

Okay, I basically finished off the behavior of the first enemy. I still don't have the interaction in for the player ground slam attack but will do that next dev session which will be either Thursday or Friday.
Definitely am loving this new way of working just 1 to 2 hours one night. Then take 1 to 2 nights completely off from it doing nothing. It makes it so when I am working on the game my mind is fresh and I can make great progress quickly. Not feeling burnt out in the least.

I also updated the EnemyManager so it sends out enemies from both sides of the screen now. Since the idea is this combat piece will end up as its own standalone game. Same as the platformer piece will end up as its own standalone game when I eventually get to that.

So here is the first enemy. I'll need to decrease the health of this enemy because this is supposed to be a relatively weak one and I think it takes too many hits to put it down for the count.

There is some randomness on how the enemy recovers from a knockdown. It may simply stand up idle for a tiny bit. It may stand up & immediately retreat (which you will see sometimes I miss it due to this). It may stand up and immediately attack.







You should be able to see how this enemy is simply making use of the 9 different states I wrote about earlier.

Overall, this is coming along well. I am happy with it. It's actually fun battling with these enemies.

Yes this is similar to what I am performing for my game (the main difference being 3 dimensions and my preference for waypoints and zones for specific situations and scenes where it is more convenient for me to click edit than hard code, such as for the AI walking up a spiral staircase or jumping through a narrow window.)


What you have just demonstrated is quite interesting because a lot of traditional 2D platforms simply have the AI assigned to a simple attack pattern bound to an an intervening period of time; but your AI seams to be dodging as well as attacking. This would interesting challenge for the players.

Very similar to how I am handling it as well. Ultimately the only thing that my AI module really does is set the exact same input states that the player control module can set (evaluating behaviors to determine which states to set). If the player can press 'w' to set the state 'move' or 'spacebar' to set the state 'jump' the AI can likewise set these same states. Neither the AI module nor the player control module do anything directly, the character controller handles the evaluation and action of states for all character entities player and npc. As it is an RPG, a variable delay time is built in to setting inputs emulating player reaction time based on character stats, as applicable stats get better such as agility, AI reaction times get better.

As for behaviors, the main difference for me is that I am working on a 3d open world environment, AI will not always be in direct conflict with the player so I have to handle additional top level states like passive, in combat, and traveling about. I also define different behaviors depending on whether a detected character is a friend, foe, neutral, or unknown. The friend behaviors can build complex teamwork and cooperative actions, the combat behaviors can determine how aggresive/defensive/tactical/evasive an enemy is when it is deciding to whether to approach, retreat, attack, defend, flee etc

Nothing wrong with having it here or you could just ask a Mod to move it.

I am liking your enemy AI with dif features of attack etc.

@Chris Tate and @Ortu it seems like we're all three basically doing the same kind of thing conceptually at least. I am sure the exact implementations vary quite a bit.

I think it's awesome you two are sticking with Dark Basic to finish your games. If something works for you... and you've invested a lot into learning (mastering even) a language & API as well as developing custom tools and establishing development patterns and so forth it makes great sense to just stick with it.

As Stardew Valley (developed in C# & the "dead" XNA) shows very clearly... it is not what you use to develop the game that matters... it is how good & interesting of a game you make and how much attention you can draw to it.

Well you know what I mean. It only matters that a person uses what is best for them to use to get the job done as efficiently as possible while also enjoying the journey. Way too many people these days think the only "real" game dev options are things like Unity, Unreal and GMS. Which is ridiculous.

Personally I find AppGameKit to be the best option I have come across in a decade or more. I never really checked out Dark Basic. I was into Blitz3D though. AppGameKit just makes it all dead easy so I can focus on my game. And it is all programming-oriented which for me is what I want. I work much better this way. The only visual parts of Game Dev I find useful are image editors / paint programs / 3D modelers to create graphics, tile map editors to make tile maps, etc. Other than that I just want straightforward programming so I can get it done.

AGK grew out of DBpro, in many ways it is a DBpro 2.0 they have essentially the same core command set and design patterns, AppGameKit has refined the syntax and added some additional functionality and considerations, particularly for mobile and cross platform, but they are still very similar and most DBpro code can be converted almost directly to AppGameKit code.

There are some more deeper level differences such as directx vs opengl, compiled vs interpreted bytecode, dll extension support and so on, but if you use one, you can easily pick up the other and they mostly *feel* the same. it's largely that feeling that keeps people here for a decade plus i think

I like DBP and AppGameKit because they present a blank canvas. This nature of development can be misleading to seem primitive, It can be easily underestimated how valuable it is to be able to have near to nothing at initialization; this is perfect for what I want. I do not want to have to deal with library dependencies, references and content management in DBP; that's what SQL and Visual Studio is here for.

@Chris Tate I agree and in fact just posted about that on the Unity forum about 45 minutes ago. Basically same as you said... I like not having all of this other crap to think about. Think about how to workaround. Think about how to disable. Etc. With AppGameKit unless I explicitly write code to do something or explicitly use the API to do something it won't be in there. And that simplifies things so much.

Just a quick note here to say I am not dead nor did I officially drop this project. I just haven't done anything on it the past 8 days. That's normal for me though. As the days become nicer I have less and less interest to be inside working on the computer. Also been getting back to my fitness focus big time as well as some projects around the house.

I might drop down to working on this game maybe one day per month or so. Not sure yet.

nice work