inkBot's Forum Posts

  • I have voted for families, but I have no idea what it is *gg* I hope that is a group function.

    http://sourceforge.net/apps/mediawiki/construct/index.php?title=Families

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Voted families again. ^^

  • I want to throw this out for discussion.

    Would there be any point at all in adding a tile-specific positioning system? Think rows and columns in excel sheets.

    Edit: Tiled might be a good editor (I dunno, haven't used it) but tailoring C2 features towards it specifically would be a really bad move. What if Tiled stops being worked on?

    Allowing C2 to read XML files and generate terrain based on that would suffice, no need for specific Tiled features I'd say.

  • That's a pretty good puppet.

    I agree with Kyatric, a series of videos with this guy explaining C2 a bit more indepth could be a good marketing tool, and of course fun. ^^

  • I voted families. Tilemap was a close second though.

    I thought about voting on function object, but I haven't used it in CC enough to really need it asap. But I thought of something I thought I'd suggest. When the function object is included I think it could just be baked into the system object, kind of like how loops are.

    Another suggestion. I think that it'd be a good idea for when you eventually get to tilemap support, that before you start working on it write here on the forums what you're intending to do and collect some feedback on it. As I imagine people will be expecting different things about how it would/should work.

  • A friend of mine has both an iPad and an iPhone (I've also converted him to Construct ^^). I've poked at the iPad a bit and it's pretty nice to use (sooo much better having one of those instead of a bulky laptop when dm'ing!). I'll eventually get an Android tablet though. It seems to suit my needs better.

  • I see no reason to change the name. All that would do is create 'further' confusion to new users.

    #1 is already doable. Just specify some other key (or whatever you want) instead of shift when making the jumping event.

  • The licenses are pretty clear, I don't see why there would be a difference when making a [genre] game than from any other [genre] game. If you make over a certain amount of money ($5000) with the standard license you'll have to pay for a business license.

    I have seen this situation numerous times. If you are new to developing games and young, I'm not sure you are but it seems that way to me, then making an MMO would be as Phobos said "insanely difficult". Not exactly impossible, but improbable at the very least.

    An MMO is an incredibly intricate thing to make, on top of actually building the client you'll need to maintain a server (getting C2 to speak to the server is only a small part of the battle there).

    I suggest starting small. Make test games with game mechanics similar to what you would like in your MMO. Then gradually work upwards, trying to get two people to connect to the same game, then three, then four etc. If you try to do it gradually you'll have more experience to take from when trying to do the "real thing" than if you just ran into it headfirst.

    This isn't aimed at Construct but I'd say it's a good read.

    devmaster.net/articles/building-mmorpg

    Also, for future reference, writing in all-caps does not really help you get people to read your posts. Probably the opposite.

  • Just bought my license. For now the standard license suffices well enough for me. I plan on making commercial games at some point in the future, and if the early adopter plan runs out before I hit 5000 (likely). Hey, more money to you guys! =)

  • if you view the source. Some of the games have over half a megabyte of javascript code!

    Well, I guess they'll have to keep consistency between products. I've always thought GameMaker was bloated.

  • The way I would do it is to have two variables, one for checking if the character is doing anything, let's call the variable 'idleCheck' and the other for a countdown, 'idleCount'.

    So you set up so that whenever the player does 'anything' you change idleCheck to 1 (or true or yes, whatever works for you) and when the player doesn't do anything it reverts back to 0.

    Now, when idleCheck equals 0 you start adding to idleCount, effectively counting upwards, and when the number goes beyond whatever amount suits the time you want you start your zooming event. If idleCheck turns to 1 (player does something) you set idleCount back to 0 and reset your zoom.

  • That works really well ROJO (and if you give the tile sprite a variable you can use that as an index for what animation to play, using the same frame hierarchy as the current one you can use that for separate tilesets. =P

    Definitely gonna have this in mind if I ever do a level editor.

    Anyway. This does what I want to do, but even so it's not efficient enough for actual use. I want to use this real-time on a larger level. Updating every sprite with a loop pretty much constantly will make the framerate drop like a stone.

    So I tried to make it more efficient. First, a "for each" loop that runs once at the start of layout, then with a second I tried to limit the loop to only updating the 8 tiles surrounding the tile that was destroyed.

    box.net/shared/v990kh0t3c6xse0y5jp1

    It seemed to work alright. So I increased the resolution and filled the layout with tiles, and the framerate is still dropping. As I'm typing I realize I made some mistakes (running the loop 8 times and essentially picking all of the eight tiles each time, for instance)

    I'm not there yet, but I'm getting closer! =)

    Edit: I think I did it. If so, wooh!

    box.net/shared/qrib8jot0ejpz5io5q5c

  • I'd say what you want is to use the path behaviour.

    A trajectory is something entirely different. http://en.wikipedia.org/wiki/Trajectory

  • newt: That article looks great. I only skimmed it now, going to take a closer look at it tomorrow.

    ROJOhound: That was a much better way than what I did. I messed around with it some and it seems like it doesn't want to update all of the sprites (or any at all) if you, during runtime, take some away and run the "for each" loop again.