deadeye's Forum Posts

  • Yeah, I realize that. Like I said in my TIGS thread, I feel kinda bad that the largest project made with Construct to date is about Hitler on a temper tantrum.

    Sorry, Ashley. It was the Random Game Name Generator what did it So far though nobody has scolded me for making it.

    But yeah, nobody go promoting this elsewhere as a turorial. It's in no way official, and has no affiliation with Scirra. As a mere Construct user, I take full responsibility for it as my own creation.

  • I'm trying to get the canvas to draw a line in a loop between four objects, from one object to the next, in order to draw a polygon.

    Here's the .cap:

    http://www.mediafire.com/?yamw9oepewn

    I have four copies of a sprite, and each copy has it's own private variable called nodenum. They are numbered 1, 2, 3, and 4, and this number is stored in nodenum.

    The I have a counter object that contains drawfrom and drawto variables. It starts at drawfrom = 1 and drawto = 2. It's supposed to find the node who's nodenum equals drawfrom and store that node's x and y coordinates in yet another object's private variables (ax and ay). Then it finds the node that matches drawto and stores it's coordinates in bx, by.

    Hope you're with me so far. Anyway, the counter then counts up drawfrom and drawto, so now drawfrom = 2 and drawto = 3 in preparation for the next line.

    Then it's supposed to draw a line on the canvas from ax,ay to bx,by, and start the loop over again.

    Here's the event sheet:

    <img src="http://i25.tinypic.com/24e81tl.png">

    I'm having two problems:

    1. The canvas seems to be resizing upon running the layout.

    2. It's still drawing a line... but it only draws one line, and the line is offset from the nodes 1 and 2. Like this:

    <img src="http://i32.tinypic.com/2mq3g2b.png">

    The tan part is the canvas. It's supposed to cover the entire image.

    I'm pretty sure the canvas resizing is a bug, but it seems like it wants to draw anyway. But there's only one line... is there something wrong with my loop? Should I be doing this differently?

  • You're forgetting the main thing :

    Compare Construct 1.0 to MMF 2 without extensions.

    Construct 1.0 wins so much.

    MMF2 has extensions, but Construct supports them too! So it's up to the community to create whatever they need, a pixel physics? Other stuff? All possible with plugins.

    You have a point, but the reverse is true also... MMF extension developers can (and have) extend(ed) the capabilities of MMF.

    So will Construct have per-pixel physics one day? It's likely. Then MMF will have this. And Construct will have that. And back and forth. There will always be advantages that one has over the other. It's up to people to decide for themselves which they want, or need.

    All I'm saying is that right now (with Construct in an incomplete state) if want to make a hassle-free game and you can use MMF, then use MMF.

    Personally, I think MMF is superior to Game Maker. But Game Maker has a much larger community than MMF. Go figure. It's all about what people are comfortable with.

    When the time is right, users will come. Already a couple of people who saw my thread at TIGS have tried out Construct. I think that's going to be the best way to spread the word for now... just make some cool stuff and throw it out there for people to enjoy. Those that are interested will bite.

  • I was actually never able to understand MMF's interface. And I think Construct is generally easier to use. Yep, I love it, so I'm sticking with it.

    While I eventually got it down somewhat, I never got over the annoying fact that you have to scroll back and forth in a spreadsheet to hunt for your objects and hover over some little checkmarks to see what your events are, so agreed 100%. Construct is hella easier to use.

    And I'm sticking with it for now because I don't have any of my deadly-serious projects ready to go yet, and I don't have the skillset to start them, so they can wait along with 1.0. It seems that Construct and I are developing at a similar rate, so by the time 1.0 is ready, I'll be about ready to start on a major project.

  • I just want to interject something here...

    Construct has better hardware support and physics,

    Yo, check this out:

    My First Skydiving Academy

    Physics in MMF. One of the most polished MMF games I've ever seen, too. It's damn near flawless.

    MMF might have it's physics drawbacks, but so does Construct. MMF can do per-pixel stuff, whereas Construct can't. It's likely there will always be differences like that between the two, causing people to waffle on which one they want.

    So if it's a matter of sitting on the fence, well... go with MMF for now. It is more viable. It's a much more complete product, and hence a more logical choice for game development at the moment. The time you spend mulling over which product to use you could spend instead on creating something cool.

    Other than that, I agree with ssbfalcon. Just give it time. It'll all come together eventually.

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

  • I went straight for the physics when I first got a hold of Construct, so I'd say Pachinko. Or Billiards (which I did). Maybe Mini-Golf (but you wouldn't really need physics so much for Mini-Golf).

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • DISCLAIMER:

    This project is in no way an official Scirra tutorial. It is my own creation. I am merely providing it to whoever wants to look through it for educational purposes.

    So here it is. The full .cap, the demo build, the sounds, and the music for Little Hitler in Toyland.

    http://www.mediafire.com/?xdytqn2fyjr

    What's covered:

    • Menu Screen
    • Controls
    • Animations
    • Audio
    • Enemy AI
    • Collision routines
    • Level changing sequences
    • How to make jump-through platforms
    • And, uh... Everything else. It's all there.

    It's all rather heavily commented. I explain what variables are doing and why certain events are being used, how to achieve certain effects, etc.

    In the places where I knew I could have or should have done something different, I made a note about it. Likewise I commented where there is obsolete code that was fixed by the new platform movement in .93. If you have any questions, or any critiques on how something could have been done differently, feel free to post them.

    Hope this helps some people out.

    Oh and I don't think I have to mention this, but it's just for educational purposes. So don't go using the art in your own project or releasing your own build with new levels or whatever. Not that I think you would, I'm just saying. If you're really itching to help me with a final release or whatever then PM me. All other questions about it belong here in the thread.

  • Hey Hideous, good to see you stop by.

    Did you block Construct from connecting to the web to update via the hotfix? It should fix the Platform movement... unless Ashley took it down for some reason.

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

  • What, it's really that easy? Just add "* TimeDelta" to the end of all your per-pixel movement stuff?

    Wow. It is nice to know what it means behind the scenes, but I thought it was way more complicated than that.

  • 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

  • Glad to help

    And yeah... the title was made with the Random Video Game Name generator. The game was going to be a competiton entry at TIGSource, but I didn't quite finish in time.

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