next »

[JOBA]

As you all know, castlevanias feature some of the coolest bosses out there.
Most of them are completely unique and i've been wondering for a long time - how devs at konami do it.

Which programming language do they use? C?

Are the bosses hardcoded?
Or is there some heavily-data-driven stuff?
Or are they scriped?
How they code behavior of bosses? Sequences of actions? Etc?

Moreover latest castlevanias feature around 100 different enemies. How do they handle so much data? Are enemies hardcoded? How do they manage the code without ending up with huge spaghetti code? What tools do they use?

And there's only a few indies who actually make games like that. Konjak has some cool bosses in noitu love 2 and legend of princess. Cave story had some cool bosses too.

How are they made?
How would you make them?
What tools do you use?

[ஒழுக்கின்மை (Paul Eres)]

these questions make no sense to me. how experienced of a programmer are you? handling things like 100 different types of enemies is easy to do with, for example, arrays.

[John Nesky]

The boss animations probably are not hardcoded. The boss behaviors, on the other hand, might be.

Often, the tools used to make animations like these are "in-house". For example, I have developed my own 2D animation tool before. It involves some trigonometry and/or matrices.

[JOBA]

these questions make no sense to me. how experienced of a programmer are you? handling things like 100 different types of enemies is easy to do with, for example, arrays.

Do you mean an array for enemy types or an array for enemy instances?
Like std::vector<boost::shared_ptr<BaseClass>> enemyArray;?

Handling 100 different types of enemies is not easy at all.
Unless they all share a lot of common traits, but in castlevania most of them are unique in a way and i cant think of a single simple data structure to hold them.

Have you played a recent castlevania game on GBA/DS?

I'm quite comfortable with C, C++ and lately i've been using C# for making game tools.

[ஒழுக்கின்மை (Paul Eres)]

yeah, good point @johnnesky -- a lot of games use a scripting language like lua to define enemy behaviors and animations external to the game code. some use things like xml too. but if you're only a single programmer there's no particular reason not to code it in the code yourself (other than it being easy to edit without recompiling, i guess), scripting mainly comes into play when you have multiple people working on a game.

@joba: what i mean is something like this. the way i do it is i have one basic object for an enemy, then have an array store its different behavioral scripts in an array. so for instance if an enemy is 'slime' its type would be 1, or a constant called SLIME equal to 1. and an array called, for instance, movement_behavior[type] which is an array of script handles. that way during its movement part, you just call that particular movement script. of course, i don't have 100 enemies, just about 50, but the principle is the same regardless of number. you also might have draw_script[type] and periodic_action[type] and reaction_to_being_hurt[type] so on.

[JOBA]

The boss animations probably are not hardcoded. The boss behaviors, on the other hand, might be.

Often, the tools used to make animations like these are "in-house". For example, I have developed my own 2D animation tool before. It involves some trigonometry and/or matrices.

Has ever any of these tools leaked? Or at least some screenshots of them?

If you dont mind, could you post a few screenshots of your animation tool?

I love seeing screenshots of custom-made game tools.

[JOBA]

yeah, good point @johnnesky -- a lot of games use a scripting language like lua to define enemy behaviors and animations external to the game code. some use things like xml too. but if you're only a single programmer there's no particular reason not to code it in the code yourself (other than it being easy to edit without recompiling, i guess), scripting mainly comes into play when you have multiple people working on a game.

@joba: what i mean is something like this. the way i do it is i have one basic object for an enemy, then have an array store its different behavioral scripts in an array. so for instance if an enemy is 'slime' its type would be 1, or a constant called SLIME equal to 1. and an array called, for instance, movement_behavior[type] which is an array of script handles. that way during its movement part, you just call that particular movement script. of course, i don't have 100 enemies, just about 50, but the principle is the same regardless of number. you also might have draw_script[type] and periodic_action[type] and reaction_to_being_hurt[type] so on.

That clearly is one way to do it.
What language do you use for main code? And what language do you use for scripting?
Have you finished the game? (i would love to check it out)
What kind of a game is it?

[John Nesky]

I haven't been maintaining my animation tool, but I could probably dig it out if you want. I used it to make the top two animations here. It was a cross platform tool using SDL and OpenGL.

[ஒழுக்கின்மை (Paul Eres)]

game maker; the game with 50 enemies is saturated dreamers: http://studioeres.com/saturated -- that's not out yet (it's in closed playtesting currently). i also made immortal defense, which used an identical structure for coding its enemy behaviors, and has 26 or 27 (i forget which) enemies. that game is out: http://studioeres.com/immortal

[nikki]

maybe a little help from inheritance ? 

[JOBA]

game maker; the game with 50 enemies is saturated dreamers: http://studioeres.com/saturated -- that's not out yet (it's in closed playtesting currently). i also made immortal defense, which used an identical structure for coding its enemy behaviors, and has 26 or 27 (i forget which) enemies. that game is out: http://studioeres.com/immortal

That really is an unique tower defense game. And I spent a bit to much time on it.

maybe a little help from inheritance ?  

Doesnt that kinda imply hardcoding the enemies?

At the moment i think i'm going to make a 2D skeletal animation tool for making "chasis" of the enemy and defining some basic animations and actions.

The actual enemy behavior is going to be scripted, each having a separate script file.

You should really check out some of the castlevania bosses on youtube(there's plenty of them and they are a great inspiration). It's still a mistery how they do it.

[ஒழுக்கின்மை (Paul Eres)]

thanks, much appreciated

inheritance is like hardcoding, but it also means that you reuse code between enemies, and you don't really wind up with spaghetti code since it's all in a neat structure.

i haven't really played any of the modern castlevania games; the most recent one i played was sotn i believe. but the bosses in sotn didn't seem that hard to code; the hardest part would probably be their AI.

[nikki]

maybe a little help from inheritance ? 

and a sniff of Polymorphism 


If you would think of an abstract type or class named ENEMY
you'd see you could come up with very basic or abstract methods. move() for example.
by overriding such a  method move() you could simply give differnt enemies different ways of moving, like flying, like a slime, running towards you, seek player position etc etc etc.
member_variables could be used to keep track of speed, force, healt, attackstrength and much more.

I wouldn't let the way you want to graphically build up your enemies decide too much about the actual class. Either way if you choose to build up your enemies from sub-images or just from pre-drawn images. An enemy will have 1 or more image-frames. to be put in 1 place or more then 1 at the same time. I spotted an enemy on the youtube with an enemy with 2 very big hands, such an enemy obviously will need more then 1 image on screen ...

The actual enemy behavior is going to be scripted, each having a separate script file.

I think i get you, but i fear a little your going to be writing 100's of roughly the same scripts. try to write as high-level methods first, you'll see you can re-use everything.
and then you could just tell your desired new custom enemy to use a few of those methods, tell it its member-variables and feed it an array or 2 with images, and give it a scary latin-sounding name
 

[s0]

i haven't really played any of the modern castlevania games; the most recent one i played was sotn i believe. but the bosses in sotn didn't seem that hard to code; the hardest part would probably be their AI.

Castlevania bosses don't have much of an AI to begin with. They have a set of pre-defined actions that get triggered in a certain order or randomly, or at least that's the impression I got from playing the games.

Also, on a side note, all modern Castlevanias (excluding the 3D ones) are very similar to SOTN. 

[Skofo]

Gah.

Moreover latest castlevanias feature around 100 different enemies. How do they handle so much data?

It looks to me like you need general programming experience more than a specific answer to this question.

[JOBA]

i haven't really played any of the modern castlevania games; the most recent one i played was sotn i believe. but the bosses in sotn didn't seem that hard to code; the hardest part would probably be their AI.

Castlevania bosses don't have much of an AI to begin with. They have a set of pre-defined actions that get triggered in a certain order or randomly, or at least that's the impression I got from playing the games.

Also, on a side note, all modern Castlevanias (excluding the 3D ones) are very similar to SOTN.  

That's right. There isn't something i could call an "AI". And the new 2D castlevanias aren't really all the different from SOTN. However I would argue that they contain even more ridiculously huge amounts of content (e.g. the soul system in AoS and DoS). The huge amount of content is what really amazes me and sets it apart from other games(even though the content gets reused a lot). And if there's a game i definitely must see the source code of - it has to be one of the metroidvanias.

Gah.

Moreover latest castlevanias feature around 100 different enemies. How do they handle so much data?

It looks to me like you need general programming experience more than a specific answer to this question.

Please state exactly what additional knowledge i might need.
Or at least suggest some programming paradigms which might come in handy.
Or supply ANY kind of VALUABLE information.
Otherwise I'm afraid your post is of no value.
If i had the experience for making 100 wholly different enemies i wouldn't be there, would I?

maybe a little help from inheritance ?  

and a sniff of Polymorphism  


If you would think of an abstract type or class named ENEMY
you'd see you could come up with very basic or abstract methods. move() for example.
by overriding such a  method move() you could simply give differnt enemies different ways of moving, like flying, like a slime, running towards you, seek player position etc etc etc.
member_variables could be used to keep track of speed, force, healt, attackstrength and much more.

I think this method would be more suited for games having not more than ~50 enemies.
I'd like to keep enemies as "data"(2d joint model+scripts) and not really a hard-code anywere near the main-code or engine. I could be wrong though.

Has any of you stumbled across an open-source game featuring vast amounts of content and enemies? (A game on http://happypenguin.org/ or something?)

I wouldn't let the way you want to graphically build up your enemies decide too much about the actual class. Either way if you choose to build up your enemies from sub-images or just from pre-drawn images. An enemy will have 1 or more image-frames. to be put in 1 place or more then 1 at the same time. I spotted an enemy on the youtube with an enemy with 2 very big hands, such an enemy obviously will need more then 1 image on screen ...

2D bone model with several defined actions and animations would cover a wide range of enemies, including some of the coolest bosses like these two:


(Castlevania: OoE, Eligor)


(Castlevania: SotN, Galamoth)

+ ability to script special custom "parts of bodies" (like a lightning rod in second video)
+ ability to script custom behaviors (chasing a player with a huge hand or a sword)
+ a list of scripted special attacks (like lightning, fireballs, lasers, etc) which could be emitted from any of the parts or by the player or be called from any script
+ a particle emitters attachable to any of the parts (like a bleeding monster)
+ detachable parts (like a hand you could chop off)
+ ability to mark which parts do damage and which parts can take damage
+ bone/tile interaction scripting
etc

It's a huge amount of work, but i think it's a reasonable model and leaves plenty of room for customization via scripting.

The actual enemy behavior is going to be scripted, each having a separate script file.

I think i get you, but i fear a little your going to be writing 100's of roughly the same scripts. try to write as high-level methods first, you'll see you can re-use everything.
and then you could just tell your desired new custom enemy to use a few of those methods, tell it its member-variables and feed it an array or 2 with images, and give it a scary latin-sounding name
 

The scripts basically will contain information about which actions/sequences of actions to trigger under which conditions, including information about chasing, etc.

Probably some of the scripts will be similar, but there has to be a way to break them apart and define some reusable basic chasing/movement behaviors.

Yeah, I'm trying to strike a fine balance between customization, code reuse and ease of making and debugging new enemies. And i really don't want to impose any kind of restrictions on what could be made within the object model.

The biggest challenge seems enemies which consist of several seemingly separate parts working together, like this boss:
http://www.youtube.com/watch?v=pyz39w_FqyI (Castlevania: PoR, Loretta & Stella)

But it still seems doable within my object model: by using an invisible joint between 2D skeleton model consisting of two animated parts. Scripting a boss like that would clearly be a challenging task nevertheless.

Thanks for ideas!
Try however to be more specific, giving a more precise code snippets in a language of your choice/pseudocode/etc. As in "how would you do it"? Much appreciated!

[Average Software]

Has any of you stumbled across an open-source game featuring vast amounts of content and enemies? (A game on http://happypenguin.org/ or something?)

Nethack.

[BorisTheBrave]

After seeing these videos of castlevania, I am not enthralled (I don't have much experience of that series). As joba says, it's painfully obvious how these bosses are built up out of simple elements. The only part I'd have difficulty with is the skeleton animation system, but you could use a 3d one without much fuss. All those bosses either don't react at all to the player, or they distinctly "switch modes" to some obvious seeking strategy with limited animation. Statemachines or markov chains (or both) would cover the rest of the AI. I could go on with other gimmicks. I'd bet the enemies are actually harder to write - they have to chase the player down, navigate the levels, and interact with each other. I wouldn't like to attempt bosses like that in a language without OO though, which probably explains the reverence from GM junkies.

So I guess the skill is in making a playably fun boss, when the medium is quite harder to work with than simple animations or behaviours. Coming up with interesting one off mechanics, designing bosses with subtle weaknesses etc.

[amro]

I handle it using Lua. Each enemy defines a new metatable which "inherits" Entity (a C++ class with basic functionality) or another enemy defined in Lua. The enemies are all instances of Entity, but with customized message handlers and event handlers (I use a variation of the Actor model).

[nikki]

Thanks for ideas!
Try however to be more specific, giving a more precise code snippets in a language of your choice/pseudocode/etc. As in "how would you do it"? Much appreciated!

From your first part i thought you are asking about the complexity in code because of the amount of 'different' enemies.
At the same time your talking alot about these graphical niceties, that are more extra fluff..
i believe its important to separate the content (animations,images,scripts,sounds) from the actual framework (the classes that you'll write) ,then you'll see the actual amount of end-bosses doesn't make that big a difference at all. (Apart from the tedious work of defining, drawing and animating a hundred endbosses)

In most basic programming books there is usually this chapter on CLASSES or OOP and it'l usually explain classes (inheritance, polimorphism, composition) with examples of vehicles or animals just read end-boss and your good to go!

But seriously, in what programming language you want to write this?, i might be able to write a little example.