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

newt - Ah! Well, that much makes sense. :)

newt - Hmmm...that makes sense, but I'm having trouble conceiving it in my head as to how I'd do it in C2.

Anyway, someone suggested I use the tilemap as an alternative. I'm going to give that a shot.

Ashley - Mighty good question, sir. Heck if I have a good answer. I've been struggling to filter things down, but I suspect that my lack of understanding of all the finer points of how each action and event works (behind the scenes) is making it hard for me see what will or won't work.

It's rather like when I learned just how For/For Each work. I THOUGHT they worked one iteration each tick. Turns out, as I learned later, they work until done, even if that means several iterations per tick. At least, that has been my understanding of late.

blackhornet - I think I'm following the logic in your capx...

1. Bee object instance is clicked

2. For EACH Bee in the Family, set the NextUID family instance variable to -1

3. Call the Connect function with a parameter that plugs in the UID of the Bee that was clicked.

4. On call of the Connect function...

5. Pick the object that has a UID that equals 0 and set the NextUID value to UID of the object instance that was picked.

6. Pick all instances of the Family whose NextUID value is equal to -1.

7. From those selections, pick a random instance of the Family and set the UID of the Family to the Next instance variable of the Bee that was picked.

8. Draw the line between the two objects.

9. Call on the Function again and run it for all other instances of the Family whose UIDs are 0.

How'd I do? I'm still not sure I fully understand the whole thing.