ChrisAlgoo - Thank you, sir. :) It's still a toss-up between whether I want to have this game take place in literal 3D space or not. The actual gameplay will be the flat 2D...soooo, still undecided.

digera - Honestly, I have trouble following C2 explanations in strictly text. But I do see the benefit of using arrays. I'm going to look into that.

And thank you for the encouragement! I'm still working on my first game for now, so it'll be a while before I truly try to tackle this space shooter game I have in mind. I will SURELY make sure everyone is updated when I get back to this project I'm asking about.

Zero6 - GAAAH!!! That's...that's...That's almost EXACTLY what I have in mind. There is a minor difference: for MY game, I picture the top down view being like Galaga, where the player is at the bottom of the screen and the enemies engage from the top. So while what you shared here is...pretty much...what I'm working towards, there is a subtle difference.

.....and there's still one thing I have up my sleeve that even Revolver360 doesn't have: and that's my secret weapon.

Valerien - Right. The 3D space will be a mock-up, of course, if I do it in C2. I'll have instance variables and/or arrays to keep track of mutual values between the two planes of perspective.

R0J0hound - HOLY CRAP!!! That was awesome!!!

It has been nearly 15 years since I was in calculus/trigonometry, but surely this will help me refresh my mind. Thank you so much!

Gameplay wise, the 2D/3D change is going to be by user input or automatic?

Personally I'm thinking about switching from something R-Type like to Space Harrier. No idea why, but it seems cool enough =P

The switch between perspectives would be primarily user-input. Though, there's no telling that I wouldn't include moments where it's automatic. But I have no current mind to do that. For now, it's strictly upon user command.

Paradox - Exactly. Whichever editor I do this in - and it'll likely be in C2 for now since I'm most familiar with it as opposed to Unity which I've ONLY JUST started tutorials on - I'll definitely have a transition sequence of some kind. Unless my skills become more refined, it'll probably be as simple a layer fade in/out.

EVERYONE has made some excellent points and considerations. Thank you!

lennaert - VERY good point about layouts for each view. I hadn't thought about the loading details. I think layers would be best, indeed.

Aphrodite - Yes, you're very right - I'll have to sacrifice a lot of transitional effects between views. However, if I'm going to use layers, I could manage something simple, like opacity fading in and out. It wouldn't be fancy, but just enough so to signify and switch.

I also did think that I'd be using variables for the "master position cooridnates". I had thought about the conflict between the X and Y values of the literal objects and figured using substitute variables to save the real coordinates would help me keep track of the mutual values.

Can't say your examples made total sense - but that's more ME just reading things raw like that. I'm sure you knew what you were talking about.

ArcadEd - Thank you, my friend. If I go with Unity, the MAJOR advantage will be having only one space ship to worry about and two cameras to easily switch between. My main concern is the learning curve. But then, the scope of this game won't be an overnighter; neither will the learning be. I'm going to FIRST start with a simplified version of my idea using a single perspective and use layers for elevation purposes, but no switching of perspectives (side versus top-down). Keep things simple to start with...

digera - THAT is a marvelous idea! I'm not sure I had thought of Arrays, but it would truly be easier to keep track of the mutual values shared between two ship instances for each view. Now, the algorithms...that scares me. LOL

My "pet project" will be a double-take on the classic space shooter genres. Specifically the 2D top-down (ie: Galaga) and 2D side scrollers (ie: R-Type, Gradius).......at the same time.

Before I get to my main question as posed in the subject, let me try to paint a picture of what kind of game I want to build...

In a 3D space, you have three axes - X (left and right movement), Y (forward and back motion), and Z (up and down movement).

Side scrollers deal with the YZ perspective and top-down handle the XY. It's presumed in 3D space that the 3rd dimension in a 2D view is fixed...it doesn't change. But what if DID change even while still in 2D perspectives?

Before I go further, I recognize the similarity between what I'm proposing and a certain game called "Fez". Both ideas will incorporate 2D gameplay in an "interactive" 3D world. My idea is still quite a bit different, not to mention it's a different genre, and I had this idea over a year ago before I even had an inkling about "Fez"...

Say you're playing a classic Mario game, originally a side-scroller. Mario comes to a wall and, despite his powerful legs, he cannot jump over it. But what if you could see from a different perspective? From above or behind him? Suddenly that impassible wall is nothing more than a simple pillar that Mario can walk to the side of.

In my space shooter game, that's the idea behind the gameplay. Having the ability to switch between perspectives on-the-fly. A wave of enemy fire that can't be squeezed through becomes a small huddled group of dots you can fly around and easily dodge. I have more ideas to incorporate, but time and testing will prove if these are viable in the actual gameplay.

Now, I have two thoughts on how to make this happen.

1. A single layout with two layers.

Depending on the active layer that represents one of the two perspectives, one layer will be invisible while the other is active. Each of the active layers will have a second "blocked off" in order to create the illusion of a viewing window that has been resized to accommodate the traditionally-narrow playing field of a shooter (not always the case, I know, and I may change that).

2. Two layouts, one for each perspective.

Pretty much the same think as two layouts, but it might make it easier to switch between perspectives so that objects on different layers don't clash.

I would use two ship objects - one for each perspective. They would "share" an instance variable that kept track of the mutual XYZ coordinates; each ship "instance" would update regardless of which view was active.

There are, undoubtedly, other considerations to account for...but I haven't tackled them yet.

What I'm curious about are any pros/cons that come to mind and possible work-around options for doing this in C2, which is where I'd like to KEEP the game for now.

However, I've had previous talks with fellow C2izens (C2 citizens) who feel using Unity might be a better option. Definitely can't disagree given that my game will take place in 3D from two fixed 2D views, and Unity is a 3D engine.

What I'm after is some insightful thoughts about the benefits of either game editor and why one or the other would be the proper route.

I appreciate your input! :)

Noncentz705 - I imagine you could, but just as it would be silly to have a single object spawn multiple other objects on top of the previous one just to create the illusion of animation, why do the same with tiles? That could result in a LOT of additional resources being used up (not to mention keeping track of them) if it's not necessary.

Burvey - LOL Thanks. Guess I SHOULD have done a search first.

Yessah! I can't imagine whether or not this would truly be possible in the editor - you have the insight on that.

But I would love to see the option to create titles that are animated along with the static images.

For instance. Say you have a tilemap made up of walls and doors. Suppose one door tile actually was animated to swing open...combined with the custom collision polygon for each tile, it would be "easy" to create interactive tiles! Trees and grass that sway in the wind, torches that flicker in low light (just as lighting effects...but not water!), water with gentle waves...the list goes on.

What's the possibility that this could be a reality? :)

Thank you for any consideration...I know your to-do list is HUGE.

szymek - LOL Indeed!!! It's taking me a little bit to get used to using/editing them, but they're even easier to use that my original level-making plan before.

I'm LOVIN' Tilemaps! Just had to give a shoutout.

This non-artist/level-maker person is definitely feeling more at home with Tilemaps and how they streamline making my game's levels. Thank you, Scirra Bros!

Link to .capx file (required!):

sugarsync.com/pf/D6025908_4317202_6011572

Steps to reproduce:

Unsure of exact steps...

1. Create and edit a tilemap as desired.

2. Place tilemap on layout.

3. Later, select tilemap object on layout or in object bar.

Observed result:

The tilemap bar doesn't load any of the tiles even as the image editor for the tilemap object shows there is artwork there.

Expected result:

Selecting the object or layout instance will load the available tiles for that object.

Additional information:

I edited the Tile width and height parameters and clicked on the object in the object bar again. That seemed to fix part of it. But I don't see how that prevents the tiles from loading at all. The size of the tiles in the image editor is 24x24, whereas the default size of the tilemap object is 32x32. But that doesn't explain why other tilemap objects don't load even after having their parameters resized.

Browsers affected:

Chrome: N/A

Firefox: N/A

Internet Explorer: N/A

Operating system & service pack:

Windows 7 w/ Service Pack 1

Construct 2 version:

C2 r154 64-bit