Could I make a living being an Indie Game Dev?

The problem isn't really frame like this, it's not dumb vs complex, because the complex can really support both in some way. It's a problem of workflow. I mean it's like windows 10 is starting faster because it figure out we do need to load all the starter program before the desktop itself. It's just that they didn't thought about the other use case in general.

In my case, the cost of starting up is negligible when I'm starting a big project with known planning.

However in order to jolt down small verification of algorithm it's taking a big toll because it slow the thought process, and takes more time than the implementation itself.

For example right now I need a visual confirmation of raycasting technique I'm doing, it's basically trigonometry in recursive space, doing that in unity is a misery, there is no reason for it though. With blitz I can have faster turn around, and since I do a lot of pcg stuff, I always verified in blitz first because there is literally no set up.

What it would take for unity? well the scene should be scriptable, ie a zero gameobject script so I can notepad during the lauch then drag and drop the script and press play, done, workflow solved, also some way to have basic coding directly in the ide, I don't want to open random code smuck software to do a simple tweak. I find it foolish anyway to pay the cost of a transform and a monobehavior to just have basic code running, even rpgmaker have generic "event" for that case.

/rant

 

If it's something you want to do and / or it entertains you for a few seconds then sure. lol

Of course it all depends on the goals. But the things we are talking about none of them let a person make a game that cannot be made in another. Well.... if it was something like a 3D engine versus something that only has support for 2D then... well no because I guess then the creative developer would make a pseudo 3D game raycasting etc.

I just meant most any of the dozens of most popular dev platforms let people do basically any kind of game they want. They just have different workflows, different architectures, etc. Look at all of the Indie games out there some are made in various languages and engines/frameworks such C# & XNA, GMS, Unity, UE, AppGameKit, Construct, etc I've even come across a few games developed in C/C++ and OpenGL or OpenTK. So in this way I meant it doesn't matter what a person is using as long as they can complete games in it (and enjoy doing so!).

It's amazing how many people are working on games. I read someplace that Roblox that 3D (I think) game creator thing typically thought of as "for kids" (might have changed I don't know) had over 40 MILLION games created with it so far. Ah yeah I found it and 30,000 new games uploaded every day. Imagine if they were all headed to Steam. I'm guessing that has to be the absolute largest game dev community of them all.

 

You should just say "to heck with all of this nonsense" and download MASM and drop down to assembly. That may be where you find your max productivity. Remember you will never know for sure unless you try it. LOL

 

Nah, it doesn't have ready made line or shape drawing, which I used to visualized stuff, I dn't want to redo basic drawing routinen or basic data structure

 

LOL! I was being silly. I get what you are saying completely. Something like Blitz3D, DarkBasic, etc they basically have everything needed to make a game. They definitely could use some extra tools like you mentioned but one could also fairly easily build World Editor inside them. But yeah there is a HUGE difference between using something like those and doing it all from scratch at a super low level.

I think I read something about a light Unity version being made or maybe I imagined that? Maybe it was some kind of light engine DLLs for deployment.

 

Uh, I used to be playing around with DarkBasic... "fun times"

I'm also following this guy: https://www.youtube.com/channel/UCaTznQhurW5AaiYPbhEA-KA
Very interesting series and it has a ton of information about low level things, knowing how it's made is useful I think.

 

In case anyone didn't pick up on that Roblox may be another option for making a living as an Indie Game Developer. I wasn't sure if I should just post that outright because I don't want to tick someone off but the thread is about making a living as an Indie Game Developer not about doing it in any particular engine so that's why others came up.

I've looked at it a couple of times from this angle over the past several months. It seems like a massive community type of thing like an island of its own. They have millions of players and they have some developers making a lot of money. And it seems like it is constantly growing at a very fast rate. It is not something I want to get into.

So if a person didn't mind very low fidelity style visuals it could be an option. I completely get some people might only want to make mini AAA style games or at least games with different visuals for a different audience. But often it is easier to gain success by finding the big thing and going there. So just throwing it out here just in case someone might be interested in checking into it. I don't know for sure but I am guessing most of the massive number of games being uploaded every day are likely things thrown together by very young kids. This is good and bad for you as an adult. Good is you can probably do a better job making a solid game than a 10 to 12 year old. Bad because you probably don't have as much of an imagination & creativity as they do. Probably much better for all of the folks who are like <25 to explore as an Indie Game Dev career. But that is just my view based on the community being so young.

There is some information here and here.

And this... actually these games don't look bad at all.

 

I watched some of his videos a month or so ago. Yeah it was interesting stuff. He has a good attitude.

 

For example particles, why should i write 20 code lines to make particles, and modify again values to tweak the particles, when i could just drop a particle object , assign texture tweak values in real time ?
Why spending so much more time coding the particles ?

Simple blending will make a huge difference, without blending walk to strike for example will look like weird not smooth.
It's a real benefit for 3D animations. It's as simple as moving a slider in Unity to adjust blending, why spending lot more time coding each blend for each animation.

It's real physics using applyind a force or setting velocity, used in most games.
While you could fake physics, it's faster using a physics engine and you have lot more gameplay possibilities looking lot better because it's physics (approximation).
Looking at video you seem to talk very simple 2D cubes and floors lol
Because 3D and physics is lot more complex when you want to fake it and make it look really good.

It's entirely related to your game 2D or 3D, and graphics with gameplay complexity.

Let's say some 3D rpg action with semi realistic graphics like Zelda BOT, you'll use particle editor, physic engine, terrain
tools, path builder tool, procedural house generator, character library.
You'll spend lot more time designing the story and quests, level design towns and outdoor specific places, balancing gameplay.
You won't want to code particles or code some physic engine LOL
3D engines like Unity value is they allow to speed up game creation and also give 3D artist many ways to focus on content and gameplay instead of coding low level Apis and tools.

While for very simple 3D game or 2D game, you can code lot of things if you want like particle or physic engine, but this remains additional work you could skip using existing features and tools
Like some people coding their own engine for their game, it's a matter of choice
https://twitter.com/kidbabygame
What you like to do, and how much coding you are ready to do instead of focusing only on coding the gameplay.

 

Unity is lot more organized, there is project and scene notions, component system, C# is OO language that helps a lot separate each object logic with ot's own script, events like start and update to manage objects per frame.
While Blitz 3D is one unique very long code file to manage your game, it's good for tiny games, once you want to make something bigger it's a nightmare or impossible LOL

Definitively a big advantage over Blitz 3D when you want to make a 3D game without leaving the editor.

I don't find any game good looking or with unique gameplay in that video LOL
Nothing appealing, i think this is more for kids to play such games, they don't mind about graphics and don't pay attention if graphics are coherent or have good palette colors and other stuff.

There is also Garry Mod in the same way about people creativity.
Or people making money creating characters or stuff for "the sims" for example.

 

This isn't accurate. First yes you could write a simple particle system in a couple hundred lines of code or less that let's you handle both explosion style particles as well as orbiting particles for power up / shield FX, etc. A particle system can be wrote in 10 minutes. Might spend more depending on how flexible it needs to be. Say it takes even 20 minutes to write one handling some very specific cases such as being able to handle standard particle explosions as well as orbiting particles for FX such as collecting an item or a shield fx with stuff spinning around another object such as the player. Spawns, orbits while fading out as life expires.

Is it really faster to get the same results from using a built-in particle system? I think most people would spend at least the same amount of time if not more just tweaking parameters trying to get the FX they want. And I definitely understand for a lot of people it might be much more enjoyable to tweak parameters than to write code. Probably people don't realize how much time they even spend because they are happily clicking things and moving sliders, entering values, etc.

I am not saying this stuff isn't good but things like this come with hidden costs. Sure it is super fast to just throw something anything on the screen and get "a result". Generally we want specific types of behavior specific results and to get those you need to then play around iteratively adjusting parameters watching how that changes the result until you get what you are after.

It might be faster for some people I am just saying for me it is not and I have seen more than a couple of videos where people are creating particle FX for a game jam, etc and spend a fair amount of time adjusting things to get what they want. It's not like watching a rehearsed tutorial video with someone showing how to get a specific result.

Some people might be able to get the result they are after easier & faster than by writing the code themselves. I won't say they can't. And they definitely might enjoy working that way a lot more. Completely understandable. At same time that doesn't mean that someone else cannot write it faster in code.

I don't spend any time on it. lol I had the impression it must be a fairly time consuming process due to reading stuff from other people talking about the struggle they had in getting the blends to work basically they spent a lot of time on it. Maybe they were the exceptions not the rule. That could be.

I just think you are oversimplifying things greatly. The built-in stuff sure it definitely allows you to throw together simple things quickly. It lets you get some stuff get a result in a short amount of time. The cost increases greatly when you are trying to get a specific result you are after or solve a specific problem and end up feeling like you are battling against the internal system you are using.

But again I agree completely if it all works for you then definitely of course you should use it. For me all of the tweaking and testing and resolving unknowns that pop up wastes more time than if I just didn't deal with any of it at all and just wrote my own to begin with. Sure the upfront cost is going to be higher. Where it pays off and saves time is everything from that point forward. Really it's a matter of when do you deal with the work. Upfront or at a later point. Do you want complete flexibility & freedom or can you live with the crafting tools you have been provided. At least that is how I see it. Again I am all for people using the stuff just not in making blanket statements that they are automatically better for everyone.

You are right something like Zelda BOT is going to take a good amount of work. I think that is the case for no matter what a person is using imo if you are going for presentation and implementation of mechanics as they are there. And there is nothing wrong with that for a large team going into it knowing it will take them years to make a shallow version of the game and they are fine with that. I would question why a solo developer would be thinking about making such a thing only because does it really make any sense for one person to be looking at and setting out to make games that are made by a development team of 300 people? It's mainly this that I disagree with.

Some folks made a version of it in Minecraft.

 

How long have you been using blitz?
you don't have a notion of scene, because you don't need one, even in unity I barely use scene so far, it's just a collection of objects. In blitz you use an include, which is concatenate at the line you place it, which allow you to separate file and have custom scene quite easily, unlike the monolithique inflexible scene stuff you get with unity.
Also while not OO it has structure like object stored in a specific list, so you can access them even if they don't have reference to them (kind of a heap). Which mean you can basically DOD them or use OO like handling or just plained implement OO yourself: http://www.hpquest.com/techlord/apps/AOBPwB3D/AOBPwB3D.pdf

Why not invoke library anyway? Unity is more than a visual editor, it's also a library, once you get that first object place in the scene and the initial script attached to it (which will act as the main), you don't have to do anything else but write regular code, with access to the library from the main script, but as long as all class don't derive from unity, you are free. SO you can use code to create and invoke the particle system and tweak everything from there no problem, and supplement it with your own extension. Which is how a lot of advance unity game are made with programmer lead team, they do it even more hardcore by using dll and do everything in c++, only using that single script to interface with unity's object (and cull the designer to the editor).

 

You will tweak faster and better moving sliders and see particle change in real time, instead of changing with keyboard 30 parameters.
Coders vs artists LOL

You type code and values, as you can enter values in the particle properties panel, it's really the same if you don't move the sliders.

Would a coder code an entire terrain system and tools , and enter code to modify the terrain, this would be totally insane LOL
It's again fully related to what kind of game you want to make, and how much you want to code Vs artists focusing on tools to get results as fast as possible.

300 people means triple A and a huge volume of assets, code, content etc ...
Who lonewolf indie will make the same triple A games as Nintendo , Naughty Dog or Rockstar ? None.
I don't think we were talking about triple A games ?

 

Also it's worth pointing that a bmp is a valid and quick level editor to place stuff

 

LOL! Right what this really comes down to is we all should work the way we want to work.

All of these things being mentioned by all of us are preferences not absolute the best way.

I used to love object oriented programming. Thought it was the greatest thing ever having everything separated out by objects and I thought fundamentally this is was how I was developing before moving to proper OO many years back.

Ultimately I see it all as two things... we have data and we have processing. It makes perfect sense to me to wrap up the data in a structure which could even be a class but in that case would make more sense to just have a struct.

Straightforward procedural programming working on collections (array, list whatever is irrelevant) of data in managers.

Focusing on all of these objects in isolation has little value and increases the overall code complexity. It is more than just this. If people stayed with just this it would not be such a big deal. But everyone I have ever seen go down the OO path including myself ends up breaking things out more and more and making their overall programs more and more complex more abstracted away until they end up with craziness like implementing command patterns and so forth that in isolation have basically no meaning at all. The only way they can be understand is by tracing code around following it through everything to see how it actually works. And we have experts out there saying this is good. LOL

People who greatly support OO say that is fine and even go as far as to say you don't need to understand exactly how everything works just that it works. The whole black box view. It sounds good in a way. But I'd say as programmers we should know exactly how everything is working. We shouldn't be striving to encapsulate things and hide their implementations away to begin with. Who are we hiding it from? Ourselves? LOL If anything we should be striving to increase clarity and make everything as obvious & straightforward as possible.

It is far more beneficial to make those implementation details stand out like a sore thumb. Make them so obvious they cannot be missed and to have everything written as plainly and simply as it can be with a bare minimum of abstraction. It is a heck of a lot less likely to introduce bugs compared to something like ThisClass makes use of this abstraction layer that in turn does something else ultimately so generic in implementation that it has absolutely no meaning on its own which is typically the goal many people who follow this path seem to strive for and what they are told is the best way to do it.

I think we all agree it is a personal thing. In the end people can do whatever they want. I am just sharing the point I am at on it having been through all of that. I probably have a dozen books around here still on Design Patterns, Object Oriented Design, OOP etc in C++ and so forth. Because I was really into it big time. But I think of it as mostly all flawed from the start now. It's part of why software development has become so complex and so expensive.

Anyway do whatever as long as you are able to complete your games and have fun doing so.

 

A black box can be a terrain tool, why should we care about the tool code , it works and let us create the terrain we need. No time to loose with the terrain or tool code until you need to do something very specific.
Do you know all the code behind the 2D engine you use ?
Until you want to create all things from scratch, you will be lot more slower to create a game than someone that does not need to code the engine and tools.

Anyway, it's easy to understand all your argumentation, what you enjoy and like the most is the code,
you prefer to create a sprite typing hexadecimal instead of using a paint tool LOL

 

I don't mind terrain tools at all. I was talking about you mentioning something like Blitz doesn't have OOP. I don't mind any tools that actually help when you need them. I can build 2D tile maps in code and have it done it many times. But I prefer using something like SpriteTile when I worked in Unity or Tiled in general. I can build all of the models in code out of primitives but I prefer to do it in a 3D modeling program. I could build up 2D objects in code but it is more sensible to use a sprite editor or a paint program.

It's not about me enjoying writing the code the most. If that was the case I would still be over engineering everything caught up in designing & implementing heavily abstracted overly complicated programming solutions for simple problems.

Basically my view across the board is if you don't need it then don't use it don't do it. Keep everything streamlined and that includes both the programming & the graphics. To me programming the whole goal is just to get stuff done as simply as possible. For a long time I was caught up in programming itself focused more on building complicated abstractions and systems that weren't needed. Then I enjoyed the programming the most. No doubt about it. It was more important to me to make what I considered a beautiful system in code than anything else. But I realized finally it was such a waste. It made everything more complicated than it needed to be.

LOL! The api I use is 2D and 3D and yes it is all open source if I wanted to know I could just look at it. BUT I have no need to because everything is implemented in a super simple flat model very straightforward.

Anyway there won't be agreement on these things and we don't need to because ultimately every person prefers different things. I know I can't be the only one who has come to this point in how I view OO and all of this abstraction nonsense but I still doubt we'd all see it exactly the same. A lot of it is just very personal because it is all kind of like an art in itself. It is a creative thing.

 

Back on the game dev for building a business... here is a game one of the guys on the forum is messing around with in AGK2. He has several different projects he is working on at the same time but this is a little 3D FPS he dabbles on from time to time.

Visually I think this looks nice with creative enemies and the environment looks quite detailed and feels spacious.

Gameplay wise I think it needs a good amount of work like it would be better imo if shooting at the bots was either much faster or had more of a BANG. And the enemies need to pose more of a threat. Probably the biggest thing. No real sense of danger. Needs a lot more to be a good game imo but like I said it is very early on and just something he dabbles on and am sure he sees it as little more than a graphics demo at this point. It is cool that he implemented mini arcade games inside the game accessible through the computer terminals.

Alright I need to get back to work. It rarely ever happens but I actually encountered a bug in playtesting last night so need to track that down. I hate bugs. They can suck up time quickly but I *think* it should be straightforward to track it down. I'll find out. lol

 

It has cool design, i agree it needs a bit of polishing about player receiving damage effect (the flickering red light or alpha image is a bad choice, instead some more subtle like Gears of Wars for example), yeah the bots need to make pauses,reload and be able to strafe or move randomly around while firing at player (going forward to player only looks not so great and it's a zombie melee pattern not a ranged unit pattern).

Player weapon would look better with smooth camera and some sort of weapon physics swing, something looking more dynamic and less static.

When you compare your game above and Perfect Dark N64 graphics, you can see Perfect Dark has better color palette and textures. It's not super dark textures and very bright ones mixed, it's well balanced, also some textures have less detail to balance the visuals, when there is too much details everywhere this lower readability or graphics appeal.

For one actual game (stylized N64 Zelda like) i use also a very small 3D engine not known and limited graphics , but it's perfect for stylized or flat polygon style games , while it has no royalties and no revenue limit and it can publish on PC or mobile.
Sure some small 3D engines can produce good looking games when you choose the right lighting, texture or use some good graphics style.

Yeah , it's a matter of preference about what tool you use, what amount of work you put on code or graphics

Bugs to fix is not fun but support is part of game process lol

 

I like the colors and textures in his FPS game. It looks kind of unique to me with all of the colored lighting and such going on. Kind of feels alieny hitech or whatever. Perfect Dark seems like a great ultimate game target a solo dev to make one day. Be a lot of work though. I never played it but I have heard it mentioned so many times and in the videos I have seen it looks like there is a good amount to it.

Oh I thought I should say in follow-up to my rant above I am not against abstraction in general or even OO programming in general. When used for the originally intended purpose I think it is great. It is all of these other layers of craziness that have been piled on to use with it over the years that I don't care for. I could still see having an Enemy object for example. I think breaking things out to that level is okay. Like I can see from a pure procedural point having an EnemyManager that is the top level but routes processing to EnemyType1, EnemyType2, EnemyType3, EnemyType4, etc. It really all depends on how much the enemies differ from each other.

Abstraction as a basic thing makes good sense... ultimately in procedural programming this is abstraction...

Code (CSharp):

1. SomeMainEntryPointMethod()
2. {
3.     DoSomePrepWork()
4.     DoSomeProcessingWork()
5.     DoSomeLoggingWork()
6. }

Of course those should all have meaningful names but modularization is abstraction. Modularization breaks things down into smaller more focused units. So at the high level one can easily see ah this is the sequence that is followed. Starts with this step, does this step next, finishes up with this step. Yet the implementation details are hidden in the sense they are not contained right here.

That is sensible. Break things down into smaller parts. But things have gone sooooooo far beyond to breaking things down into such over generalized tiny tidbits of code. That is what I threw out. Not fundamental abstraction through modularity but the crazy overkill that has become the norm.

Alright enough of that just wanted to clarify.

 

I also use OO to the minimum.
For example enemy will have a common data class about health, attack power and common stats.
But all ai logic will be a differet new beahviour tree for each different unit (or duplicate BT and modify it to speed up).

It's lot of level design work, but it blocky and could be fast using Probuilder, texture are not so complex and you could make a minimalist version of those, keeping color and only few details painted shapes.
The most complex could be AI and AI manager per zone, if you don't have experience creating AI or if you don't know what ai tools to use.

There was a remaster

And i also enjoyed the new version (some textures had too much specular or not great design but i found it looked good design overall)

Perfect Dark had lot of great features modern shooters does not bring

It is related to your game complexity and ai complexity.
More detailed and able to do varied actions and varied animations the more work you'll need.
This is why many indies keeps things simple like animations with simple blending, ai simple actions and animations.

When you work with behaviour trees for ai , when it's about characters, you'll break things into small re usable modules.
This is important because it's lot of work when you make those, but you'll re use most of them for your next game, so you'll be lo more faster to create ai.
For example you'll have detection modules :
- basic distances check module with value inputs (hear, view long range, field of view)
- basic actions ( melee, ranged attack with line of sight)
- movement modules (walk, run, patrol using navmesh, waypoints , or nav grid)
- query strategic path (EQS or your own system)
- ai group alert
- ai group coordination (one ai becoming the leader)
- an all AI behaviour (berserk, ranged unit stay distance and use covers, melee, zombie)
- probability and random decision module to make AI actions and decisions sometime unpredictable.

About simple patterns AI, you can always make a simple game using those very common patterns without needing to create very advanced ai systems.
It's a good overview :
https://games.soe.ucsc.edu/sites/default/files/khullett-fdg-camera-ready.pdf


Breaking things down help a lot in code clarity and readbility.
It's better to have functions like input(), movement(), actions(), switchState(), detection(),alert(), flee(), pursue() etyc ... instead of having one big function with thousand lines of code hard to follow and debug.
It's common coders problem to find the good balance to find between modularity, re usability and straight forward code.

Anyway about 3D graphics , you can go very minimalist and weird, there must be some niche for those games lol





And some good 2D style graphics with outlines
https://twitter.com/i/status/1066350115273801729

 

Well that's sensible to break things out within reason. What I meant is all of this stuff is essentially what we have had all along. At least fundamentally. Basically object oriented programming came out of actually was already considered back in the procedural programming days. It was seen as the ultimate way of breaking things out. Wouldn't it be cool to be able to pass a chunk of code that contained all of the data that it worked on along with all of the logic that worked on that data. But it was also just a different way of breaking a program down into smaller logical units.

What has happened over time is people have become obsessed with the what if scenarios and this caused patterns and a movement to overengineer everything. Truly there are people that would write an abstraction layer on top of every Unity component and every method in the Unity api. Because one day... one day they might want to switch and use something else such as Unreal or whatever. This is one example of grossly overengineering.

Other examples is originally the idea was to break down complex large programs so they are simpler to understand and easier to maintain over time. This has been taken to crazy extremes as well. The ideal for abstraction in modern times is to reduce the code to incredibly generic bits of code that have no meaning at all on thir own because they are just a generic implementation. This completely defeats the goal of breaking things out to begin with.

And we see this in many people's modern OO programs consisting of a huge level of complexity for what are basically simple programs. They will have dozens of code files where there could very logically be 2 or 3. They will have hundreds even 1,000+ classes where there could be dozens. And the real kicker is it is worse the bigger and more complex the program truly is. Because this approach takes everything and adds complexity adds bulk to it.

This is the the stuff I am talking about, I've done a lot of projects in my life from personal to work from tiny to huge and I've seen this time and again as well as with other people's projects that I (well me on a team) had to come in and fix or redo. In my career I have seen where so many projects have failed not because the code was too rigid but because they followed so called best practices to such a degree the codebase ended up so massive and complex (overengineered) the original team could no longer maintain it in an efficient manner. I've seens projects fail time and again to come in within budget and on time for this same thing. Granted here that is often someone setting a very unrealistic budget for time to begin with but not always.

On AI I have done a good amount of work on game oriented AI. My current game is only one of very few games that use a simple waypoint system for enemies. Generally even my simple shmups or platformers have far more true AI implemented than many games people are making.

Like enemies in a platformer aren't patrolling in a given area by using markers or waypoints but instead I always had them looking at their environment. Have they reached the edge, can they see the player, did they hear something. Recently I am exploring simplifying this more by just using markers / waypoints.

Game AI imo is quite easy to implement in a way that is interesting. I thought about it in my defense game as well but again for me just relying on a straightforward waypoint system is a different way of doing things and it fits the needs of the game.

Behavioral trees can be a good tool but again I think much of this focus people have is coming from the same place as all of the abstracting down to nothingness is. A simple FSM or a HFSM will easily handle the needs of 99% of the games people are making. As humans we tend to want to bring complexity into everything. We say it is for good end goals we don't want to be locked in rigid stuff, we want to maximize code reuse and so forth. Maybe the real issue the goals have not been questioned. Is it always a great thing to reuse code for different purposes? I don't know that it always is. Sure it reduces code but at the same time isn't this creating a dependency which is something that also is supposed to be avoided? lol

For me it doesn't matter how complex an AI is that I'd implement I can do it with just a simple construct... having states and tasks. The combination of the states and tasks would be a superstate. The states themselves would be the high level state.

High level states of course can only be defined in the context of the behavior needed. For very simple things they may be Patrol, Combat, Death. Patrol may have tasks of move, gather info from surroundings (stop at a certain point and look around or listen more focused, etc). Combat can have tasks of hit and run basically attack and evade. If it is more complex overall as to how an enemy can behave then some of the tasks from the simple AI would be states.

A more complex AI for an enemy may have Patrol, Engage, Evade and Death. Now Engage may have tasks such as moving into a better position, moving into range, performing the actual attack whether shooting or melee combat, etc. Evade may have move to get out of a certain proximity, look for cover, move to the cover, heal, etc. And of course all of these again can be broken down. Doing it this way the tasks are reusable pieces of code if one wants to do that.

Most of this stuff is pretty straightforward the whole key (I know you know this) is just to break it down and focus on the goal at hand. What is the primary objective at this moment in time. That is the current task. And the state represents the goal at this moment in time. What is the primary goal at this moment? That is the state. For me I include Spawn, Death etc always in states because they represent completely unique states that need to be managed for an enemy in a game. Spawn could be enemies coming out of a building, or coming down the rope of a helicopter or it may be demons coming out of a portal.

But I agree of course complexity in the requirements of the game need to be managed. I am just saying it can usually be done in a much simpler manner than people seem to think.

Anyway... what are those games in the screenshots? Do you have any links to videos or web pages on them?

 

That was so looong. Didn't realize how much rambling I had done. Since you may well skip over it @zenGarden what are those games in your screenshots? They have a very interesting look to them. Do you have any links to videos or the game pages?

 

BT are useful :
- re use available nodes for anything
- visual representation easy without needing to read code , somewhat like general use case , you don't need details to understand what it is doing
- real time visual flows debugging without needing breakpoints or adding visual debug stuff
- used in most AAA games, or BT variation and combination with FSM or other stuff
- easy to use for non coders.

You'll want re usable, until your projects are varied and you don't make the same kind of game often.
Let's say you make a tps shooter you'll re use most of the ai and re usable code components saving you lot of time, and let you create new ones from old ones or modify them.
When you make very different games, like some tps game and your next game is some boat exploration game, i agree you could code lot of things without making things modular and re usable.

It also depends on your game complexity.
For example some N64 game style does not need so much advanced ai LOL
The game is inspired by Jet Force Gemini, doing this simple 3D style allowed to get many variety features on their game :
-12 unique and colorful worlds to visit/discover
-Retro styled cutscenes
-Vehicle combat
-Race minigame
-Arena minigame
-Mech battle minigame
-VR survival minigame
-Weapon upgrades
-Character customization

This is "mouse corp", it seems to be made by a beginner about graphics or someone not talented on that side, that's wht we an call a very special minimalist style (i didn't tried the game to say if it's good)
https://thecatamites.itch.io/mouse-corp

 

Yeah I definitely can see people might prefer visually defining the AI but that is just an option they can choose whether FSM or BT. I used to often sketch out simple diagrams as well to get a visual reference to what I was after. Ultimately you always need to implement those nodes in code. I suppose there are some systems that come with canned behaviors that can be selected but I think even doing it visually generally you drop to the code to actually implement the task on a given node.

If they work for people then definitely use them. I don't see a need for taking it to the tree structure. That's just my view. And remember that is the old way now. The more modern new shiny thing Game AI moved onto is Utility AI. I don't know how widespread it is in AAA but this kind of stuff is always becoming more complex. Just the nature of all things IT related. Most developers these days unfortunately given a choice between handling a problem in an easy way or handling it in a more complex "cool" way will choose the latter no matter if the problem actually needs it or not.

I just think there have been fundamental things around forever we can use for handling such things. You want to chain a sequence of actions / tasks at a given point use a queue. You can load it up with LookForCover, MoveToCover, UseHealthPotion, etc and in this way implement simple plans. You could push any desired action into that queue. Then just process them in sequence.

Of course the greater concern might be in the decision planning itself and that is what Utility AI focuses on mainly I think. But it is the same thing basically. Maybe queue up something like HealIfNeeded, EvadeIfInDanger, Attack and have these conditional items in the queue. Still processing one after the other. All I am saying is there are many simple ways to implement AI that would be hard to distinguish from anything a player sees in any game with so called impressive AI. Here it would be a simple matter of loading some enum values into a queue. Very straightforward to understand very easy to implement.

Alright I am done rambling about AI. lol

Cool thanks! I will check out that game. You seem to find a lot of these out of the ordinary games. I find a good number of them but you find different ones that I have not seen.

BTW I spent nearly 45 minutes tracking down that bug. First of course trying to find a way to duplicate it in a fairly consistent manner. Then I thought well I guess I must not be releasing some resources so I double checked all of that and it was fine. Finally I went to the old tried-and-true way of print statements (Log in this case) and narrowed it down to one call I was making to an api function DeleteAllImages() which frees all image resources that have been loaded with automatic id assignment and more importantly resets the auto ID counter.

LOL! I hate those. They are the worst things and the most common bugs I seem to encounter. A bug in the api / engine itself or maybe not so much a real bug but an unknown. I expected the moment I switched back to the screen for rendering for it to have switched back to the screen. I finally figured out best as I can tell is that even though I had switched from the renderimage to the screen before releasing all images and calling that method it doesn't seem like internally it actually updates until you do a Sync() / Swap() call. That was my best guess and it seems to have resolved the issue.

Of course, really the core problem was my own in that I shouldn't have created the renderimage using the auto ID assignment approach and instead assigned the id myself. Since really the render image (and render Sprite) needs to stay around at all times anyway. And in this way calling the DeleteAllImages() call wouldn't have tried to remove the current image buffee.

 

BT for me it has nothing to do bout cool, but instead it's the most easy way and fastest way to create ai quickly.
Quick overview, best way to debug (any time you know what is doing ai), re usable nodes and actions, no need to read 10 "if then else" code that needs modification while you just change BT nodes connections.
Yeah , coders most of the time don't like that sort of graphical tools LOL

That's another way, but your code can become lot more complex when you want your ai to handle interruptions and events (MoveToCover : event health potion is nearest, UseHealthPotion : event player is melee close, LookForCover : event cover destroyed).
Any ai can be done coding only, but there is huge benefits using ai graphics tools like BT or FSM, at least for artists lol

And other people will find other nice games we both never heard about

 

BTs, FSMs and Dialogue trees are the only cases (maybe we can add the shaders as well, since they are highly visuals? maybe, the jury is out to decide on that one) where I find the visual node-based systems really useful (more useful than annoying).

 

lol

Why not try other 3D engines like Love 2D for example ? It has some commercail games already.

 

AI in AAA is surprisingly very conservative, it's either fsm or BT (BT isn't just visual though, it's a paradigm). BT is popular because it is essentially a generalization of fsm, script and planning, and it's designer friendly, it's something they get. After many attempt of adding a planner, people have realize that A BT essentially do the same thing. Utility used to be cool, but then it tend to suffer from oscillation and unpredictable state, so it's either used as an evaluation pass before a BT, translating the perception into concept that will trigger the BT. SO most AI is either a fsm when too simple (crowd logic) or a core BT extended with some other idea, which has been called "ai sandwich". NN is becoming popular for imitation, though "case based reasoning" has been use in great effect for that purpose with killer instinct xbox.

 

I know I was done with AI ramblings... but what are the problems people are having implementing AI? I mean in general. I guess I don't really see what the needs are that are too complex to be done. Many games I have seen and played seem to have zero AI. Like truly nothing. Enemies patrol in a fixed area or move in a specific pattern they may attack when player is within proximity or los. That is the bulk of games. The awareness as far as player is within a certain proximity / los can be considered an aspect of intelligence but again this is such a simple thing. I'm not sure what the goals are that people are trying to achieve. Really you don't want the enemy AI to be too bright as far as being challenging / deadly as an adversary. That is easy to do but not very engaging and enjoyable.

Giving enemies interesting behaviors is more important I think. I used to play around with the idea of giving each enemy a goal like a sort of life agenda / routine it does. I think I remember posting a simple diagram around here someplace one time about that. Having a game populated with several different critters not necessarily even adversaries it depends on the player actions. Actually I think it was like one was a hoarder and spent its time roaming around collecting things and bringing it back to its lair. It would ignore the player unless it encountered them trying to steal its stuff. Another I think was just a lazy roamer. No goals in its life except roam around, eat, play and sleep. I think it was a coward and would always flee and player would need to chase after it if they insisted on killing it. And then there was a predator enemy type that roamed around hunting.... everything. It would go after the other enemy types and the player. When attacked it just becomes that much more aggressive.

I find this kind of interesting from an AI perspective. But again this doesn't require any complex constructs to implement just very basic fundamental stuff but I think it would result in a far more interesting experience than most games provide in this aspect anyway. I mean how many times do we see different species in games that all seem to completely ignore each other and the only thing they care about is the player. It would be a lot more interesting imo to just (a) give them a behavior beyond how they interact with the player and (b) make them aware of each other and have them battle among themselves from time to time.

It isn't complex to implement just need more creativity in ideas to make things more interesting. So this is where I think maybe people focus too much on the technical side when they would probably get a much more interesting result to focus on the ideas side. This kind of scenario can be used by the player to their advantage as well. Maybe try to lure the predator over by the hoarder's area so those two get into it and then you can also attack the predator and have a much better chance of taking it out.

 

Or Goap

Or a mix

Htn planning

Ai is not only that, but also top level stuff to manage game flow, for example Director AI

There is endless ways of creating ai, but yeah BT and FSM are very common in many games but it's not just that in triple A games.

This is something you have in games like Far Cry , with animals able to attack enemies or the player.

Something we don't see a lot, is predefined ai but able to randomly shoose other behaviours.
For example some mage character using magic, stay at distance and not offensive, when near a melee weapon would be able to choose to use it and go berserk.
Many games uses characters stats to define their behaviour on some situation instead of choosing randomly.

 

To be frank goap and planner are rarely implemented, there is 3 or 4 game top with goap, most htn are in strategy game, and a htn is architecturally pretty close to BT, especially when you start extending it to have scripted event (like retreat when general arrive in scene 5), so given that observation people stick to BT and incorporate concept of other stuff either as action, selector node or decorator. HTN or simple planner (goap) is mostly a procedural BT anyway, it's great when you don't want to map personally the space of decision traded off against some more computation, there was even some talk about using a htn to automatically generate BT (basically baking it).

- Authoring and control

- FSM can grew into a monstrous spaghetti, even when dealt only in code. Especially when you start having exception, for example dealing with high dimensional condition (if health, if distance, if ally in proximity, etc ...). The problem is that it's hard to debug when it scale, as you only have a local view of teh logic. Fsm is also very bad at managing random global interruption in a state, which create more noise to author and potentially more bug. Generally FSM are faster to execute because highly local (no tree traversal) which make them great for a lot of simpler AI (crowd), but even then your producer or lead will give you a stern look to stay within a strict scope of complexity.

- BT is simple to do, simple to read (the logic is laid out plainly even in code and even at scale) and can encapsulate other AI stuff like utility quite well, it has simple concept that allow evaluating state change quite simply without having to deal with explosion of condition and transition. It's basically a generalization of script, fsm and planning. It's scalable from simple to complex ai, so you write it once and don't have to deal with complexity or surprise where the ai do unexpected thing or your project and ai grew in size and complexity. Also you can reuse and combined tree without breaking anything, so adding a behavior from one character to another (or make the character learn new behavior) is as simple as appending a new node. Also it often encapsulate smaller fsm as node to take care of action. It's just more order to the chaos.

Basically BT makes it easier to add interesting behavior and not shot you in the feet while authoring it. It's easier to go from bt to fsm too than the reverse. BT abstract action, evaluation and decision from each other so they are easily manageable. SO if you want to make your patrol, just write the patrol routined, you don't write the los check inside the patrol, you create an evaluation node, and then you create a BT for the decision. So it evaluate, if evaluation fail it continue patrol, if evaluation succeed you shift to the attack node, which you can simply replace with a negotiating node for another AI by simply replacing the action. With fsm you will have to rewrite the transition from inside the patrol, duplicating the state.

 

Another thing BT make easy is smart object, you can have a use object node, that just read the object and append the BT of the object to the agent requesting the use, so the agent don't need to know how to use the object in code. And it would work for any object you would add to teh scene, immediately. With fsm you will have to reauthor all the node to take care of all transition.

So now your patrol node can request to the patrol object the path, and each node or edge of the path have their own BT, so that any character can do the exact same patrol with their own animation set.

BT turn ai into lego.
You just create block of different type like evaluation, decision and actions, and you mix and match them ad nauseaum.

 

I guess I just don't see still what the issue is as far as handling the AI decision making and actions. The logical parts of it. You can basically implement the stuff with a simple if conditions and switch statements as far as decision making and state & task management. Personally I think the details of gathering the data from the world that are needed to implement the actual results are the weakness much more than making the decisions or managing the states & tasks.

Soon we may need to drop down to sample projects for examples. lol

What I mean is say we have a single player game... some cubes (just because it is simple allows to focus on the topic at hand). We have some large gray cubes representing obstacles, buildings, vehicles, whatever. We have several red cubes representing the enemies and we have one blue cube representing the player.

Say 3 of the red cubes are walking around in a given area. 2 more red cubes are standing guard by a much smaller white square.

So 3 of these cubes are in PATROL state. 2 are in STAY_HERE (whatever term you wish) state.

If any of the 5 red cubes see the player (ok we need a LOS function) their state changes.
A PATROLing cube changes state to ALERTED. In Alerted it yells out to its cube comrades (okay we need a EnemyAlertsOthers function) an then it needs to figure out what to do. Immediately attack, try to find a better position to attack from). So it does a check of its immediate area and if there is a cover position within x distance (we need a function FindNearestCoverWithinRange(maxDistance)) it finds one and decides to ENGAGE (state) and begin with MOVETOCOVER(task).
Meanwhile 1 of the 2 other patroling red cubes was ALERTED (state) by its comrade yelling. It MOVEINDIRECTION (task) its comrade yelled from.
And the cubes in the STAY_HERE stay well maybe they also were alerted by the yell and if so they should go into DEFEND state. Which just means they are alerted and looking for something to shoot at.

We know this stuff could be implemented in a number of ways. But I think this example will show what I mean. Managing the decision making and the states & tasks is pretty straightforward. We just set it up as we want to. States and Tasks. The only difficult aspect of this piece is figuring out how you want the cubes to behave what should they do in a given scenario. However all of the details implementing the results are the bigger obstacles. Querying the local environment to find a cover position (we could mark these things during level creation). Making sure the enemy actually moves to the proper side of the cover position a spot where it can take cover yet pop out and shoot at the player (we definitely don't want the enemy to run to the in plain sight side of the cover and squat down lol) so we need to do some more checks. Probably I would have it so when the enemy is within a short distance of the cover area they will find an actual target position for the enemy to move to and the task would change to TAKECOVER. We'd need to implement the yell which could be a simple radius check. Enemies within a certain range of the source will hear it.

The actual decision making and management of the states and tasks is pretty straightforward in the example but dealing with the environment having enough information about the environment in a readily usable way will likely not be as straightforward. Actually moving without going through or getting hung up on objects. Figuring out hey I just got over here and was going to take cover and now I am at the same position as the other red cube who was already taking cover. In my experience it is all of this kind of stuff that is the real work and challenge.

 

Maybe I should have been more direct in my answer, you asked what problem they were trying to solve:
My answer was basically Scale ie through data driven, readable, modular, atomic element

But you are right BT basically a formalization of the "if decision tree":
- sequence is basically a series of IF with the first to fail having a return
- parallel node is basically a if then else (ie find the first if that doesn't fail)
- evaluation is the first if generally
- non selector node are basically function call inside the if
- managing tick rate inside the tree to spread the execution is basically yield, so it's a co routine
- and you can nest it too!

So congrats your if tree is basically a BT hence why it is popular, it's simple, straightforward and fundamental

So since the problem is scale, you don't do BT for very small project, just like pcg don't make sense when you just have 3 different object. It's like sorting, some algo work best on low number of set, some other only make on big data set due to the overhead cost amortized after a certain quantity. BT is formalized to allow fast iteration, good practice, flexibility, and is one of the no non sense pattern, it's battle tested and allow complexity without the downside. It's so generic than in fact some game use the BT tools to also make menu instead of doing the stack poping non sense no people ever understand.

Also it doesn not work alone, you need other concept like blackboard and the like to help, which are basically organisation concept. EnemyAlertOther will probably write to a blackboard for other agent to respond.

 

That's what I mean though. This stuff is not difficult to implement as far as the actual AI itself is concerned. Like all of these things you are talking about specific approaches to implement it. That's fine. But the real work and difficulty is in what comes after this part. I mean it is much more of a challenge just something simple like a vehicle that can serve as cover. Great we can tag it in some way to identify it as a cover spot. But getting the enemy to actually move there and interact with that space taking the presence of other enemies that may already be there is more of a challenge.

A simple way would be to block off specific enemy sized areas around the vehicle. So in reality the data wouldn't even be the shape and position of or anything else to do with the vehicle or a building, etc instead it would be a number of "slots" that can be used as cover positions. Once this kind of world meta data / gridding / otherwise marking up the areas with the information that is needed... once this is done then it's easy to do anything imo.

At least that is how I view it. I focus more time on how to get the data that is needed readily available. So in this case seaching for cover spots it would get a list of available and choose one. When it gets in range before it goes into the TAKECOVER state it would need to check and find an empty slot. To prevent conflict with another enemy it needs to be able to mark a slot as "taken". If enemy dies before using the slot it would need to remove that mark same as when it leave it. Or perhaps a better way would be to mark a slot as "reserved" status which would be some kind of timer based unavailable status which allows the enemy a tiny amount of time to get there while also serving to remove this spot from consideration by other enemies. Of course once it gets in the spot then it should still be marked as "taken" But with a reserved timer based mechanism if the enemy dies off the spot automatically becomes available to others within a short period of time. Again it is these details of implementation regarding the world space that is the challenge. Figure these things out all is possible.

 

This is true, hence why BT is making this part as painless as possible by removing any concern of managing the state out of the equation. SO you can focus on that instead of thinking about how to manage all these state. FSM will give you some pain after a while, so you would had to stop doing the real work and start refactoring, that's a distraction. BT by having clear conceptual pattern abstract that from you and let you define the right atomic action you have highlighted.

The idea is like photoshop, you focus on painting, not on managing how color are adressed in memory.

Put more clearly it's about decomposing structure from style, which use to be a hot debate in the industry, hence why BT is popular, despite being simple.
https://www.gdcvault.com/play/1249/(307)-The-Photoshop-of-AI
http://intrinsicalgorithm.com/IAonAI/2009/10/aiide-2009-the-photoshop-of-ai-debate-michael-mateas/
BT discovery was basically the settlement of that debate for good.

Spoiler: BT of your sample

BT ROOT (parallel)
- sequence Listening //higher because has more priority
-- Check isPlayerFound on blackboard
-- NOT sequence Mode //decorator NOT turn fail into success for the sequence continue
--- Check Stay_Here
--- sequence Defend ...
-- MoveInDirection()
- sequence Alert
-- Check PLayerSeen() //write to the blackboard on success
-- parallel Reaction
--- sequence CheckCover
---- Check isThereCoverInRange()
---- sequence MoveToCover ...
--- attack
-sequence Patrol
-- parallel WayPoint
--- MoveToWayPoint() //can be a BT sequence or a custom code function, Bt don't have to cover everything
--- IdleWaypoint()
--- CheckNextWaypoint()

FSM is assembly
BT is C
Planner is Lisp
script is rpgmk

 

This is strategic movement and actions in some complex environment are driven by level data, it's not BT only.
As you'll see below is not just using BT and actions like simple MoveTo and play walk animation LOL

Horizon PS4 game ai
https://www.guerrilla-games.com/read/the-ai-of-horizon-zero-dawn
Killzone 2 Level annotations
https://www.slideshare.net/guerrillagames/pgaic11
More presentations
http://aigamedev.com/open/coverage/killzone2/

FF15 game

Open World ai

Tom Clancy ai presentations

Sunset overdrive ai

Anyway, none of us will make triple A ai LOL

 

This is what i call a readable Pico game
https://twitter.com/i/status/1066761077210394625

Another dev doing good indie games
https://twitter.com/kircode

And cool 2D beat them up , with perspective design.

 

We are working on AI that makes good educated decisions, understand their surroundings, flank etc

 

Actually, AI is one of the few things where indies can shine. It's not _that_ expensive to have a good AI, so indies could afford it.

 

I was meaning advanced, not the same games melee or ranged units, i'm not sure you'll make better than Killzone 2 game for example lol
Or this one that has many things not common to other games.

Anyway, i would like to see your game, it should be interesting.

It depends on what game complexity and ai complexity.(I never seen any indie game using level anotions generators, heatmaps and other advanced stuff).
Sure, unlike triple A studios making again and again the same fps and tps games (AC, COD and others), because they can't take lot of risks on innovations, indies can make new things more original.

 

Haven't played it, we are more going for fear 1 level if you have played it, or Splinter cell blacklist. You should never feel safe, the AI will flank you, smoke you out with nades etc

 

Very true, AI is more about polish and take your time.

 

Agree to above.

For example, I used Neural Network to design 3D gimbal controller, with customization propulsion. That wouldn't be otherwise possible with typical BT, or similar, providing not using tricks, like rotation lerp.

Optimized model takes just moment to teach.

 

I will have to watch the others later when I get a chance. I watched this one and all I see are very simple behaviors. The huge workload I see here is the same as always the amount of effort that went into the visuals. I see some animals dinosaurs at one part that have a simple run away turn around run back. Get hit turn run away repeat. I see a big beast in a battle doing a stomp and pause. I see an NPC moving with the player and then running up ahead.

This is all very simple stuff that anyone here with any reasonable amount of experience should be able to duplicate. Again talking about the AI behaviors. When you watch these things imagine everything is in ultra low poly or even cubes. That will help to put the AI behaviors into better focus. I'm not saying it isn't good. This is a great example of how you only need some simple things.

I am off work today but have some things to do and will check out the others later.

 

It's not only simple behaviours, you can see lot more than that only, and each behaviour is a high level representation of all systems behind.

Perhaps it can be done, it's just i didn't seen indies using advanced systems like level annotations bake system,

heatmaps , ai groups director like Halo, or specific level annotations and behaviours like in Sunset Overdrive Insomniac game.

There is also a balance when making AI, making it too efficient and too much unpredictable and the player will quickly be frustrated and won't find any fun in the game.

Anyway indies don't need to go for the best AI, good enough and make games you don't find in the triple A market.

 

Anyway one big and difficult part of AI is not the behavior or the logic, it's the feedback toward the player, and generally it mean voice clip and a lot of animation state that are plausible. Fear AI is lauded by its logic, but then people who worked on it would say you it was about the feedback system, the goap was a very little part of it, I posted the source once in teh forums, but I know nobody will care anyway that's the nature of teh beats

Indie just make as complex annotation system, I help steering te people dong Rainworld which simulate complex ecology and have AI driven procedural animation, which is more advanced that most AAA. I don't have time to do a refresh search about the indies, maybe later when I have time.

 

When highly sucessful triple A games can make AI more simple than some indies.

Use AI and tools according to what you like to use and how complex you need to go.
We're going too much out of thread discussion, better keep focus on thread title LOL

 

Well I agree 99.99 % of Indies almost certainly aren't using the same approaches for AI. Most probably aren't even doing AI period beyond patrol on this path... is player in LOS? Yes... okay shoot.

I don't understand why the so called "advanced" approaches are being used for such simple behaviors to begin with. Not saying I expect Terminator style AI LOL but for all of the hoopla over the advanced AI systems they are using I don't see it reflected in the results. Maybe it is more a case of them focusing on getting the environment to be easily readable for the AI to use. That would make sense because that is the key. As long as the environment can easily be "read" devs can do about anything. And that kind of sounds like the level baking thing you mentioned.

For AI in games I think the best places to find that is in sports games. I mean even the old NES sports games had far more going on than the majority of Indie games do. Team coordination, executing plays as well as individual control of the ai players.

These are great sandbox projects for people interested in AI to experiment.