HYDRA Engine - Idea for future game implementation - Printable Version +- Save-Point (https://www.save-point.org) +-- Forum: Games Development (https://www.save-point.org/forum-4.html) +--- Forum: Upcoming Projects (https://www.save-point.org/forum-15.html) +--- Thread: HYDRA Engine - Idea for future game implementation (/thread-5129.html) |
HYDRA Engine - Idea for future game implementation - JayRay - 05-04-2014 Okay, so, maybe this is more of a notekeeper than an announcement at any rate. I've been tweaking around with FPLE, and H-Mode 7 recently, and have unlocked higher resolution. I can't do anything about H-Mode 7's 640x480 LIMITATION, but with tilemap rewrites by Goldaryn, I have successfully commuted a H-mode 7 and FPLE engine together into an 800x600 screen, which I may use for a RPG at a later time. I'm going to work out a simple tilemap and movement demonstration very soon, but the best thing about the engine is that I've completely halted the rendering effect for strafing, moving forward and back and for turning, so that I can start rendering models to take up event blocks and angle in ways as to continue the perception of 3d. Screenshots to follow of course, but, basically, with the common horizon in FPLE, I have something like this... There are 33 positions on the default FPLE horizon, and that's great, but in actuality, since events zoom no matter what, I actually have 7 positions to meet perspective guidelines. This will allow me to have an object rendered in world, as long as I take into consideration the position of the camera (FP) and the labyrinth entity(LE) This also allows for some interesting skyboxing possibilities, if you want to spend the time in taking the right amount of pictures for each event and stretch them to line them up right with the scene. FPLE's own system allows for this quite nicely, if not without a little bit of a grind in placing all those 480x480 events in the players' view. What was spoiling the illusion was that gradual movement from point A to Point B namely, something like this... Code: when 4 # Strafe right What I've done is on this movement, is taken away the incremental change, and replaced it with a not very well known wait command inside the script itself. Code: when 4 # Strafe right Now this changing of the @offset_x -2 to @offset_X-32 would really mess things up if you pressed Q, you'd sidestep about 4 tiles before you figured out you moved. The 40.times { Graphics.update} makes the engine wait until that second is up before saying "Hey, you're here, this is what you see". This also gives you more ability to render your objects in the one of 7 positions from your camera offseting each position by whatever perspective is needed. Remember also that while the walls and floors might be limited by 8, you can design events(and move them) for the entire room and be as diverse with your events as you want to. Each event can be styled in one of 6 positions.... like so... so if you need "flat events" you actually need two events to ocupy the same square. If facing north, that can be a Type 1 D-Align 0 and a type 1 D-Align 1, but what would be BETTER is in the grid directly BELOW it on your map, adding an event that is Type 1 D-Align 2 - This is more in line with the way the engine recognizes Z status of events, and if you declare that an event is say, shut on or shut of depending on the angle that a player is facing, you can easily create the illusion of floors with vast array that you've come to expect in your game. What's important is that you remember the perspective of each event, and change graphics accordingly. This may require several event graphics per floor tile, but with that, you can create auto-tile like floorscurves, even distortions to give your room a rounded or worn floor look. Combine that with an indoor and outdoor transition between FPLE, and H-Mode 7 and you the beginnings of a nice little engine to explore an RPG world with. |