next »

[Paul Jeffries]

Looks really impressive so far.  I'd like to put a vote in for you re-implementing the terrain deformation; that looked like it could be a really cool feature.

[AMT]

Both a big and small update today! First, a screen:


(Right click > View to see large version)

Skeletons can now be added as a component to any entity. Now we have flies! But this is the small update. This is the big update:



Yes, that's an Xbox 360 and yes, I got it for $14.99 . The thrift store couldn't test it because it was missing the power brick. I took it to a friend's house and it works! The only thing that's wrong with it is the disc drive, which is fine because I intend to use it for XNA dev (and maybe the occasional XBLA game). So, now that I have an Xbox, Isolation is going to be both on Windows and XBLIG! I'm excited about this

[AMT]

More music I got Komplete Elements for Christmas. This is my first attempt at using it. Probably not going to be in Iso, but I figured I'd share. Thanks for reading the thread, feedback is always appreciated!

[floatstarpx]

hey, wow - nice to see someone doing an interesting, ambitious project. it looks like in several areas you've gone down a similar path to what we have with your world design, tools and animation system (although we don't use a "skeleton" as such, we use 2D key-framed 'parts' for our characters)..

definitely very interested to see this progress!

your skeleton's pose in the last screenshot reminds me of the guards from "Another World" (or 'out of this world' depending on what region you're in!)

[TheSpaceMan]

Do you have any good links etc about portalsystems that you would like to share.

I do understand the concept, but it would be nice to have some data structure examples.

[AMT]

I couldn't really find too much info on them, but I'll take some time to describe my approach to everything. My classes are WorldStreamer, Cell, and WorldElement. A Cell consists of a collection of WorldElements, a world coordinate, and misc info like the background, music, and lighting to use. The world coordinate is a pair of integers that represent what slot the cell should be in on the world grid. Cells cannot overlap, instead it's like a giant tilemap. WorldElement is a parent class for everything that can be placed as part of the environment, like polygons and doodads. Their coordinates are stored relative to the Cell that owns them, so a WorldElement at 0, 0 would appear at the upper left corner of its respective Cell. WorldElements that generate collisions are marked with a special flag in the editor so that they can be easily differentiated. That pretty much covers the way the world data is stored.

The last bit, getting it loaded during gameplay, is what the WorldStreamer is for. The WorldStreamer is a singleton that maintains a 2D array of the loaded Cells. WorldStreamer has a queue of needed resources and a method called Run that runs in its own thread. This method loads each thing in the queue one by one until all needed resources are in memory. The engine uses a GetCell(x, y) method to interact with the WorldStreamer. The WorldStreamer will give the cell at the wanted position if it is loaded in memory, and if it isn't it adds it to the load queue. As far as what it returns if the Cell isn't in memory, I recently switched a bit of how I handled this, so I'll mention both approaches here. My first approach was to return a temporary Cell that was a giant solid square. That way the player couldn't actually get into a Cell before it's been loaded. I thought about this and didn't want this to impact the ability of players to try speed runs on my game, so I decided that I would load all collision data when the game is initialized and only stream in the visual geometry. By keeping the environment collision masks low-poly and using the drawn polygons to do all of the detail I can fit that in memory without any issues.

The last bits of the puzzle are unloading resources and tracking Entities. I make the Cell the Player is in the "focus cell" and the 8 surrounding Cells are also updated / loaded. When a Cell is no longer one of these 9 Cells, it's unloaded from memory. Entities work in the same way. Any Entity in one of the 9 active Cells has its Update and Draw called regularly. The only exception is as follows: If an Entity is marked as "essential," and it's in a Cell that should be unloaded, that Cell is not unloaded. "essential" entities are updated regardless of if they are in the active Cells or not.

That pretty much sums up everything. The focus follows the player as he moves from Cell to Cell, and the amount of time it takes for him to traverse one Cell is usually more than enough to load the resources for the next. If it isn't, the player sees some pop in, but gameplay is still identical because collisions have been loaded beforehand. If you have any more questions / want to see actual code, feel free to ask! Hope that helps

[wogan]

this looks GREAT. when will we get to play it? it looks like a biiiig project, so I'd imagine it won't be for a while?

[TheSpaceMan]

[... Good description of the system...]

Thank you.

That makes sense, also that you keep important objects active and they keep the cells active. Maybe you could optimize it one step further and just keep the collision data and interactable object for the area, sounds like you are keeping the graphics as well?

It would be interesting trying to implement a Zelda game using this logic as well. But maybe need a bit more logic to try to keep enemies in their native areas...

That made me think of something else.
How will you handle monsters. Will a monster be owned by the cell they are currently in, or where they where created. Both of these can be come a problem. 1: A zone deviod of life due to all enemies migrating to another cell. 2: Enemies being despawned because the owner cell is out of range...

[AMT]

[... Good description of the system...]

Thank you.

That makes sense, also that you keep important objects active and they keep the cells active. Maybe you could optimize it one step further and just keep the collision data and interactable object for the area, sounds like you are keeping the graphics as well?

It would be interesting trying to implement a Zelda game using this logic as well. But maybe need a bit more logic to try to keep enemies in their native areas...

That made me think of something else.
How will you handle monsters. Will a monster be owned by the cell they are currently in, or where they where created. Both of these can be come a problem. 1: A zone deviod of life due to all enemies migrating to another cell. 2: Enemies being despawned because the owner cell is out of range...

All textures and graphics are streamed / unloaded, the only thing that is always kept in memory is the shape of each polygon for the collision data. If you do make it to an area before it gets loaded, you won't fall through the world, but you won't see anything there. It's not the best solution, but I don't want to punish players for being fast.

As for monsters, larger / more notable things like bosses will be marked essential and won't respawn once they've been killed. All monsters start in the Cell they were spawned in, but can move to other active Cells at will. If the Cell they're in is deactivated, they're despawned, but when you re-activate the Cell they originated in they'll respawn. You could technically abuse this to duplicate enemies, but since it will only work on small ones it shouldn't be an issue. It'd just be like running into another one in the wild. Since their AI will primarily respond to the player, making them not leave their original Cell without being lured or forced to by the player shouldn't be an issue.

To be honest, some of this is still theory and has yet to be implemented, but I'm fairly certain it won't be a big issue. If I make any changes to this I'll give a followup post explaining what actually worked. I hope this helps!

this looks GREAT. when will we get to play it? it looks like a biiiig project, so I'd imagine it won't be for a while?

Thanks! I'm actually hoping to get a player movement test out relatively soon so that people can try their best to break it / get out of the environment / etc. It won't be huge, but should give a good idea of how the game will control and play. Keep your eyes out for it, I'll be making a post about it here when it's ready

[AMT]

Not quite "music," but I put together some creepy ambiance to use in the game. I think this should help set the mood nicely. Thoughts?

[thedaemon]

I'd have to hear it first.

[Sean A.]

Started working on music a little bit. Excuse the production, I'm away from home and mixing on earbuds, but here's a little concept that's inspired by Metroid Prime's soundtrack

I <3 the Metroid Prime soundtrack, and this one sounds pretty good. Will the game have an upgrade/unlock system similar the Metroid?

[AMT]

I <3 the Metroid Prime soundtrack, and this one sounds pretty good. Will the game have an upgrade/unlock system similar the Metroid?

Yeah, the game is going to have a progression similar to Super Metroid. The upgrades and areas will be completely different, but it's definitely going to be the same kind of flow. Super Metroid is my favorite game of all time and I've beaten it hundreds of times

[Sean A.]

Mine is Metroid Prime, I never grew up with an SNES so I've only played it on Virtual Console and emulators. I think it's soundtracks one of my favorites too and if you can get the feel like those games then you're all set.

[AMT]

http://www.youtube.com/watch?v=v30n1t9hBUE

A little video showing that enemies work and I can shoot at them. Next up, making them hurt the player. Thanks for watching!