Game Idea: for C2 or Unity?

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! :)

Unity: will require your users to install the unity plugin to play it in a browser.

Construct2, will enable to you to export it to the various platforms, web being the easiest one to attain for any user.

If you want on the fly switching of perspective, use the same layout, else each switch will cause a short lagg while the layout gets loaded, making the switching less fluid as the levels get bigger.

Using them in the same layout, would be the fastest method to switch views manually.

I would just use some method to disable updates on the hidden layer,until you switch to it.

I keep hearing bad comments on unitys lacks of updating manuals/guides and what not, but thats related to fast development or so I hear.

Im not aware which export options unity offers, but I know construct 2s is vast.

I think it is doable in C2 (even though you will not be able to see a transition between views), you'll have to think you game in 3D, but to apply it in 2D, the inused dimension can be simulated using a scaling on the sprites, I suggest you don't use directly the X and Y position of the elements, but you use variables like Real_X; Real_Y; Real_Z, then having a rendering method on screen.

Exemple:

Group 3D logic

Ship_1, every tick, set Real_X to Real_X + 1*60*dt //this is a movement; *60*dt is for frame rate independancy, if you prefer the game to slow down like classic space games, you can remove it

Group 2D application, viewport 1:

Ship_1, every tick, set X to Real_X, set Y to Real_Y, set scale to ((Real_Z+something)*something)

Group 2D application, viewport 2:

Ship_1, every tick, set X to Real_X, set Z to Real_Z, set scale to ((Real_Y+something)*something)

Not sure I am perfectly clear

EDIT: so between C2 or unity, depends, if you are used to C2, I think it will be a good option, for unity though, depends on what you really want (I don't know any unity export, except the browser one, which uses a plugin)

Unity allows export to Android, IOS, Browser(with plugin like stated), Windows 8, Windows phone 8, Blackberry, Mac, Linux, Windows, PS3, Xbox, Wii-U.

Just wanted to clear that up.

Like we talked about, I truly think this is going to be a much easier project if it's built in 3d (unity) and then you have 2 different cameras that you can switch between. Switching cameras can then switche the control scheme that allows you different moving (going from right and left of a side scroller, to 8-way of a top down for example).

Of I am not saying this isn't possible in C2, I'm sure it is. I just think the easier approach is to go full 3d.

There would be some hurdles in Unity... especially if you're not a coder.. I think you'll run into issues with applying the movement methods with perspectives in unity... Among other things... But it would probably be easier in unity as it is already 3D capable...

You mentioned having variables to store position information....

I am not quite sure I understand what you're trying to do but I have thought about how to do a Fez-like game in C2 and I feel it is most easily done by using an array to store all positional information... Basically, having the whole game be handled in an array and the visual elements merely being interpretations of the happenings within the array.. Usually, when this is done, you end up with choppy/tile-based movement, but you can overcome this by using a gigantic array and oversizing your action sprite as well as implementing some clever algorithms to handle things like acceleration...

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

I would want some transition so it was clear to the player what view they were switching to. Even though it's the same two.

I would probably make an animation of the ship doing the rotation, from top to side.

Then when the player hit the switch button, make a show of everything pausing, and fading to black, except the ship. When it's alone on the screen, play the animation of the rotation. then fade back in and unpause the new orientation. (hopefully all happening in a half second.)

It would be a combination, the fade and pseudo 3d.

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.

Rhindon, the algorithms are the easy part of that kind of project :-P

The difficult thing, for me, would be wrapping your head around what is actually going on in the array to ensure that your graphical translation is accurate.

Most all maths are open-source :-D

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

There are certain advantages for running a project like this in a 2D environment, with arrays governing the action and the engine simulating 3D and I believe that this is how Fez works.. 2.5D, 2D simulating 3D..

You can fairly easily simulate a 3D environment with 2D objects being represented based on their position in an array. Crudely, off the top of my head, you can have each object represented by a number in the 3D array... say, 1=player, 2=floor... have a series of 2s filling up the x and z of one layer of y.. have a global variable just to store which perspective you're in... if perspective=1, then move all floor-objects to Z,Y. if perspective=2, then move all floor-objects to X,Y... you could have the floor objects move at a speed to show a transition...

And for the algorithm handling player acceleration, you could have a global variable that counts up to 3.. for every .2 second that [movement key] is pressed, add 1 to moveVar. for every .1 second that no movement keys are pressed, subtract 1 from moveVar... For the next part, I'm having a little trouble thinking of how to do this... but you'll want to shift the "1"'s position in the array an amount of spaces in the array = to moveVar... if you have the objects oversized, and the array very big, the plots in the array can be a few pixels big each, so moving 1-3 spots every .05 seconds could be pretty smooth movement....

Anyway, not sure how much of this is coherent or helpful.. But your project is ambitious and I'd love to see it come to fruition.

Maybe it's because I'm having some trouble visualizing how this work in Construct 2, but this idea reminds me of a game called

.

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

come to think of it, that approach actually lead me to make virtual attempt.

I started with the thing that is now the mini map in the top left.

It was suposed to be a hidden bottom layer to determine x,y coordinate.

But it became multifuntional as I also applied it to be the minimap.

Your game could basically be similar to ikaruga, gameplay-wise : having two "worlds" between which the player can switch on the fly. 3d space wouldn't required in that regard and you'd keep a somewhat similar gameplay value.

From what I can tell, your idea seems pretty abstract to me at the moment. In order to find the right tool for the job, you should do a small prototype to see if it works and how well it works on a given engine.

Basically, if you need a camera rotation beyond the scope of screen space, you'll need a 3d engine. 2d engines aren't meant to represent 3 space anyway. Also, I'd say that the target platforms and scope of your game will determine which engine you should favor to a large extent.

Good luck,

Nathan

You can do a smooth transition from side to top in c2 with a formula to rotate a point in 2d.

http://www.siggraph.org/education/materials/HyperGraph/modeling/mod_tran/2drota.htm

Here's it in action using pre-rendered sprites for the ships.

https://dl.dropboxusercontent.com/u/5426011/examples21/shooter_rot.capxr155