Asteroids with a funny twist! Game/toy

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Asteroids Game Pack contains environment elements, vehicles and a background to create an arcade asteroid space game
  • Ok, her's a little thing me and a friend of mine made in a day. You can't finnish the game yet, ther's no goal. The only thing you can do is fly around and push the asteroids and enemy ships with your high-tech weapons.

    Controls:

    Left/right-Rotate

    Up- Speed up

    Control- Fire pushbeamthing

    Shift- Shockwave (hold to charge, release to shoot. Takes about two seconds to maximize.)

    The big issues right now is

    1. The little twist preformed by the enemies when they pass the angle of 0*. We got it to work with one enemie, but then it flipped out. I wasn't the one dealing with that part, so i don't really know what the problem is right now.

    2. Collision detection impossible with objects using the physics movement. Tried some simple things with detectors that didn't work very well. Is this planned to be implemented any time soon Ash

    3. I couldn't find a way to make the edit box accept numbers only.

    Comments and critics are highly Appreciated!

    Edit: Hrm... forgot the link. http://www.mediafire.com/?brwzz4zjzgw

  • That's pretty cool. If I had any complaints at this stage I wouldn't mind you being specific about how you want your movement controls to work. The low-acceleration, high speed turning is difficult to manage.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I've had a little bit of success making physics detectors with Create Hinge. For instance, if you have a solid physics circle that's 32px you can make a no-collision physics circle that's like 36 or 38px and attach it via a hinge with high stiffness. The hinge sticks better than setting the xy coordinates with an Always event because it happens during the physics behavior update rather than in your event sheet, and since it doesn't do physics collisions you can test for basic sprite overlapping. Also be sure to set your detector to like .01 mass so it doesn't cause drag on your object.

    Something to try anyway.

    And I'm afraid I can't check out your game at this moment because I'm posting from a different computer, but I'll be sure to take a look as soon as I get on my own.

  • That's pretty cool. If I had any complaints at this stage I wouldn't mind you being specific about how you want your movement controls to work. The low-acceleration, high speed turning is difficult to manage.

    Hmmm... i think the movement is very easy to controll right now, unless you check the "realistic movement" box. Well, lets hear what other people say, and maybe i'll change it, but personaly i like it right now.

    deadeye: I'll give it a try! Thanx!

  • Okay, I've had a chance to play this.

    The graphics are cool. Did you do them yourself?

    The player movement is nice and Asteroidsy. It feels authentic. That said, I never was very good at Asteroids so yeah, it's kinda tough.

    The pushing physics works great.

    And on the down-side:

    1024x768 is way too big for a windowed game. The biggest you should ever make a window is like 800x600, and even then that's kinda big. So I changed it to 800x600 and rearranged your map level. When I did I noticed that the lasers were spawning away from the ship, which leads to my second crit:

    You shouldn't use the System object to spawn object-specific things. Instead of this:

    [ul]	[li]System: Create object Sprite2 on layer 1 at (0,0) from Spaceguy's image point 1[/li]
    	[li]Sprite2: Set position to object Spaceguy (image point 1)[/li]
    	[li]Sprite2: Set angle to Spaceguy.angle[/li]
    [/ul][/code:2lpz6vwi]
    
    You could just do this:
    
    [code:2lpz6vwi]
    [ul]
    	[li]Spaceguy: Spawn object Sprite2 on layer 1 (image point 1)[/li]
    [/ul][/code:2lpz6vwi]
    
    First, it makes more sense to have the object doing the shooting to spawn the bullet, and second, it only takes one action (because the Set Position and Set Angle are taken care of automatically).
    
    Anyway, it's a cool project and I'd like to see it developed further.  Hopefully you can get your collision stuff working.
  • Thank you for your comments!

    Yeah, i did the graphics! Glad you liked it! If this becomes a whole game i don't think the movement will be too hard. You get in to it after a while, but for a demo like this when people just play for a coupple of minutes it might be hard. Did you try the "realistic" movement? That's how it was in the beginning.

    Why should the window size be smaller? I chose that size because i didn't want the screen to scroll, but i still wanted to be able to create variated levels (hard to do on a small screen).

    Thank you for your tips on the spawning thing. I looked at that event first, but i didn't really know what it did so i took the one i was used to.

  • Why should the window size be smaller?

    Mainly because not everyone's desktop is set to "huge." A lot of people still have dinky monitors, or are far-sighted, or just plain like a lower resolution. My desktop is set to 1152 x 864 because my icons and fonts show up nice and readable but still small enough to have room on my desktop.

    A 1024x768 window spawns halfway off the screen for me, and it takes up a lot of space. And if it happens to me, it'll happen other people.

    If you want windowed, stick with a max of 800x600. Anything higher, go with fulscreen. I played around with your game at 800x600 for a while, and it seemed fine to me.

    Thank you for your tips on the spawning thing. I looked at that event first, but i didn't really know what it did so i took the one i was used to.

    No problem

  • I don't see what all the fuss is about. When it comes down to it, someone can make their game to any minimum specification.

    Especially nowadays with HD becoming the norm, 768p isn't all to uncommon. Around here, all the lowest end 4x3 monitors you can readily buy at WalMart are 768p minimum. The shitacular one my parents have is 1152x864.

    It would be nice if Construct had the functions built in to scale to any resolution automatically within the same aspect ratio. I've made my StarFox project at 480p, but I wouldn't mind having the program render it at a higher 4x3 resolution for runtime.

  • Okay then. I'll just pop on down to Wal-Mart and pick me up a new monitor. They take Monopoly Money, don't they?

    Seriously though, you do have to keep in mind what your users are going to be playing on. If you're just making the game for yourself, that's cool, go hog wild. Set it to ten bajillion by twelve quadzillion resolution if your monitor can handle it. But most windowed games are 640x480 or 800x600 for a reason... to be as compatible as possible with most people's systems.

    And HD isn't as norm as you think it is. A whole lot of people are still using computers they bought five years ago.

  • And I bet they're still enjoying their 52nd playthrough of Half Life 2 on them. Look, I'm not saying you're wrong. I'm saying 1024x768 is not as bad as you're making it to be - even on aging computers. Forcing VGA resolution compatibility across the board for the sake of keeping some Windows ME or similarly ancient budget computer from y2k running with a sense of purpose is kinda flipping off the progress of yearly computational advance - not to mention it's not preparing for the near future.

    The market trend is overwhelmingly widescreen high definition. What about the multitude of users with new and seemingly ridiculous WUXGA setups? 480p can take up less than 5 inches across on the smallest of those, and since you're most likely sitting at a desk in that situation you might as well pull out your Gameboy to experience the same effect.

    There has to be balance between the old and new. 768p seems entirely reasonable to me, even on my own 4-year-old HP laptop.

  • Look, I'm not saying you're wrong. I'm saying 1024x768 is not as bad as you're making it to be - even on aging computers.

    I didn't say it was a bad resolution. I said it was a bad size for a window. Go ahead and make 1024x768 fullscreen games.

    I can't recall ever using any games or programs that run in a statically sized 1024x768 window. And there's a good reason why... it's to big to cater to a significant portion of people.

    In five or ten years when everyone in the world has HD monitors it won't matter. But if you really want to go blazing trails on your crusade to promote HD window sizes, go right ahead. You'll be alienating, or at the very least annoying, a large portion of potential players. Will they be able to play it if they change their desktop size? Sure. And so could I. But why the hell should I have to? It's a courtesy thing.

    I guess if you don't care about alienating users, or you really just want to cater to the HD niche and not bother with anyone else, then that's fine, but it doesn't make my point any less valid.

    And my point about making this particular game 800x600 still stands as well. I did it. It was a simple fix. I resized the window and then resized the map to fit it. It didn't seem to adversely affect my gameplay experience at all. In fact, it was more enjoyable, because it fit nicely on my screen.

  • Why should the window size be smaller? I chose that size because i didn't want the screen to scroll, but i still wanted to be able to create variated levels (hard to do on a small screen).

    Sorry to jack your thread, man. We're two different people with strong views on the subject. But the above quote is where I'll agree that your game would fit in a smaller window.

    Of course, decreasing the playfield causes an inherent problem with all your sprites. They become 28% "bigger" onscreen. They're the same size, but now there's less acreage for which to act in. You'd have to shrink your sprites to about 75% their original size (Construct can do this in the object's properties window).

    This isn't necessarily a bad thing. You don't have to change your playfield to accommodate for level variance. The SNES had a resolution of 512x448, yet it still produced gems like Chrono Trigger. If you really look at how modern games are made in HD, you'll notice the extra pixels don't really affect their design too much (16x9 aspect not withstanding). If they were to remake Chrono Trigger on Xbox360 or PS3, They surely wouldn't keep him at 30 pixels tall. Similarly, they wouldn't use 12-point font, would they? The game would be unplayable.

    Games are still made with about 480 scanlines in mind, no matter the resolution. The games aren't really getting bigger playfields, they're just getting more detail per square inch. This allows for them to be scaled down to be played as low as VGA resolution and still be readable, playable.

    And that's what you should consider with your Asteroids Push game thing. Would your levels fit on a standard 480-line tube TV? If not, you need to rethink sprite sizes, level density, and whitespace (get it? whitespace? aww) accordingly.

    While I regard 768-windowed as perfectly fine during the transition to HD, I disagree with why you've chosen to have the high resolution. Deadeye is correct that you should want to make your game as accessible as possible, and he and many others still use equipment that can't support that in windowed mode, or they're unwilling to change their habits just for one program. They are valid points.

    I know you put a lot of hard work into those nice graphics and want to show them off. Here's an idea, though. Play with that zoom function to always scale the whole playfield into the current window size. Make your game at a high resolution, and find a way to allow the user to switch window sizes at runtime (Ashley, is that possible?). That way, people who can run your game comfortably at a high resolution can do so, but people who wish to scale it down a bit won't miss out on anything.

  • [quote:ds4lfd1u]allow the user to switch window sizes at runtime

    System - Set display resolution!

    Just to throw in my thoughts:

    I run a dual monitor setup, each display at 1024x768. Windows doesn't let you create windows bigger than a display (for a good reason), and with all the added window caption and borders, that means the window is squashed a bit. As a result, DirectX is scaling the display slightly smaller with a linear filter, which ends up "blurring" fine pixel graphics like text and reducing the quality of your graphics. Plus with a window the size of my display, I end up fiddling about trying to align it with my screen. The next build can change between fullscreen and windowed at runtime, though, so you could always have a 'Press F to go fullscreen' in the title screen or whatever - I really would rather go fullscreen at 1024x768 than windowed.

  • Whenever you talk about what's new or fixed in the next build my shriveled Grinch heart grows three sizes.

    Sorry to have cluttered up your thread, Attan.

  • Well... i could have solved it in many ways, but when i made it i didn't even plan to post it here. We just made it for fun but i thougth you might like it so i posted it her too. For now, i've just checked the fullscreen box, but i won't repost it. It's easy to do by your self.

    But you have a point deadeye. I know how frustrating it can be when people make games that you can't play and tell you it is "standard" to have what it takes to play hit... hrm... pixel shaders.. Anyways, i didn't even think of the fact that some people might have a lower resolusion and what that might result. I will keep that in mind in the future!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)