• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.
As soon as possible, as I want to start putting up lore/gameplay updates and such on it. Only thing with Tumblr is that it doesn't really have 'tabs' does it?
I think WordPress.com has options for a free blog. Here you can use "pages" to craft links like "about, contact, etc" using these pages as "tabs". The front page runs just like any other blog. Plenty of designs to choose from or roll your own.

They have paid options, too.
 

bsp

Member
Okay what is this and when can I buy it?

Your game is gorgeous! I'm looking forward to playing it.

Wow, that is stunning. This game just keeps looking more and more incredible.

Everytime I see your game it reminds me of Adventureland at Disneyland. And thats a marvelous thing to remind me of.

Thanks, everyone! :0) This is for an adventure game/immersive sim I am making with one other called Udon Dreams. That links to our devlog on Tigsource if you'd like to see more (no website set up yet... we should do that). Release is unknown as we are still pretty early on in the project. Sorry :(
 

_machine

Member
We've been working hard on the trailer, but I also decided to try my hand at creating a little gif to accompany our marketing pitch:
fBE1mz2.gif


It's definitelly going to need some work on a closer camera, less length and optimization, but I would love some advice on which direction to go towards. I would probably like to add the deckbuilding aspect to the gif, whilst still trying to optimize the size.
 

Kalentan

Member
I think WordPress.com has options for a free blog. Here you can use "pages" to craft links like "about, contact, etc" using these pages as "tabs". The front page runs just like any other blog. Plenty of designs to choose from or roll your own.

They have paid options, too.

I think I will use it. Thanks. :)

Also...

c36b.png


Before I try and animate the walk, I thought I probably should get down an idea of how I make the characters facing each direction.

Also others on previous pages were asked about game titles... So I've been thinking about... The Red Horizon or The Blood Horizon, which might invoke a bit more of the idea of battle or war... I mean to be honest, I don't think trying to make a unique named title for the sake of being unique will help at all. If anything I feel like it might drive people off.
 

Minamu

Member
That humble bundle with game maker and android plugin is over now, yes? I was thinking of getting back into my own programming and relearn my skills I've left dormant for too long :/ But I don't know where to start on pc games now that xna is "dead", feels dumb to ask. Maybe unity? I have a 2d project up on google play but I'm on my own this time and I'd like to code it all in visual studio if possible :)

Edit: Actually, while I do want to use visual studio and do most things from scratch, I do have a book on game programming, that might have some suggestions. Stencyl sounds like fun too and I really ought to learn ue4 too. But if I just want to code some basic 2d game, where should I start?
 

OldRoutes

Member
That humble bundle with game maker and android plugin is over now, yes? I was thinking of getting back into my own programming and relearn my skills I've left dormant for too long :/ But I don't know where to start on pc games now that xna is "dead", feels dumb to ask. Maybe unity? I have a 2d project up on google play but I'm on my own this time and I'd like to code it all in visual studio if possible :)

Edit: Actually, while I do want to use visual studio and do most things from scratch, I do have a book on game programming, that might have some suggestions. Stencyl sounds like fun too and I really ought to learn ue4 too. But if I just want to code some basic 2d game, where should I start?

I don't want to sound like an ass, but have you looked at the OP of this thread? It has a lot of valuable information that will answer your questions.
 

Minamu

Member
I don't want to sound like an ass, but have you looked at the OP of this thread? It has a lot of valuable information that will answer your questions.
:lol It's okay, deserved. I did check it slightly, thus the edit :) I'm on my phone, gonna re-check it tomorrow.
Always nice to talk to someone instead of an impersonal google search :)
 
Looks awesome. Is the whole game gonna be in Japanese?

That's me. Progress is slow, but I'm trying to dedicate more time to working on the game. It's just hard since at the end of the day I'm extremely tired. However, if I'm going to meet my deadline of Q1 2016, then I have to speed up the process and not let my fatigue win out. Generally, I take about 30 to 40 minutes to unwind, then get started and work for 4 or 5 hours. These days I'm working longer since I have to meet my deadlines. Juggling everything is just hard, but bills have to be paid. :(

Thanks! The basic idea is, yes, it should be ENG/JP with a chance for a spanish translation since that's my mother language. But I may have to use Kickstarter to fully complete the JP translation in a speedy manner. Else it'll be at a turtle pace on my own. (But it helps a lot when most of the concepts laid down are already in japanese or the katakanization of a lot of foreign words already took place.)

I agree juggling everything is hard, I mean, my day job is what pays all the bills so, yeah, it's a fine balance and not one that is easy to achieve....
 

Kalentan

Member
I will admit, while I will keep going forward with my game... The temptation to use the YoYo RPG Humble as a jumping off point is really tempting. Maybe if my game is liked enough, I could use it as a template to make the prequel game: "The Five Years" which currently is just a sort of digital novel atm.
 

Jumplion

Member
I think I will use it. Thanks. :)

Also...

c36b.png


Before I try and animate the walk, I thought I probably should get down an idea of how I make the characters facing each direction.

Also others on previous pages were asked about game titles... So I've been thinking about... The Red Horizon or The Blood Horizon, which might invoke a bit more of the idea of battle or war... I mean to be honest, I don't think trying to make a unique named title for the sake of being unique will help at all. If anything I feel like it might drive people off.

Just wanted to say that you've improved a lot of stuff really quickly, really like the direction the sprites are going compared to the original.

But I do think you should slow down a bit, you're pumping out iteration after iteration after iteration, and while it's totally great progress on your end, I'm thinking it might rushing too hard into things. Let things simmer a bit, maybe plan out all the mechanics if you haven't already, and experiment. Try out distinct visual styles rather than small tweaks, maybe really dive into animations if that's what you want to tackle next but settle in and really get the feel for how a character will be animated.

Sit down and chew on the steak. I'm seeing you toss things around a bit too much like a salad, let the pot boil for a bit and figure out how much longer the souffle is going to take to rise. Challah bread. I like food metaphors.
 

Kalentan

Member
Just wanted to say that you've improved a lot of stuff really quickly, really like the direction the sprites are going compared to the original.

But I do think you should slow down a bit, you're pumping out iteration after iteration after iteration, and while it's totally great progress on your end, I'm thinking it might rushing too hard into things. Let things simmer a bit, maybe plan out all the mechanics if you haven't already, and experiment. Try out distinct visual styles rather than small tweaks, maybe really dive into animations if that's what you want to tackle next but settle in and really get the feel for how a character will be animated.

Sit down and chew on the steak. I'm seeing you toss things around a bit too much like a salad, let the pot boil for a bit and figure out how much longer the souffle is going to take to rise. Challah bread. I like food metaphors.

I still think the biggest thing holding my progress back is the AI. Without the enemy AI, I'm not sure I can start on my combat system. Which is really the biggest thing I need to figure out.

Since there is little to no documentation on how to make AI for a Tactics RPG. I just need to get to that point where I can simply put stuff in the game. You know?
 
I still think the biggest thing holding my progress back is the AI. Without the enemy AI, I'm not sure I can start on my combat system. Which is really the biggest thing I need to figure out.

Since there is little to no documentation on how to make AI for a Tactics RPG. I just need to get to that point where I can simply put stuff in the game. You know?
At this stage I would recommend dropping everything else and focusing on combat AI.

You'll need to define a set of rules for enemy options, add a weight system to each ability that they can use that gives more weight to move X when player healh is low or move Y when your health is low, etc. Start small with attack, heal, run. Add on to that with more abilities.

Use flowcharts. Design it on paper first. Test your system with some dice, picking random playing cards, etc. From there, program.

If you will be unable to create a combat system and AI then there is little point to creating all sorts of artwork and cutscenes.

For example, for my game the most important hurdle to development, for me, was physics and collision. The first thing I did when I set out to make my game? Physics and collision. You need to make sure you or someone can handle the meat and potatoes of the game before actually making the game. Cutscenes, menus, all that stuff is nonessential until the end or until it has to be shown. Hell, we have our story and cutscenes planned out since last year and only last week we drew sprites for one of our cutscenes to showcase it because it was necessary. I can't stress enough how important it is to make sure you can actually make the game you want before sinking time into the nonessentials of development.

Just my .02
 

Kalentan

Member
At this stage I would recommend dropping everything else and focusing on combat AI.

You'll need to define a set of rules for enemy options, add a weight system to each ability that they can use that gives more weight to move X when player healh is low or move Y when your health is low, etc. Start small with attack, heal, run. Add on to that with more abilities.

Use flowcharts. Design it on paper first. Test your system with some dice, picking random playing cards, etc. From there, program.

If you will be unable to create a combat system and AI then there is little point to creating all sorts of artwork and cutscenes.

For example, for my game the most important hurdle to development, for me, was physics and collision. The first thing I did when I set out to make my game? Physics and collision. You need to make sure you or someone can handle the meat and potatoes of the game before actually making the game. Cutscenes, menus, all that stuff is nonessential until the end or until it has to be shown. Hell, we have our story and cutscenes planned out since last year and only last week we drew sprites for one of our cutscenes to showcase it because it was necessary. I can't stress enough how important it is to make sure you can actually make the game you want before sinking time into the nonessentials of development.

Just my .02

It's not so much that I don't know what to include in the AI but more so how to actually write it.

Like how do I start it? How does it know what enemy to select first and how to do it's entire phase enemy by enemy before concluding. How do I make it so it doesn't rush through it, so it actually needs to wait for each part to finish before continuing.

When the enemy phase begins it needs to take into account...
  1. Player Heroes Positions (Also which direction facing)
  2. Enemy Positions (Also which direction facing)
  3. Enemies Health and Mana
  4. What is the objective?

Cause it needs to be an AI that can be used over and over. I can't just make all of this for one specific set of enemies. It needs to be something that can take into account all of the enemies, no matter how many I put onto the field and take advantage of their own specific movement ranges/skills.
 

Jobbs

Banned
I do the flow charts in my head and as I work, possibly because I never really knew the right way of doing anything. What made sense to me, as a person with no programming experience and just working within the range of things I knew how to do in stencyl, was thinking of the ai as reaching a decision point and then making a decision -- completing the loop and keep going. As conditions change you can make their behavior change because each decision point checks multiple things. There are certain aspects I still struggle with, but on the whole it's a bit amazing how much I've managed to accomplish with my limited abilities. I was making state machines before realizing what a state machine was.

Most important of all is iteration.. I patiently work with my enemy behavior just getting things working one bit at a time, one foot in front of the other. Patience rules the day.

In my next game I'd like to do legitimate pathfinding and other things I know are beyond my programming abilities, which is one of the several reasons I doubt I'll be doing another game alone.
 
Yeah, I don't use formal flow charts either. I just figure out stuff on the fly. I've never been very good at writing pseudocode or illustrating dummy art either. For me, at least, it feels like a waste of effort to work things out separately and then have to redo it all.

But I was also the kid who never showed her work on math in school. I would just write the answer down because I did the problem in my head, and the teachers often thought I was cheating.
 

Jobbs

Banned
Yeah, I don't use formal flow charts either. I just figure out stuff on the fly. I've never been very good at writing pseudocode or illustrating dummy art either. For me, at least, it feels like a waste of effort to work things out separately and then have to redo it all.

But I was also the kid who never showed her work on math in school. I would just write the answer down because I did the problem in my head, and the teachers often thought I was cheating.

I think we skip the flow chart for very different reasons, because I'm no math prodigy. I'm really a fucking idiot. I just bumble around and experiment. If I made a plan it'd likely change as I tinkered and iterated anyway. I work by many small iterations, starting only from a general concept in most cases.

(unless we're talking about simple purpose-built obstacles or enemies, e.g. this thing hops back and forth forever)
 

Paz

Member
I iterate on concepts out loud or on paper until I can conceptualize the way the game will play in my head, it's hard to explain but there's a moment where I just feel confident in the decisions. This means I don't use a lot of complex written documentation, though if I'm programming it I will often write a bunch of super haphazard pseudo code like "blah bit goes here" etc.

I do use flowcharts for figuring out menu flow and behavior though, because I can't account for all of the edge cases in my head and it's usually more for other peoples benefit.
 
I think we skip the flow chart for very different reasons, because I'm no math prodigy. I'm really a fucking idiot. I just bumble around and experiment. If I made a plan it'd likely change as I tinkered and iterated anyway. I work by many small iterations, starting only from a general concept in most cases.

(unless we're talking about simple purpose-built obstacles or enemies, e.g. this thing hops back and forth forever)

Ha, fair enough. Although I should say that most of the enemy behavior I've been working on recently is fairly simple, especially since there's no pathfinding involved.

I iterate on concepts out loud or on paper until I can conceptualize the way the game will play in my head, it's hard to explain but there's a moment where I just feel confident in the decisions. This means I don't use a lot of complex written documentation, though if I'm programming it I will often write a bunch of super haphazard pseudo code like "blah bit goes here" etc.

I do use flowcharts for figuring out menu flow and behavior though, because I can't account for all of the edge cases in my head and it's usually more for other peoples benefit.

Do you do all the enemy design in Cactus? I'm curious how your team shares that load.
 

Paz

Member
Do you do all the enemy design in Cactus? I'm curious how your team shares that load.

Tim and I share all the design work in Cactus, I tend to focus on things like enemy behavior concepts, level design, iterating on design & and tuning all things to make it all really cohesive.

At one point I did map out our enemy plans on a spreadsheet indicating things like their rough hitpoints, role, physical size etc. Just to make sure we weren't over covering areas or missing any key areas.
 

Jobbs

Banned
Ha, fair enough. Although I should say that most of the enemy behavior I've been working on recently is fairly simple, especially since there's no pathfinding involved.

A few of the enemies/bosses/npcs in Ghost Song have a range of decisions they can make as events change, it's a bit scary -- and in each case the more days away from last working on the thing the more impenetrable it becomes to me.

The majority of enemies are relatively simple, of course.
 
Tim and I share all the design work in Cactus, I tend to focus on things like enemy behavior concepts, level design, iterating on design & and tuning all things to make it all really cohesive.

At one point I did map out our enemy plans on a spreadsheet indicating things like their rough hitpoints, role, physical size etc. Just to make sure we weren't over covering areas or missing any key areas.

Oh, cool! Thanks for sharing.

Since most of the enemies in Nethermind have only one or two hitpoints, they're designed primarily around attack vectors. We also try to get as much visual difference as possible so it's not just "skeleton with a spear, skeleton with an ax, skeleton with a mace" et cetera. There have never been any charts, but we have combed over to make sure nothing is too similar, nor that any big hole is missing.


A few of the enemies/bosses/npcs in Ghost Song have a range of decisions they can make as events change, it's a bit scary -- and in each case the more days away from last working on the thing the more impenetrable it becomes to me.

The majority of enemies are relatively simple, of course.

I know that feeling. Not necessarily with AI, as it's all tied up super obvious nomenclature like "if (canSeePlayer(x, y, noClip)) state = CHASE;", but with other bits of code. The map generation in particular is a very tangled and confusing beast. There's almost no commenting on it and a lot of shorthand variable names to keep the behemoth condensed.
 

Jobbs

Banned
I kind of like skeleton with a spear, skeleton with an axe, and skeleton with a sword, though. :)

Incidentally, that's another thing I want to do next time. Enemies that are more interesting because elements of them (for example, their weapon) are dynamic.
 
I can't believe I missed this one:

So most of our walls and ceilings and floors (which I will refer to as "level geo") is actually constructed in the editor using ProBuilder. It allows you to drop in highly editable cubes and other primitives and start building maps. This tool also allows you to apply textures in a number of ways, so we have a few different tileables (made in Photoshop) that get applied to the level geo. Here is a demo where I drop in a cube (CTRL + K), go into edit mode (G), and move some vertices around. In the end I drag on a tileable texture I already had made (a tiling wood panel texture).

3kf9hRq.gif


Detail props like food, equipment, furniture, etc I still model in 3ds Max and then export to Unity.

Edit: Just saw your edit! The most important thing to get the pixelated textures on 3D is to use Point Filtering/Nearest Neighbor filtering on your textures. This renders them as 100% crisp and no interpolation is preformed to smooth them out. Use a texture resolution of like 128x128 with point filtering and you're on your way.

I did actually wonder if you were using ProBuilder, that asset is an absolute marvel. I assume you're also using it to build other specific static geometry bits such as the railings? It'd probably be fairly easy to use it to build the various simple models as well.
 
I kind of like skeleton with a spear, skeleton with an axe, and skeleton with a sword, though. :)

Incidentally, that's another thing I want to do next time. Enemies that are more interesting because elements of them (for example, their weapon) are dynamic.

I understand where you're coming from, and I appreciate that. I'm not sure if the example I used was the best to explain my point. I guess it depends on design imperative. Sometimes little things like that are changed to keep that one enemy type from being exactly the same encounter each time, and that's alright. And sometimes little things like that are changed because the dev(s) didn't have time to implement substantially different characters, so those tiny differences are treated like whole new enemy classes.

Maybe a better way to put it would be that I don't mind minor variation in enemy types as long as it doesn't detract from the implementation of major variation in enemy types.
 

Jobbs

Banned
I understand where you're coming from, and I appreciate that. I'm not sure if the example I used was the best to explain my point. I guess it depends on design imperative. Sometimes little things like that are changed to keep that one enemy type from being exactly the same encounter each time, and that's alright. And sometimes little things like that are changed because the dev(s) didn't have time to implement substantially different characters, so those tiny differences are treated like whole new enemy classes.

Maybe a better way to put it would be that I don't mind minor variation in enemy types as long as it doesn't detract from the implementation of major variation in enemy types.

A lot of what I do next time will be a direct response to my experiences this time.

One of those things is enemies and how I think about enemies. In Ghost Song, enemies are largely treated as little bumps, little obstacles, purpose built to their surroundings. Most enemies are not particularly smart, and an overall approach of placing emphasis on quantity has been taken. I felt as though I needed lots of enemies, new enemies in each area, otherwise I feared the player would get bored because there's not something different to shoot.

I'd like to take a different track. Each enemy should be able to exist and behave just about anywhere, and each enemy should be interesting and diverse in itself. Each enemy should be to some degree unpredictable and fun to encounter. The game should have a focus on quality, dynamism, depth and variety within each individual enemy rather than just trying to have a huge roster of shallow enemies. I want a smaller roster, but a far better one.
 
A lot of what I do next time will be a direct response to my experiences this time.

One of those things is enemies and how I think about enemies. In Ghost Song, enemies are largely treated as little bumps, little obstacles, purpose built to their surroundings. Most enemies are not particularly smart, and an overall approach of placing emphasis on quantity has been taken. I felt as though I needed lots of enemies, new enemies in each area, otherwise I feared the player would get bored because there's not something different to shoot.

I'd like to take a different track. Each enemy should be able to exist and behave just about anywhere, and each enemy should be interesting and diverse in itself. Each enemy should be to some degree unpredictable and fun to encounter. The game should have a focus on quality, dynamism, depth and variety within each individual enemy rather than just trying to have a huge roster of shallow enemies. I want a smaller roster, but a far better one.

Are you thinking all the way like Shadow of the Colossus? Or is there a less severe example you have in mind?

There are a surprising number of games where you can run by most of the enemies if you play well enough. Most of the time this is only countered by literally gating the player.

What you're describing sounds interesting for sure, but I don't think it's the one true design imperative. I enjoy a healthy spread of minor enemies in most games.
 

Jobbs

Banned
Are you thinking all the way like Shadow of the Colossus? Or is there a less severe example you have in mind?

There are a surprising number of games where you can run by most of the enemies if you play well enough. Most of the time this is only countered by literally gating the player.

What you're describing sounds interesting for sure, but I don't think it's the one true design imperative. I enjoy a healthy spread of minor enemies in most games.

No, nothing like SOTC. I want the enemy encounters to be heftier, for sure, but it wouldn't be a bosses only game at all.

I think I've talked a little about my idea before, but it's been brewing in my mind for the better part of a year now. Emphasis will be placed on a living world and dynamic elements -- Imagine certain aspects of Don't Starve or Animal Crossing merged with Dark Souls, with most likely a dark fantasy setting.
 
No, nothing like SOTC. I want the enemy encounters to be heftier, for sure, but it wouldn't be a bosses only game at all.

I think I've talked a little about my idea before, but it's been brewing in my mind for the better part of a year now. Emphasis will be placed on a living world and dynamic elements -- Imagine certain aspects of Don't Starve or Animal Crossing merged with Dark Souls, with most likely a dark fantasy setting.

Oh, okay. I guess I thought Dark Souls might be categorized as shallow since most of the enemies are humanoids that can be run right past.

The guys who do Extra Credits videos started a Let's Play of Dark Souls a few months ago (link). There's not been a lot of progress, but it's been pretty interesting all the same having a game designer and a professional animator tear it apart.

A couple of things they noticed in particular were interesting to me. For example, that Dark Souls enemies keep you on your feet by having a number of slightly different attack animations. A lesser (or at least simpler) design would only have one attack pattern per enemy, so circumventing it becomes rote rather than agile and reactive. That's something I want to influence future enemy design that I do.
 

Jobbs

Banned
Oh, okay. I guess I thought Dark Souls might be categorized as shallow since most of the enemies are humanoids that can be run right past.

The guys who do Extra Credits videos started a Let's Play of Dark Souls a few months ago (link). There's not been a lot of progress, but it's been pretty interesting all the same having a game designer and a professional animator tear it apart.

A couple of things they noticed in particular were interesting to me. For example, that Dark Souls enemies keep you on your feet by having a number of slightly different attack animations. A lesser (or at least simpler) design would only have one attack pattern per enemy, so circumventing it becomes rote rather than agile and reactive. That's something I want to influence future enemy design that I do.

Nice find, I'm checking it out.

What I'd add to your comment about running by enemies is that this is not terribly productive unless you already know where you're going and what you're doing. If you don't, it's chaos that often ends badly. There are also cases where you are gated in (namely, bosses) and in some cases, at least in the sequel, there are things you can only do if you clear the enemy(s). For example, switches come up that open a path or make something easier and those switches can't be accessed unless the enemy is out of the way.
 
Nice find, I'm checking it out.

What I'd add to your comment about running by enemies is that this is not terribly productive unless you already know where you're going and what you're doing. If you don't, it's chaos that often ends badly. There are also cases where you are gated in (namely, bosses) and in some cases, at least in the sequel, there are things you can only do if you clear the enemy(s). For example, switches come up that open a path or make something easier and those switches can't be accessed unless the enemy is out of the way.

Yeah, that's what I meant by some games literally gating the player. It's an interesting thing to balance. You don't want your game to be too easy, but that can actually be a very empowering moment if the only people who are running past mobs are seasoned pros.
 

Jobbs

Banned
Yeah, that's what I meant by some games literally gating the player. It's an interesting thing to balance. You don't want your game to be too easy, but that can actually be a very empowering moment if the only people who are running past mobs are seasoned pros.

Earlier I had designed a system to combat "running by everything" in Ghost Song. Basically, the idea was "spirit doors". You charge up spirit energy by killing enemies, and the energy opens doors that are placed in certain spots. The doors would come back when a save point is used, and your energy reset to 0 as well.

The idea behind it was you couldn't just avoid killing anything, you'd need to kill things as you go or in some cases encounter a situation where you need to go looking for a few enemies. It also presented the opportunity to design some organic puzzles -- Like, for example, this other door needs energy to open, but you can't get to it with enough energy intact unless you find a secret route that gets you around another door which was eating up the energy you'd need to open the desired door. That kind of thing.

This was eventually removed from the game because it just never really gelled for whatever reason -- So the only times you have to fight are when the game arbitrarily gates you in, which it does on occasion.
 
...

For example, for my game the most important hurdle to development, for me, was physics and collision. The first thing I did when I set out to make my game? Physics and collision. You need to make sure you or someone can handle the meat and potatoes of the game before actually making the game. Cutscenes, menus, all that stuff is nonessential until the end or until it has to be shown. Hell, we have our story and cutscenes planned out since last year and only last week we drew sprites for one of our cutscenes to showcase it because it was necessary. I can't stress enough how important it is to make sure you can actually make the game you want before sinking time into the nonessentials of development.

Just my .02

This x 100.

Except for menus though! Maybe it's just Unity or my specific needs, but it has been a pain the past few days working on one.



@AI
Don't forget to make the AI fun, not just hard. Give them personalities and preferences even if it causes them to choose less efficient attacks.

Switch up their tactics based on the situation too. If they get low on health, maybe make them use more frenetic attacks. If a player has a long range weapon, have the AI keep close and focus on melee.
 

bsp

Member
I can't believe I missed this one:



I did actually wonder if you were using ProBuilder, that asset is an absolute marvel. I assume you're also using it to build other specific static geometry bits such as the railings? It'd probably be fairly easy to use it to build the various simple models as well.

Yea you certainly can. Right now the bamboo railing is indeed PB along with some other more specific structural meshes in other levels and lots of trim.
 

Kalentan

Member
I do the flow charts in my head and as I work, possibly because I never really knew the right way of doing anything. What made sense to me, as a person with no programming experience and just working within the range of things I knew how to do in stencyl, was thinking of the ai as reaching a decision point and then making a decision -- completing the loop and keep going. As conditions change you can make their behavior change because each decision point checks multiple things. There are certain aspects I still struggle with, but on the whole it's a bit amazing how much I've managed to accomplish with my limited abilities. I was making state machines before realizing what a state machine was.

Most important of all is iteration.. I patiently work with my enemy behavior just getting things working one bit at a time, one foot in front of the other. Patience rules the day.

In my next game I'd like to do legitimate pathfinding and other things I know are beyond my programming abilities, which is one of the several reasons I doubt I'll be doing another game alone.

I think for me.. A flow chart maybe helpful as it gives me a visual to follow. I'm a very visual learning person so I think it will be good. Looking back at the chart now, I assume I should have different AI code for each type of enemy. So rather than having one code for both melee and ranged, I should have one for ranged and melee and so on and so forth.

The only thing I wonder is if I can use the path finding on my hero character on the AI.

I think also my biggest issue is how exactly do I tell what object is an enemy or not. By that I mean, how does the Enemy overview AI that works like this...

E76b.png


Choose the enemy. Do I have a variable in each of the enemy objects?
 

Jarekx

Member
Yea, I just got to working on some enemy AI for my current project as well. What i was thinking of doing was having basic behaviors that all enemies of a certain type follow. Then a set of expanded behaviors that can be applied across all enemies.

My game has a JRPG type combat system though, and enemies can be different levels and feature different sets of skills at those levels of which only 4 can be used in any given battle. So I figured it might be easier to actually tie behaviors to skills since a lot of skills are used by multiple mobs. Maybe i'll tie in the other idea by making it a system for choosing what type of skills they are loaded out with.
 

GulAtiCa

Member
Does anyone here know of anyone or best place to look for paid artist for graphics? Looking to get some graphics done for my Space Shooter Asteroids-like game. It would be a small project, as wouldn't need that many graphics, esp since the main objects will be zoomed out, so will be "small".

Anyways, anyone know of good places to look?
 

Kalentan

Member
I know I need to work on the AI...

But I just got done and figured out:

1. How to make the player selected, name, face, health, mana, and level appear in the corner.
2. How to make a menu appear when selecting a character.

I also got the character to not able to be selected after attacking and moving, no matter the order.

Basically what I did is I gave each character a specific variable number. So if the selector is on Marlow, heroSelect = 1, if selector is on Masara, heroSelect = 2.

I plan on doing the same thing for enemies for when attacking. The only problem with this is that I'm unsure how it will react when there is 2 heroes and what about skills that hit more than one target?
I guess I could always change it so instead of one variable every character has: (marlowSelected = true, masaraSelected = true) and the same for enemies. However this does screw with my current script which uses heroSelect > 0 to go on... But I think I need to start realizing that sometimes trying to have 1 variable instead of multiple actually makes it more annoying...
 

Blizzard

Banned
I think also my biggest issue is how exactly do I tell what object is an enemy or not. By that I mean, how does the Enemy overview AI that works like this...

Choose the enemy. Do I have a variable in each of the enemy objects?
In object-oriented programming, I think the normal practice would be to have say, an "Actor" class that's a general type. Then "PlayerCharacter" and "Enemy" would be subclasses, and they would have their own variables and methods.

If "Enemy" objects have a variable called "enemyType", then you can just check that while looping through stuff. Or "Actors" could have a variable called "actorType", and you could check whether actorType == ACTOR_ENEMY_SWORDPERSON.
 

Kalentan

Member
In object-oriented programming, I think the normal practice would be to have say, an "Actor" class that's a general type. Then "PlayerCharacter" and "Enemy" would be subclasses, and they would have their own variables and methods.

If "Enemy" objects have a variable called "enemyType", then you can just check that while looping through stuff. Or "Actors" could have a variable called "actorType", and you could check whether actorType == ACTOR_ENEMY_SWORDPERSON.

I'm not sure I understand..?

So say I have 2 enemies (objects.)

Bandit 1 and Bandit 2.

Bandit_1
Creation
Code:
var enemy = true;
var enemyType = ENEMY_SWORDSMAN_LV1

And repeat for Bandit_2.

So... would the code check if "enemy" = true and use the "enemyType" to figure out it's AI code pattern?

But how does that go and check Bandit 1 and 2? Do I need a new AI for each level to specifically check those enemies?
 
I'm not sure I understand..?

So say I have 2 enemies (objects.)

Bandit 1 and Bandit 2.

Bandit_1
Creation
Code:
var enemy = true;
var enemyType = ENEMY_SWORDSMAN_LV1

And repeat for Bandit_2.

So... would the code check if "enemy" = true and use the "enemyType" to figure out it's AI code pattern?

But how does that go and check Bandit 1 and 2? Do I need a new AI for each level to specifically check those enemies?


Just make a parent object called objEnemy or something and make your bandits be children of that parent. You can read a lot more about object parentage in the manual.
 

Kalentan

Member
Just make a parent object called objEnemy or something and make your bandits be children of that parent. You can read a lot more about object parentage in the manual.

Okay. Though I suppose that does mean I will need a new AI for each level, correct? I doubt I want one objEnemy that is the parent of every enemy in the game.
 
Okay. Though I suppose that does mean I will need a new AI for each level, correct? I doubt I want one objEnemy that is the parent of every enemy in the game.

You can go a hundred layers deep with this if you want.

Code:
objEnemy
 - objBandit
   - objBandit1
   - objBandit2
 - objSlime
 - objSkeleton
   - objSkeleton1
     - objSkeleton1king
   - objSkeleton2

But you'll probably only want it to be one or two tiers. Any further distinction is probably better solved by storing disparate attributes in variables.
 

Blizzard

Banned
Okay. Though I suppose that does mean I will need a new AI for each level, correct? I doubt I want one objEnemy that is the parent of every enemy in the game.
Please forgive me if you're already familiar with this -- but if not, I recommend doing a bit of reading about object-oriented programming. I'm not sure of a good reference to recommend, but I feel becoming familiar with the concept of "classes" "objects", and "member variables" would make your task a lot easier.

I'm not familiar with how Game Maker would handle it, if that's what you're using, but hopefully it supports some sort of object classes (think of classes as types of objects).
 
Status
Not open for further replies.
Top Bottom