Rhindon's Forum Posts

  • My take on this would be to store the image information in a tilemap...

    You have to deal with roads that are not complete 90 degrees angles over longer distances though. Several interpolation algorithms can be applied here.

    I want to say that I'm following your meaning with this suggestion - which, for the very little that I think I grasp, I think could work - but honestly, I'm at a loss as to just how you mean for this to play out. Might I trouble you to detail what you mean exactly? Dare I ask for some images or sketches to help me visualize what you mean?

  • As you can see here I've uploaded the map of a real-life Texas, USA city. My plan is to have a city-scale environment (although there will be a conservative adaption of this real-life map to game map...not all roads will find their way into the game for lots of reasons which I will not waste your time in detailing to have you read through).

    Since this map is obviously extremely analog rather than the likes old-school video game sprites that are reused throughout each course, there's going to be a lot of custom setting-up of roadways. There's going to be no easy way about this, whatever I decided to do. So I was hoping to get some input from experienced developers who are familiar with the less-than-cookie-cutter development of levels and environments.

    My initial idea was to create objects at intersections that serve "hubs" for where roads are drawn and connected to other roads and intersections. However, I foresee this will have its own inherent issues and will hinder me in drawing roads beyond flat black with no details (because sprites will overlap with little to no regard for how road lines come together at intersections and so on).

    The alternative is to manually place all the road pieces and draw unique road pieces where needed...which is probably going to be my main recourse for a map of this nature.

    Obviously, there are a ton of roads, so, as I mentioned, I won't be including every road of the real-city map in the game map. But for the roads I do adapt into the game, what do you suggest I do to make the process as streamlined or as easy as possible? Whether I have to manually place each road myself (including drawing custom pieces) or device a system that draws most of the road pieces at Start Of Layout?

    I'd be grateful for any and all suggestions. I only hope I am able to understand and follow it all - despite all I know now, I'm still learning a ton and am only all too away that I'm ignorant about a lot. This is definitely the biggest project I've attempted so far...

    Thanks!

  • I literally copied the central part of my hometown in Texas for this part. Using a map of the city provided by the city's website, I created a kind of outline with which to set up the game's road system. There will be some differences, of course. Not all roads are likely to find a game counterpart and street names I plan to change. Nor will any actual building locations be included in the game (meaning, you won't find your house or business recreated in the game). But for all intents and purposes, the roads will be nearly identical.

  • Subscribe to Construct videos now

    A key aspect to my game is to have a large-scale cityscape to drive around in. I decided to go "all out" and actually incorporate an actual city into the game...my old hometown of Tyler, Texas.

    One thing I'm mindful of...hopefully more-so than not...is the fact that a large size like this will be more demanding on GPU. So balancing a large environment, a large number of objects (on and off-screen...working on that) and yet making sure that the environment is still big enough to drive around in (can't be too small) is all squarely on my mind. And more!

    But so far I think I've got the scale just right.

    I literally screenshot maps from the city archives and worked them into my game. Later I'll be adding a system which will adapt these map images to incorporate actual game road elements.

    This video is just to showcase the non-blocky road system I'm working on as well as the scale of the city and hopeful 2.5D visuals.

  • Following my post above regarding the technical set-up for the buildings, I used a similar setup for the creation of the sloped roads, too.

    Subscribe to Construct videos now

    At first, I was going to draw each road sprite at different sizes and then arrange them accordingly. The different sizes would represent different elevation levels in the city. And this probably would have worked just fine until I remembered I plan to include bridges, as well. Since I want to employ serious amounts of scaling/Z-elevation factors, it became clear that the roads wouldn't line up properly if different road pieces that represented different elevation levels weren't actually scaled properly.

    Simply put, everything that's on a different elevation level in appearance has to actually be on a different elevation level. But actually accomplishing that with the sloped roads was going to be tricky because if there's no way to scale a sprite where one edge is secure at a lower Z-elevation while the other edge aligns with its adjacent road sprite at a different elevation.

    What I did then was created "slices" of the road and spawned them in such a way that as the road pieces connect from end to end but are on different elevation levels, the road "slices" would "step" along to connect the two ends. It's literally like a set of stairs but because it's all flat images and aligned just right, it appears near-flawless (at least, I think so...). An actual sloped road that appears elevated from one end to the other.

  • I was asked how I did the "3D" buildings and the trick is really simple.

    It's literally just a stack of similar sprites with a progressive Z-elevation value.

    Using For() loops, I spawned [a number of] window and non-window sprites to create a "floor". In my case, I used 5 instances of a window sprite and 5 instances of a non-window sprite to make one floor...hence why the HowHigh variable on event line 3 is set to a multiple of 10.

    From there, I just tell it to alternate between a window sprite and non-window sprite. Every five instances of one sprite lead to a swapping out to spawn five instances of the other sprite. And I set the Z-elevation in according to the current "floor" count. To keep the buildings from appearing too tall, I divided by 4...but this is subjective and will depend on how you might want to use this setup for your game.

  • Subscribe to Construct videos now

    The Getaway is a "unique" racing game in that the opposition comes in the form of time and the assortment of enemies and obstacles found.

    Held captive by a mysterious villain, the Driver must navigate an enclosed cityscape to survive and escape to freedom. With complete freedom to navigate the city, the Driver must complete a series of missions in the hope of outwitting his captor and leave the giant prison. Further, the Driver can explore the city to find clues as to the truth behind his capture and the nature of the city.

    Features

    These are aspects to the game I hope to include, though the cutting room floor is sure to be filled...

    • Multi-level roadways - Using layer scaling and Z-elevation in creative ways, a sense of depth will be crucial to the level design and graphical presentation.
    • Hi-speed missions - Each of the main missions will feature a race against time as the Driver seeks to achieve his goals. Quick reflexes will be needed to navigate the city as the Driver pushes the pedal to the metal. If time runs out, it's only the beginning of the end as the Driver must then face off against an increased set of challenges all while still trying to complete the mission.
    • Drive + Run - The obstacles and enemies will leave a toll on the Driver's car. But just because the car takes one too many hits doesn't mean it's automatically game over. The Driver will have the option to get out on foot to find alternate vehicles to drive. But this will leave the Driver severely vulnerable...

    Themes

    The themes of the game could probably fit all under the "do or die" mantra...except on four wheels (and sometimes two legs).

    • Fast, constant tension
    • You're not racing to be first, but to survive
    • Exploration is the key to solving the mystery
    • Time is a patient enemy

    Tagged:

  • jobel - I wanted to avoid using additional layers because, with z-el now a feature, it's unnecessary by-and-by. At least, if there's a better way to accomplish the visual effect I'm hoping to achieve. It's more details to manage and it can get rather cluttered in my mind.

    oosyrag - Ah okay. I'll try those effects instead. Thanks!

  • Sorry slightly offtopic, but that looks great! Hopefully you want to do a tutorial some day (in high concept form - to save time).

    Good luck!

    I appreciate that, very much! Thank you!

  • I was hoping to avoid having to use so many layers, but, ah well. Worth a shot. Thanks!

  • My game is a top-down view of a circular environment with a center pillar...Basically, imagine a gladiator pit in the shape of a donut.

    Using Z-elevation on multiple instances of the inner- and outer-ring wall objects, I've created a pseudo-3D arena effect. Works almost perfectly!

    But to really drive effect home, I want to implement the blur effect that happens when objects in the distances or up close - whatever is not in the focus view (like how movies do for people in the distance or up close) - are blurred. The focus is primarily on the ground level. So that would mean that the closer you get to the camera (assuming it's waaaay up there above the arena) the more the top of the walls and pillar becomes blurred.

    I tried using gradual intensity settings for each layer of the center pillar but the results weren't quite what I intended.

    I was hoping for some suggestions on the settings I could use.

    Thank you, kindly.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Doh!!! So obvious... Thanks for that. I'll test it out when I get home. Thank you!

  • Objects in question: Enemy (sprite) and Enemy_Life_Piece (also a sprite, dubbed ELP for this post).

    Event lines under the Enemies Group starting at event line 7.

    .c3p file: https://drive.google.com/open?id=1mDQ7d1IbTZcVgGcrrNBfhL89J9rvi-wt

    Controls: Arrow keys to move, spacebar to fire

    (Allow a few seconds to pass for Enemies to spawn from the center pillar in the game environment. Their movement system has been disabled for testing. They will spawn and stop once they are no longer overlapping the center ring. Up to a max of ten Enemies will appear around the edges of the center ring.)

    When an Enemy is spawned, the ELP is auto-spawned with it because they are in a container together. The Enemy has up to six stages (from a triangle to an octagon) with its own HP at each stage. The ELP is a kind of "health gauge" for each stage which "fills in" each of the slices of the Enemy's current shape (eg: if it's in its triangle stage, the ELP will show three transparent triangle slices). As the Enemy gets hit, the HP will drain and the animation frames of the ELP will display accordingly. So if the Enemy has a max HP of 75 and has only 25 HP or so left, only one triangle slice should be displayed via the ELP.

    Now, this system works in as far as continual attacks go. The problem I'm having is that when the Enemy is initially spawned, the ELP does not display correctly. In fact, it won't display correctly at all until it is reduced in its stage. If it starts out at the square stage, reducing it to the triangle stage will result in the ELP displaying correctly as the Enemy's HP is continually drained.

    I can't figure out why this is happening... Can anyone see what I'm missing?

    Thank you.

  • Oh!! That must be it! I had forgotten that z-el had a base limit of 0. I was setting it to 0.25 and THAT'S why it didn't seem smaller/father away than the "twin" object above on the layer atop.

    That explains everything.

  • That shouldn't make a difference here. One 9patch item is the only object on an entire layer. The other, its "twin" is at the bottom of the other (which is also z-elevation=0). The one on its own layer is below the other layers altogether.