Rhindon's Forum Posts

  • KFII - Good points, sir!

    1. I'll definitely aim for that kind of "theatrical" presentation...something that beckons the player to take a closer look. And the SNES Mario Kart is a perfect illustration! The interactivity idea will be very simple for the purposes of my game.

    2. It's not a DEEP game, at least not on the surface. And I don't plan to give too much away right at the TITLE screen. That would just be silly. LOL But you're right - I'll definitely test it on players.

  • cgirolet - Welcome to the C2 family, Claude!

    As I'm growing in learning to use C2, as well, I find it's becoming easier to organize things by having separate event sheets for different things, just as GeometriX stated. Per my knowledge, having additional event sheets won't take up more resources, per se. Maybe the TINIEST bit if any. Feel free to add as many sheets as you need.

  • Beaverlicious - OH! Okay, gotcha. They don't seem to have it now, but YouTube has/had a feature that, while the video is loading with that rotating circle graphic, if you clicked IN the video window and touched one of the arrow keys, you could play a game of "Snake"...where you chase down the dot to grow longer.

    ArcadEd - Gotcha. If you ever do add a title screen interaction, I look forward to what you come up with. :) You'd certainly come up with some CREATIVE stuff, I've no doubt!

  • ArcadEd - Maaaan, that sounds so familiar about the basketball game...was it on the NES or later consoles?

    And I LOVED the Mario 64 deal! LOL SO creative! So pointless, but it was FUN!

    Do you plan on adding anything along these lines to your games? Any ideas what you MIGHT do?

  • Beaverlicious - I haven't played any of the FIFA games... What can you do on those title screens?

  • My job entails a LOT of driving, so I have plenty of time to brainstorm on my game. In trying to create the emotion and atmosphere I hope to convey during the gameplay, I started thinking about the title screen. It's too early in development for me to worry about that much, but it occurred to me that it would be, in my mind, very engaging to have an "interactive" title screen. More than just some (animated) images and a few options - "start", "options", etc - but rather the player can make things happen even before he starts playing.

    In the Nintendo DS game, "Mario & Luigi: Bowser's Inside Story", before you've even pressed "START", the bottom screen shows a reflection of Peach's Castle as...Bowser's Castle???...in the pool of water. The water is rippling a little. And when the player taps anywhere in the pool, the water reacts by creating more ripples. It's really simple and that's about all you can do. Yet, to me it's that interactivity even before you've actually started the game that makes it all the more fun, and I believe it can help set the mood very well.

    My game is a stealth game that I hope to embed with some subtle light-hearted whimsy as my robot main character seeks "more input" after escaping his creators shortly after his AI unexpectedly becomes self-aware (think of a mixture of the "Short Circuit" and "Wall-e" movies). On the title screen, I picture a side view of my robot in a platform view (the game will be top-down) and he'll automatically wander back and forth in the restricted area, with little animations interrupting things to show a tiny bit of his character. BUT! How much fun might it be to include some hidden functions when the player presses a key and find that they can control the robot to a limited degree? What might that reveal about the game? Will there be a tiny Easter Egg before the game begins? Will there be clues to the robot's otherwise minuscule character (he is just a robot, after all...or IS he)? And if you can do that little thing on the TITLE SCREEN, what ELSE can you do before the game begins?

    Those are my thoughts. What do you all think and what might you put in your game if you employed this feature?

  • stevefromio - No, sir, you make a LOT of sense right there. GREAT points. While I'm not too worried about C2's ability to handle a lot of objects at once, I do see the point about switching perspectives fluidly.

  • Colludium - Aye. I've learned just a finger-full of how Unity works, and I think the multiple camera objects feature is its best selling point.

  • Unity by far.

    Why is that? :)

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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