Sign in to follow this  

Enemy Loading/Saving in a Top Down Shooter

This topic is 3095 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In my 2D top down shooter I'm using XML to save/load level information such as map tiles. I'm going to use that to store information on the levels' enemies too but I have some questions about the exact way to do things: Naturally, I plan to have a couple of different kinds of enemy. They'll be different in health, damage etc. I've thought of making different AI attack patterns for each one too. This would mean for example; all grey planes travel in a straight line but all black planes attack diagonally. In that situation I'd just have to store enemy positions the same way I'm storing tile positions; a single number representing the enemy type in whatever position it's in. However, what if I make planes that move across the screen diagonally to the left but then I also want to make them move right sometimes? That completely messes it up. Unless I completely randomize the AI of each plane (which would probably lead to some insanity and generally sloppy looking gameplay) that just can't be done in a system where an enemy is represented by a single digit unless I make an exact duplicate of that enemy type but with the one difference being the direction of attack. That would work but it would be tiresome and not very flexible. Maybe then I want every plane to be able to attack in any of the set AI patterns? I'd need an EnemyTypes*AIPatterns number of different enemies. So what I'm asking is: What is a good way of storing enemy information for a specific level using XML for a top down shooter? Different types for every slight variation on an enemy type is surely a bad idea, right? So, how might you logically store more than a simple number while not ending up with a garbled mess? I would suppose that a pretty good way to store an enemy's information would be like this:
<enemy type="1" xpos="22" ypos="10" attackpattern="2"/>
That would allow changing of the AI, health, etc. of any specific enemy regardless of type but how then should it be organized inside the XML file? Should they just be one after the other, in order of appearance in the level with the first at the top? That'd wind up very long but I suppose that doesn't matter. Would that make sense or is there an obvious better way? Also, in a top down shooter, should the "waves" of enemies that come together in formation be in any way linked by the game code or level files or should they just be enemies that happen to appear side by side and use the same attack pattern?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sean_Seanston
However, what if I make planes that move across the screen diagonally to the left but then I also want to make them move right sometimes? [...] that just can't be done in a system where an enemy is represented by a single digit.


Sure it can.

enum AttackPattern {
ATK_NONE = 0,
ATK_STRAIGHT = 1,
ATK_LEFT_DIAGONAL = 2,
ATK_RIGHT = 4,
ATK_SOME_NAMED_COMBO = ATK_RIGHT | ATK_STRAIGHT
};


<enemy type="1" xpos="22" ypos="10" attackpattern="6"/>

Defines an enemy with ATK_LEFT_DIAGONAL and ATK_RIGHT. This gives you n possible attack patterns in an n bit unsigned type, where any of them can be combined. You can also name combinations as above.

If you want to store more, like how often they switch attack patterns, then you'll need more than 1 value.

Share this post


Link to post
Share on other sites
Ya but I mean describing the entire enemy with just a single number.

You'd need at least 1 number for the enemy type (grey plane maybe) and 1 for the attack pattern.

Like currently I have the tile map saved like this:
        <row id="0">9,9,13,9,15,9,19,20,9,9,9,9,9,9,9,9,9,9,9,9</row>
<row id="1">4,4,4,4,4,4,4,4,9,4,4,4,4,4,4,4,4,4,4,4</row>


I was going to do the enemies in a similar way where 0 is no enemy and 1/2/3 are different types of enemy but then this problem cropped up.

Does anyone actually have any information on how something like this was actually handled in old 2D games like SWIV or Aero Fighters etc.? That would be interesting too...

Share this post


Link to post
Share on other sites
Think of the density of your enemy data in relation to the density of your map data. Compared to the size of the map, I imagine on average that there are only going to be a handful of enemies. Therefore, you should store an entry for each enemy on the map, but not store anything for enemies that aren't on the map. If you store enemies the same way you store tiles, you not only limit yourself to one enemy per tile but you also store null data by enumerating a bunch of tiles where there aren't enemies (i.e. by using an ID of 0). If there is no enemy on a particular tile, then simply exclude that information instead of storing fluff. Otherwise, you're inclined towards a much less expressive and flexible way of storing the enemy data. You've already observed what problems can arise when you collapse it all down to a single value. Just store exactly what information you need for every enemy individually. Don't bother trying to come up with a list of all possible permutations of enemy state and assigning each one an ID, there's no need.

Share this post


Link to post
Share on other sites
I would say the better way to do this is, have a basic data store for all your enemy units that has nothing to do with the map at all... it defines the basics for the enemy unit, and then in the map ref these units and whatever modifiers they may have. Allows for the most flexibility.

Share this post


Link to post
Share on other sites
Quote:
Original post by ZipsterJust store exactly what information you need for every enemy individually. Don't bother trying to come up with a list of all possible permutations of enemy state and assigning each one an ID, there's no need.


Alright cool... I'll just use a sequential list of enemies.

Quote:
Original post by wacko420
I would say the better way to do this is, have a basic data store for all your enemy units that has nothing to do with the map at all... it defines the basics for the enemy unit, and then in the map ref these units and whatever modifiers they may have. Allows for the most flexibility.


Ya, what I plan to do is have an XML file that describes the characteristics of each enemy type, like health and damage and whatnot. Then I'll load from the map XML file into a vector of enemies.

Share this post


Link to post
Share on other sites
You could have elements like this at the top of each level:
<enemy_type_definition type_id="1">
<ship_type>gray</ship_type>
<attackpattern>2</attackpattern>
<otherinfo>foo</otherinfo>
</enemy_type_definition>
Then whenever you used the number 1 in your row arrangment like so:
<row>0,0,0,1,0,0,1,0,0,0</row>
it creates a gray ship with attack pattern 2, whatever that might be. That particular row created two of these ships.

You could use this in combination with Zipster's (superior) idea, where you write lines that have a position and a ship type, instructing the game to place a ship of the requested type at that position.

You could also expand this system to have all the ships' properties specified at run-time, loaded from these enemy type definitions.

Share this post


Link to post
Share on other sites
An interesting idea too... though it still has the 1 enemy per tile limitation. Still not totally sure how I'll do it... making it so you can select attack patterns for enemies in the editor is giving me a lot to think about, especially with multiple enemies on 1 tile which isn't going to be visible unless some kind of numeric display of the enemies on the tile is implemented. I'll find a way soon enough though...

Share this post


Link to post
Share on other sites

This topic is 3095 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this