catch22's Forum Posts

  • Er... By nature if an event occurs every X ms it's timesynced to begin with. The problem with unlimited FPS is some computers might run the game at 100fps, some at 20fps, so on and so forth. You never know. So moving something by 50 pixels every step will vary wildly depending on how fast the game is rendering.

    If you're doing things in steps of time anyway, you don't need to worry about it.

    Maybe you could elaborate exactly what you're talking about, because what you've listed is the same as doing 100ms x 50, x 100, x 150 (5 seconds, 10 seconds, 15 seconds).

    Why don't you just "do this every x ms" (every 5, 10, 15 seconds) ? Why bother adding to a counter?

    EDIT: Missed this question:

    [quote:10frcve3]Also, unless I misunderstood, Time Delta varies. This means the value will never actually be exactly 50,100, or 150, right?

    Sure it varies a little (or can a lot), but it ultimately depends on how much you're doing each step. If you load resources at random times during the game it'll sky rocket when you do, compared to if it's humming along just doing the same stuff every frame.

    TimeDelta is usually a very small number. For example 0.0013. It's the time it takes your computer to perform 1 game loop. Even on a "slow" computer, it's usually a very small number (compared to whole numbers). Most computers can render a basic game at 60fps solidly with vsync on. Mine can run my sample projects upwards of 10,000 at times with it off. That's a really small number

    I can't think of a reason you'd need to be using TimeDelta in a cumulative fashion like I think you're attempting (even though it's not in your sample you give). Construct does this for you by offering the "every X ms" event.

    But again, unless you elaborate more, I can't even fathom what it is you are trying to accomplish. But to answer your question... if you are adding it cumulatively every gamestep... if you're casting it into an integer, it will eventually land on the whole number you're after. Yes. But if you happen to do something time consuming at that moment, it may skip over the number you are after. I'd encourage you to use greater than/equal to as opposed to just equal to.

    But for more accurate time calculations, just use what construct offers.

  • Just to further the compliments on construct, I'm a C++ programmer for many years, and I always looked down upon game makers as half-assed, no-skilled dead ends for people too lazy to learn how to really make games. They were always too limited to make anything decent (and typically, suffered horribly in performance).

    Forgive the snobbery, just being honest.

    However, Construct has changed my opinion completely. It's extremely well done. While it still has its limitations, it's light years ahead of game makers I've looked down upon in the last decade... to the point where I'd say it's a mandatory wrench in any game builders toolbox. Whether they use it to release the game or not. It's just marvelous for fleshing out ideas quickly and getting demos up and running to pitch ideas to others.

    Most of this is based around the open-ended nature of Construct and it's ability to be extended by a powerful scripting language. Instead of offering people a box to play in, you've given them an engine they can tap into (effectively, giving them a world).

    Well done, Scirra!

  • Just my two cents, but this is probably why virtually every support service from game companies begins with... "reinstall your game and try again."

    Because I'm sure they've wasted countless hours trying to fix games people tinkered with and broke.

    Something else you could try is preemptive file screening. It would be a little bit of an upfront time sink, and possibly more complicated than it needs to be... but do an md5 hash of all your files and store them in your compiled source. Then at run time you could scan and compare your external files to the md5 hash (for example).

    If the file signatures don't match, politely inform the user there's a problem with the file, tell them to reinstall it, and quit.

    If you use thousands of external files, this would suck. If you use less than 50, it's probably not too difficult to do this. EDIT: Alternatively, you could zip archive your files and use zlib to access them... then just do one hash of the zip archive (this isn't hard to do in C++, but in construct it might be tricky... Though there are python zlib and md5 scripts out there).

    That's just one idear I had off the top of my head.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Excellent update, guys, and very much needed for us Python types.

    The reference to newly created objects is dreamy.

  • I just recently posted a thread here "Fix Your Timestep" which essentially illustrates this problem and even includes a comprehensive fix for it.

    At this point, it's up to the developers.

    Well, this is open source, I guess I could post a patch. Not something I'm able to dive into right now, unfortunately.

  • Oh yes, based on the above users suggestion, I forgot to say in mine....

    Import/Export of layouts/sheets is extremely important in a team environment.

    Merging caps would be another godsend.

  • I'm still new to Construct, so my suggestions may be short sighted.

    • More Python integration. Currently exposure to the core engine is hit or miss. By more, I guess I mean full exposure. If I can "point and click" to it, I should be able to just python it.
    • Speaking of Python, the current editor is kind of fumbly. Tabs for example sometimes work, sometimes change focus in the window. Sometimes the tab brackets don't work. Copy-pasting acts weird at times. The "intellisense" (helper text) isn't very complete or helpful, usually. It's not any one thing, it's just not as polished as it probably could be. Right now I use IDLE and copy-paste. But, then there's copy-paste issues at times (python could be less nazi about indentation in general, but what do you expect from a language that has an optional end statement operator).
    • Networking. Nothing more than a layer or "wrapper" is really required, but some native support to connect and send packets around would be swell. PodSixNet works pretty good right now. Having integrated support would be faster, though. Object Replication would be dreamy creamy, but you did ask for blue sky stuff. This is the stuff end users would be interested in. Making a network object and telling it to be broadcast, and it internally be taken care of.

    RakNet does all of this, quite simply too. I know the licensing might be an issue for an opensource project, but that should be between the game creator and Jenkins, not Construct and Jenkins (RakNet is free for most people -- only when the dough rolls in does he ask for a cut).

    • Sprite Indexing and or easier/more obvious instance selection. Instancing in Construct is rather "masked." I don't know why, as it's extremely vital to select the thing you're trying to modify. For Python too!
    • Astar module? I have it working in python, sure, but again, more integration means faster computations (compiled C++ vs. python...) It's a pretty easy thing. You guys even have a "node" editor built into some modules, so laying custom paths down would probably be easy, even for 1.0. Pre-generated pathing nodes would be a must too (and would probably be a lot faster in C than again, Python). Not that python is dog slow, it's pretty quick, but more speed is more speed! *grunt, grunt*
    • Speaking of Astar, that's probably too low level anyway. Why not just go for sky blue and do AI actors? It's a pretty important part of a game, these days.

    Hm, I guess this is more of a 1.0 wishlist than a 2.0 one. Most of this stuff I could see be attainable for 1.0, or well, should be anyway.

    Like I said, I'm new still. Can't think outside the box yet =)

  • Have any of you developers read this by Glenn Fiedler?

    http://gafferongames.com/game-physics/f ... -timestep/

    Just curious on your thoughts of possibly including this in a future build of Construct?

    I noticed that the physics are tied to the frame rate... I can't run unlimited FPS or the physics are non-functional (basically). Possibly I am missing something, though (I am using TimeDelta where applicable).

    Feel free to correct me if that's the case, otherwise, I think you'll find Gaffer's solution to be quite simple and very effective. It also takes into account time scaling (slow motion, fast forward replays, etc).

    PS: The State stuff in the article snippets is a little confusing, but if you scroll down and download/run the source code example for the tutorial, it'll make more sense.

  • I had some success doing my own cap of this today but im not much of an artist so the graphics didnt line up very well.

    You could do it in python using py picker and some code to orbit objects around a point (in the event you wanted to maintain the running circle feel). I ran out of time at that point and didn't continue. I hope that steers you along the right path though.

  • Is your bullet object global?

  • AJAX, CSS, and some creativity can yield a lot.

    As for WYSIWYG... I wish I knew. I'm too old school, I just type stuff. I know, it's silly

  • Fun comes first.

    Part of the fun can be exploring strategy. I'm never a big fan of the "BFG" mentality, but rather trade offs between different playstyles.

    A smaller sword might hit for less and have a lower range, but it might swing the fastest, meaning in the situation where someone wanted to capitalize on that strength, their playstyle would differ from other people using a longer, slower swinging sword... but one that hits much harder per swing.

    In the end, you should probably put your balance numbers in an excel (or open office) sheet and create a balancing system (a number value for each strength) and try to get the weapons to equal about the same total value... but with different distribution.

    But by no means should technicalities circumvent fun. People play games to have fun

  • Just theory crafting, but why do a huge sprite?

    Why not break up sprites to represent terrain and stop drawing them when they go off screen?

    Your map would be really long, I guess. But I can't see it being so different than moving the player sprite rather than the world, it's the same net effect.

    Are you trying to maintain the ball rotating look, or ? Even in that case, you could just be mapping smaller sprites together and dealing with them off screen... but you can not draw them once they're outside the screen rect.

  • You could also just script it with python.

    import random

    random.seed()

    print random.randint(1,10)

  • Hey all. I'm Dan. I'm 29 and I've been into games since the NES (I was like 5 or 6 when I got it).

    After playing Mario Bros. for the first time, I began to wonder how games worked. It was not long after I got the wild idea to be a games developer. Of course, I pretty much do it as a hobby, one I don't get to do all that much (sadly). I'd say I first cut my teeth on a C64 a friend gave me. BASIC was my first language (load *,8,1!)

    I got into Construct recently (2 days ago?) because a friend of mine had been sending me little demos and games he was messing with and so it piqued my interest.

    Some history about me. I'm a C++ developer mainly. I worked on the HeroEngine/Hero's Journey (http://www.heroengine.net) project for about 3.5 years. If you were at GDC 2006 or 2007 you may have met me in the Simutronics booth.

    Aside from that, I've made a few contributions to ClanLib (http://www.clanlib.org). I use ClanLib primarily when doing my own projects. Here's a screenshot of a level maker I wrote (sorry for the URL, the boards want to crop the image though).

    http://tropple.com/images/aquila.png

    For ClanLib, I created an example that is distributed with the package. It's using the frame buffer to create a flashlight or lighting effect (this exists in Construct from what I've seen).

    http://tropple.com/images/canvas.png

    The last thing I was working on after that map editor was network programming for games (RakNet mostly). So far, I've taken a good deal of interest in the PodSixNet demos by scidave and Python scripting in general (I did often worked with Lua prior, so I'm toying with Python now, which is fun).

    Thus far, my goal with Construct is to provide a network layer for a game my friend is making. Nothing fancy, we'd just like to kill monsters together.

    My day job is IT. Oddly, for a technician, I also do scripting and coding for my company's internal website and applications. So one day I build computers, the next day I'm writing database reports with PHP/AJAX/SQL.

    I'm married, have a daughter, and my second child should be here any day now I guess my real pride and joy is family.

    I'm also into cars (*sigh* I recently sold my GTO though).

    Thanks for listening all.