Shooter type game. « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Shooter type game.

(12 posts) (5 voices)

Started 1 year ago by serveace6
Latest reply from sunflower

Tags:

game design

serveace6
Member

Hi all,

I'm designing a shooter type game and was wondering if anyone can provide some suggestions regarding the implementation of the elements. Currently I have a bunch of enemies, weapons, and items (i.e powerups) but need to incorporate different levels and possibly bosses. What is the best way to construct these elements of the game? I'm looking for a flexible way for me to create new enemies to go with certain levels and not end with crazy code.

One direction I was looking at was to create Level classes that would hold all the information like the different type of enemies, powerups, background and possibly bosses and to be used in my main GameScene. I new to game development and would love get some suggestions for designing/implementing this type of game. I guess I'm looking for a pattern that is commonly used or just key pieces that I would need to accomplish this.

Thanks

Posted 1 year ago #
zenkimoto
Member

@serveace6

Hmm, I've never done what you're proposing, but if I were to do it, this is probably what I would do:

1. Create a layer for each level. Has it's own background, tiles, etc. Loads up baddies and final bosses.
2. Of course, baddies, powerups, etc would be in their own classes.
3. During a level transition, just change the layer to the "next level"

Separating out the levels in different layers allow you to add new levels in the future. Something to think about. :)

Maybe someone can chime in if they have a better idea if they'd done something like this before. I'd love to hear it.

Hope this helps.

Posted 1 year ago #
serveace6
Member

@zenkimoto: Thanks! That's what I'm kinda looking for from suggestions. I've never considered a layer as a level so that may make things better as I can take advantage of the cocosnodes. I'm gonna wait to see if anyone else can chime in with some experience on this as well.

Posted 1 year ago #
reedjsmith
Member

I went down the road of different layers for each level but you end up with a bunch of duplicate code. What I did is determined all enemies & actions and defined them as their own entity. So if I wanted enemy-1 to do action-4 I could just send the enemy into a function to do it and the function would apply the action to the enemy, etc...

I kept a database of levels with enemies/time/actions that determined which enemy and when the enemy was to be shown on the stage and what his actions were. I allowed multiple actions to be applied to each enemy either simultaneously or in a timed sequence.

This worked well for me. Let me know if you want that code, I have no problem sharing it:)

Posted 1 year ago #
zenkimoto
Member

@reedjsmith

I'm curious, what type of duplicate code would you be talking about? After thinking about it, I see how it could have duplicate code between the layers. Could a generalized level class be created for the "duplicate code"?

Great idea about the database of levels enemies, time, actions. I had never thought about that. Does the database include artwork such as backgrounds, etc when the levels change?

Posted 1 year ago #
greyhoundgames
Member

Take a look at my game Sub Hunt. Its a lot like what your describing. I can provide you info on what I did if you want. I went a semi complicated route. I ended up with having super flexible code though. I was able to add a bunch of stuff near the end that was completely different mechanics then what was in game with minimal changes to the engine needed.

Posted 1 year ago #
zenkimoto
Member

@greyhoundgames

I am curious how you do that in Sub Hunt. Did you go through inheriting a layer or a database of enemies?

Great game by the way :-).

Posted 1 year ago #
reedjsmith
Member

Yes I have a separate table to define enemies(sprites) and their graphics/actions. Actually it is more abstract than that. It just takes sprites and associates their actions and settings and assigns an id. Can be called once or as many times in forward or reverse or at a different interval. I have another table to associate relationships between sprites. This changes from game to game.

I extended the layer class with a custom class to reload from db with new data. I could have used separate layers I guess but this is what worked for me and the only thing I am really losing is transitions. I still maintain layers for all menus, etc.

The cool thing is this framework makes developing and tweaking new app ideas with tons of actions very quick. I have a class that creates actions on the fly based on database items. So if I have 5 actions related to a sprite in the db, 2 actions at the same time and 4 actions in a sequential order after that it takes care of it. So I can add this sprite to the screen when the main sprite gets to a participator position and make it do these actions.

Another benefit is the ability to allow the user to develop custom levels and offer download-able levels.

The hardest part of developing a game is the idea/game play not the coding. This helps me flush it out quickly.

Posted 1 year ago #
greyhoundgames
Member

Here is a very high level overview. If you do not have an OO programing background this may be overly complex for your needs.

First thing I did was separate the model(level,enemies,player,bullets) from the gui(in my case custom engine, in your case cocos2d).

Then you would create a single layer that exits for the purpose of catching touch events and rendering dudes.

Your top level layer could have a level model object.
Inside the level model object you could have say a list of unit objects.

The way mine works is i have a tick function that gets called continuosly on the layer. The layer then calls tick on the level. The level then calls tick on each guy in it. Each guy then moves himself as appropriate.
After thats all done the top level view needs to go through all its gui elements for the units\bullets etc and update their position with the new values that resulted from the tick function.

At a high level thats the jist of it. For each different level you should be able to just swap out the level model object with a new one and use the same view.

Posted 1 year ago #
serveace6
Member

@reedjsmith: Your method definitely has its flexibility in the long term with the ability to expand the game thru in app download. However, it may be a bit overkill for my needs right now but I might take you up on the share offer at some point :)

@greyhoundgames: Sub Hunt looks great and I think it more along the lines of what I'm trying to implement. I think what I have currently is only missing the "Level" class that encapsulates the game objects. So what I'm thinking is this,

GameScene
* HUD
* Player
* Level
** Enemies
** Background
** Projectiles
** Items (powerups)

So how does the Player interact with the Level? So if the player's only purpose is to shoot the projectile, should I pass it in to the Level? Or have the player spawn the projectiles via a method in Level?

Again, thanks to everyone for enlightening me on this subject.

Posted 1 year ago #
greyhoundgames
Member

In mine, the Level had a direct pointer to the player object, even though he was also in the array of units. When a touch event came in say on the DPAD i would just do something along the lines of player.directionMoving=NORTH_EAST or whatever. When they fired i did player.beginFiring or whatever. Then in the player object's tick function, it would check if any direction is set and and if firing is on and move\fire. Firing would create a projectile object which also got a tick and would look for collisions with other units as it moved.

Posted 1 year ago #
sunflower
Member

look at this post. It has prety basic shooting game tutorial.

http://www.raywenderlich.com/352/how-to-make-a-simple-iphone-game-with-cocos2d-tutorial

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.