Elysian Shadows

EdBoon wrote:oh awesome i will have to grab it on playtest!! i saw you had to pull for bug, (me too, waiting until sat to resubmit. The week long waiting period is brutal! mine was 1 line of code ) ill throw u 2 peer reviews once you get it up, and i have a couple friends with them too i will have them review it. should give u about 2 to 4 reviews first day.

if you wouldn't mind throwing me a peer review as well on saturday , or whenever you get a chance following it, i would appreciate it!

good luck, going to go try it now

Will do, sir. And thank you, I really appreciate your help!

I go back up for Peer Review tomorrow (Wednesday).

To my XNA peeps - Rad Raygun is back up for Peer Review!

Can this be the release that goes live? Dear lord, I hope so!

awesome, Will do it tonight for sure.

I forgot to ask, does this mean you will continue the development of Golvellius 3D?

How do the plans for Microsoft's discontinued support of XNA play into your future development plans as someone who has released many titles under XNA and for the XBOX 360?

As a person who would like to release games for XBLIG, I'm curious to see what direction others are taking.

How do you handle modifying parallax layers in your editor?

TNTniceman wrote:I forgot to ask, does this mean you will continue the development of Golvellius 3D?

I have every intent to revisit the Golvellius 3D project one of these days, but probably not until my kids are a bit older. Until then, I'll probably do some Android development, since I'm too cheap to buy a mac. :P

mattheweston wrote:How do the plans for Microsoft's discontinued support of XNA play into your future development plans as someone who has released many titles under XNA and for the XBOX 360?

As a person who would like to release games for XBLIG, I'm curious to see what direction others are taking.

Yeah, that sucks...I really do like the XNA framework. I'd love to move onto iOS development, but I don't own a Mac. I'll probably do a small Android project next.

Falco Girgis wrote:How do you handle modifying parallax layers in your editor?

Did you see my reply on page 1 of this thread? If that doesn't answer your question, let me know! I'd love to discuss the editor, because it really played a huge part in letting my artist and I work in parallel. Using only the editor, we could build a completely different platformer and have it be about 90% complete! The problem is that is a shit load of art assets and RR alone took 2 years! :P

trufun202 wrote:

Falco Girgis wrote:How do you handle modifying parallax layers in your editor?

Did you see my reply on page 1 of this thread? If that doesn't answer your question, let me know!

Oh shit, I completely missed that somehow!

So tell me if I'm understanding your layering correctly. From back to front:
1) background image
2) background tiles ontop of the background image for animating certain regions of the background
3) main layer the player interacts with
4) foreground layer for things like trees that are rendered in front of the player and the main layer

Then there are two levels of speeds for parallaxing:
slower: layers 1 and 2
faster: layers 3 and 4

Assuming that I am anywhere near correct here, I have some back-end and front-end questions.

Back-End
Is your layer "size" smaller for the background, since it scrolls slower and can technically fill the same area as the two foreground layers with a much smaller region? If your layers are static structures, are you actually allocating a smaller area region by using the map size from the upper layers and the speed of the parallaxing?

Front-End
So does your level editor's map placement window actually render the background layer as it would be in-game? If the user were to scroll over the main view, would they see the in-game parallax effect? Can we see screenshots?

That's very clever for background animations, btw. Sounds like an efficient and elegant solution.

I'm asking all of these parallax questions, because I have been considering allowing the level designer to "toggle" the upper layers in our maps as parallax layers in ES. I have a very good idea for how I would implement the back-end in our engine, but not so much for how I would handle this in our Toolkit.

trufun202 wrote:Using only the editor, we could build a completely different platformer and have it be about 90% complete! The problem is that is a shit load of art assets and RR alone took 2 years! :P

I can only imagine. I feel like we are probably in the same boat here.

Falco Girgis wrote:Oh shit, I completely missed that somehow!

So tell me if I'm understanding your layering correctly. From back to front:
1) background image
2) background tiles ontop of the background image for animating certain regions of the background
3) main layer the player interacts with
4) foreground layer for things like trees that are rendered in front of the player and the main layer

Then there are two levels of speeds for parallaxing:
slower: layers 1 and 2
faster: layers 3 and 4

There are a total of seven layers (going back to front) and 3 speeds of scrolling:

1) parallax image - slower scroll - single image for the background
2) parallax tile layer - slower scroll - tiles laid on top of the parallax image
3) background layer - normal scroll - tiles that appear behind Rad, but scroll with the collision layer
4) collision layer - normal scroll - yeah, that stuff you walk on
5) entity layer - normal scroll - stores interactive items, such as enemies, power ups, ladders, etc.
6) front layer - normal scroll - tiles that appear in front of Rad, but scroll with the collision layer
7) foreground layer - faster scroll - for things like columns and trees in the foreground

Falco Girgis wrote: Assuming that I am anywhere near correct here, I have some back-end and front-end questions.

Back-End
Is your layer "size" smaller for the background, since it scrolls slower and can technically fill the same area as the two foreground layers with a much smaller region? If your layers are static structures, are you actually allocating a smaller area region by using the map size from the upper layers and the speed of the parallaxing?

Each layer is only alllocating what it needs. In the editor, a new map has each layer as a 1x1 array. The layers are then redimensioned as tiles are dropped in. But, for example, say you have a huge map with only 1 entity, the collision layer may be 1000x1000 where the entity layer only has to be 20x20 -- does that make sense?

Falco Girgis wrote: Front-End
So does your level editor's map placement window actually render the background layer as it would be in-game? If the user were to scroll over the main view, would they see the in-game parallax effect? Can we see screenshots?

Yes, if you scroll over in the editor, it matches the same in-game parallax effect. We didn't do this at first, but it caused mass confusion. Basically I can go in and out of "Preview Mode", and the map looks the same. The output of the editor is just 7 text files, exporting the 2D array of tile names. (pretty rude and crude, I know, but its all a compiled resource in the 360 build.)

EDIT:

Here's a look at the parallax layers in the editor:
http://i50.tinypic.com/sw4u4l.png

...and in-game:
http://i48.tinypic.com/244a2pi.png

You'll also notice that the in-game screenshot has a more pixelated look. This is just a transparent layer that I render over the entire game to give it the retro look.

Falco Girgis wrote: That's very clever for background animations, btw. Sounds like an efficient and elegant solution.

Thanks, I was proud! :D This allowed us to have gunman firing in the background of the first level, and it really added some depth and feeling of being a "live" environment.

Falco Girgis wrote: I'm asking all of these parallax questions, because I have been considering allowing the level designer to "toggle" the upper layers in our maps as parallax layers in ES. I have a very good idea for how I would implement the back-end in our engine, but not so much for how I would handle this in our Toolkit.

That'd be sweet! Having the ability to specify a layer as being parallax and then setting the scroll speed in the editor should give you all of the flexibility that you need. I got away with 3 speeds essentially - slow backgrounds, normal collision, and faster foreground - but, I could totally see needing varying levels of parallax for different maps.

trufun202 wrote:

Falco Girgis wrote:Oh shit, I completely missed that somehow!

So tell me if I'm understanding your layering correctly. From back to front:
1) background image
2) background tiles ontop of the background image for animating certain regions of the background
3) main layer the player interacts with
4) foreground layer for things like trees that are rendered in front of the player and the main layer

Then there are two levels of speeds for parallaxing:
slower: layers 1 and 2
faster: layers 3 and 4

There are a total of seven layers (going back to front) and 3 speeds of scrolling:

1) parallax image - slower scroll - single image for the background
2) parallax tile layer - slower scroll - tiles laid on top of the parallax image
3) background layer - normal scroll - tiles that appear behind Rad, but scroll with the collision layer
4) collision layer - normal scroll - yeah, that stuff you walk on
5) entity layer - normal scroll - stores interactive items, such as enemies, power ups, ladders, etc.
6) front layer - normal scroll - tiles that appear in front of Rad, but scroll with the collision layer
7) foreground layer - faster scroll - for things like columns and trees in the foreground

Aaaaah, I didn't realize you had a separate "collision" layer. I figured the collision was an attribute of each tile. So with a separate layer like that, the same tile can be solid in one place and walkable in another place, right?

trufun wrote:Each layer is only alllocating what it needs. In the editor, a new map has each layer as a 1x1 array. The layers are then redimensioned as tiles are dropped in. But, for example, say you have a huge map with only 1 entity, the collision layer may be 1000x1000 where the entity layer only has to be 20x20 -- does that make sense?

Oh, damn! That's even more sophisticated than what I was asking... very nice.

trufun wrote:Yes, if you scroll over in the editor, it matches the same in-game parallax effect. We didn't do this at first, but it caused mass confusion. Basically I can go in and out of "Preview Mode", and the map looks the same. The output of the editor is just 7 text files, exporting the 2D array of tile names. (pretty rude and crude, I know, but its all a compiled resource in the 360 build.)

EDIT:

Here's a look at the parallax layers in the editor:
http://i50.tinypic.com/sw4u4l.png

...and in-game:
http://i48.tinypic.com/244a2pi.png

Damn, that's sexy as hell. I really like the idea of having the editor render the layers just like the engine. It's good to see you proved it can be pulled off... Now I'm more motivated to give it a try. We already stole your layer selection widget, after all.

So, I'm just killing time while I wait for my last XNA Peer Review approval... Here are some interesting (or at least I think they're interesting) stats on Rad Raygun:

- 830 days in development
- 85,481 lines of code (engine + game + editor)
- 6,572 art assets (if you count each tile)
- 9 original songs

It's kinda cool to look back on a project that I thought I would NEVER end!

trufun202 wrote:So, I'm just killing time while I wait for my last XNA Peer Review approval... Here are some interesting (or at least I think they're interesting) stats on Rad Raygun:

- 830 days in development
- 85,481 lines of code (engine + game + editor)
- 6,572 art assets (if you count each tile)
- 9 original songs

It's kinda cool to look back on a project that I thought I would NEVER end!

85,481 lines of freakin' code
This game looks so freakin' professional and awesome.
I bought myself 800 Microsoft points just for this game!

Any chance of a Rad Raygun X

85K freakin insane, kudos