you need a mac.

is multiple gamepad support a thing?

Should I code you the game?

No offense, but what have you tried?

Have you opened the ghost ahooter tutorial?

Have you read all the manual?

It's best practice to share what you have tried and write out what you are stuck on. So many times, just writing a well thought out question can actually lead you to answer it for yourself.

An array is a great way to hold the data and information to keep track of where objects are.

I would would use a number to represent each tile.

Let's say I have tile 1, 2, and 3

The array holds the game field and values are 1-3

Think of an array like a grid. Or game of battleship.

for this problem I would use nested for loops to navigate the array.

For(int I is less than array sizeY)

For(Int Y is less than array sizeX)

check if there is a match across ArrayX

If not, check for a match on arrayY

If you want to get into performance optimizations. Do a full check every once in a while. Otherwise only check where there are changes in the array. No need to check the whole thing all the time. Once should be good.

Is it possible to have the shadows behind objects instead of on top of them?

My game looks odd when shadows cover my sprites instead of starting behind them.

Its like if on a sunny day my face has some shadow extending on and past/over me instead of starting on the ground so to speak and going behind me.

Would I be needing multiple servers running? As in multiple browser tabs, or would it be possible to do this within a single server you think?

I'm just trying to think of ways that could make the game load in persistent chunks without needing the entire world going at once.

My theory being that having smaller Shards to deal with would have better performance. Why load an entire world, when players only play in a small "chunk" at a time.

I run into a wall though, because if a single machine ends up hosting multiple servers constantly. That would almost defeat the purpose of the shards, unless it could be dynamically done.

still interested of peoples thoughts on the subject.

Game scenario:

8 players are roaming a game world.

1 of the players enters a dungeon.

Desired effect:

This dungeon should now have a separate server.

When players enter the dungeon they are placed on the new server.

When players leave the dungeon they are returned to the main server.

Reasoning:

This shard behavior. Reduces stress and latency across the main game world.

This allows more dynamic servers, and could allow for larger player interactions.

For starters. a single sprite, multiple frames. Width, height, scale are all values that can be modified on the fly to get variation between the same piece. not to mention flipping/reflecting a sprite.

The sprite, should create and destroy itself. (if using multiple sprites instead of frames, they should create and destroy each other)

at higher speeds, if the sprite is not in control of its own creation and destruction, (for instance you have a separate object that spawns the pieces) the game will break apart. Pieces won't align.

I would share a demo, but being an idiot I formated my drives before I published.....lost a good deal. sadly my dropbox has an old broken implementation.

But hey, next time around I have plenty of room for improvement. good learning process haha.

[quote:1az9rqt2]As for memory management. Not all objects need loaded at the same time. store object data in arrays and create those objects as needed and destroy them as needed. Think of this like minecraft "chunks" You only need to load so many "chunks" at a time.

Texture wise, they are still in memory, so it can be a pain.

[quote:1az9rqt2]An amazing feature construct should do instead of tiled backgrounds or sprites etc. Is procedurally/dynamically/viewpoint loaded objects. When the viewport is near where objects should be, load them and create them. Otherwise, they dont need to be loaded or known about until later.

This looks like more something the user should have to do himself, that could break so many projects otherwise

I imagine that last part for object creation to be a behavior. This way objects that need to always exist can. But others could add the behavior which would help with performance a good deal in projects I would think.

As for the memory. Dont the same sprites share the same texture? Or does every object have its own texture. I am not very familiar with how that works.

Regardless though, GPU and CPU would not have to work as hard if this was implemented. Consequently increasing performance. As well as freeing up ram etc because object information isnt needed or being used.

https://dl.dropboxusercontent.com/u/583 ... index.html

Desired effect?

arrows move, mousewheel zooms.

and there is some touch support. touch feet to drop. two touches jump.

144fps pc

60fps mobile(note this is a device limitation not performance hit)

4 sprites

31 objects

with room for improvement.

and many many ways it could be optimized further.

Pros:

Scales without seams.

Very few sprites.

Meets in-between of tiling background performance and tiling sprites performance. (but at max fps on all my machines I cant honestly verify this simply theory crafting)

Cons:

Large background image. (this could easily be broken up into smaller images)

Multistage level design(you tile everything and build your level and then have to again set solids etc etc)

Performance(both a con and pro depending how you look at it)

And a picture

https://dl.dropboxusercontent.com/u/583 ... apture.JPG

As for memory management. Not all objects need loaded at the same time. store object data in arrays and create those objects as needed and destroy them as needed. Think of this like minecraft "chunks" You only need to load so many "chunks" at a time.

That means a 3000 object project might only have loaded 300 objects at any given time. Just food for thought.

An amazing feature construct should do instead of tiled backgrounds or sprites etc. Is procedurally/dynamically/viewpoint loaded objects. When the viewport is near where objects should be, load them and create them. Otherwise, they dont need to be loaded or known about until later.

Tylermon not at the moment I'm afraid. You're welcome to make any of these additions yourself if you like and I'll merge into the main release.

Also worth keeping in mind I wasn't able to get this playing nice with Clay.io and CocoonJS. Essentially CocoonJS allows you to have a single webview for making async javascript calls. I can't see a way for clay and flurry to share one. If anyone has any ideas, let me know.

Ah, that is good to know. My java script wizardry skills are lacking, but if what you say is true with cocoonjs conflicts etc then I'm probably not going to worry over it.