Fimbul's Forum Posts

  • It breaks my heart that I don't have time to update this behavior... I have many features planned for this, including:

    • strafing - moving sideways
    • dead reckoning - returns the coordinates of where you'll be X miliseconds from now or where you were X miliseconds ago
    • multiple engines - you can have multiple engines with varying degrees of power in different locations with different angles
    • NPC - a version that can be automated and doesn't rely on key presses
    • Thrust [to/through] coordinate - Make the npc fly to/through a coordinate

    ...all working in partial states in different construct versions. I wish I could say "I'm going to implement them all soon and there will be a big update!" but that's just not true. I'm stuck with humongous projects and if my life continues in it's current path (which I hope it does), I'll be busy for the next 2 years at least!

    I love developing plugins for construct 2, and I even had some stuff relating to stream loading tile-based maps from a remote server, inventory management, and was working on a multi-level variable parser plugin with jquery syntax (example: object.vars("status.attributes.health")), but then the market exploded with requests for consulting and projects, and a construct update broke nearly everything I had. It's probably trivial to fix, but alas there is no time.

    Meanwhile, my huge gigantic ambitious project (that is my inspiration for developing those plugins) is on hiatus due to multiplayer not supporting UDP (yet) and my complete lack of free time.

    In any case, thanks for all the feedback guys! I hope I can squeeze some time eventually to at least fix the bugs! It's nice to see people still derive value from my work!

  • How come most of your posts are "urgent help"? I don't see what's so urgent here.

  • In this special case, if you don't know how to do it already, you aren't suited to do it.

    If you still want to do it, post a paid offer in the "help wanted" section. Since you need a license to use SQL server, and such license is quite expensive, I'm guessing you have a budget for this project. In that case, you're better off paying someone to help you, since a MMORPG is a HUGE undertaking.

  • No one's bashing construct 2 or HTML5.

    Construct 2 is the best game making tool out there, with the best workflow, which is not to say it's perfect.

    HTML5 is really good now, and can deliver some impressive results, though we aren't there yet in terms of portability. There are many limitations to what can be accomplished, even in a beefy desktop running a modern browser.

    Mobile, however, isn't there yet. You can't make anything but simple puzzle games in there - meanwhile, other engines with native exporters perform a lot better. Sure, they aren't as capable and working with them is a convoluted mess, but the end product is often more performant.

    I don't know why people are getting all defensive. I love construct 2 and scirra, but we're not there yet in terms of multiplayer and semi-professional mobile development. Blame it all on HTML5 and phone manufacturers (especially apple - I mean, their stuff costs double the price of an android/htc/blackberry/whatever with HIGHER specs and even with all that money they still can't get their act together? I honestly don't know why people buy their stuff).

    In regards to mobile HTML5, Blackberry is putting a lot more effort into it than everyone else, and I'd recommend developers stick with them - the environment they're creating for us seems far less toxic than apple or microsoft's alternatives. Android is pretty okay, Google is very competent and mobile chrome is great. Firefox mobile shows promise as well, especially if you want to focus corporate, low-end or edu.

    Do notice that Ashley can't do anything about any of this. The strategy of integrating third party exporters worked to some extent (in that we now know which technologies suck and which show some promise), and shows the goodwill Ashley has in supporting us in that area, and how he'll do everything he can to make it better (compare that to other game making tools, which just don't care, and spend years with updates that amount to little more than bug fixes. Konidias will know which one I have in mind specifically). The most recent versions appear to be focusing more on the core product, with new features to help the core engine, and that's a relief for me.

    It says a lot that, even when working in large projects, ALL THE ROADBLOCKS I've encountered so far, NO EXCEPTIONS, have been in regards to HTML5. It was NEVER construct2's fault, and on the few times construct didn't do something I wanted it to do, I fired up my development kit and made a plugin/extension to fix it.

    I'll end up by agreeing with Konidias, though I'll disagree with the title - this is not "the sad truth of construct 2", but "the sorry state of HTML5 right now, especially in mobile".

  • Guys, be aware I'm talking about REAL TIME multiplayer.

    It's perfectly possible to make multiplayer games right now, as long as they aren't REAL TIME (as in, dependent on fast reaction times or twitch skills). MMOs are also perfectly doable.

    Adding multiplayer to the ghost shooter demo, as an example, is not viable. It gets very laggy very fast.

    Let me give you an example (which is not scientific at all): a sustained 2% packet loss over a 50ms connection gigabit ethernet (latency and packetloss simulated) desyncs the game by more than 1 second per 5 minutes.

    In the same conditions, under UDP, there is no loss or desync, the game runs perfectly.

    Game was tested using raw tcp/udp and multimedia fusion 2. Server powered by node.js in both modes as well. I would imagine construct would fare even worse, due to websocket's overhead.

  • I agree with I find it hard to understand how an automatic "save" would benefit large projects, especially in the case of RPGs which have levels powered by a custom engine and loaded externally.

  • Modal windows? That is, if you have window A and it spawns modal window B, you cannot interact with window A until B is dealt with. Similarly, modal window B might spawn modal window C, and you cannot interact with B or A until you deal with C

  • I'm not convinced. I really dislike the idea of having two products ? what if I want to use both 2-D and 3-D together? It also depends just how much 3-D capability would be incorporated ? if it's just simple displaying of a model and maybe some basic lighting, There's no reason to redo anything from scratch when it can be made as a plugin instead. Making two products would be far, far more work for Ashley for no reason.

    I'm also not sure how it would be better. The only thing I can think of that there might be a potential issue with is panning around a 3-D world in the layout editor. I can imagine that could be worked around elegantly by having a 3-D camera that's separate from the normal 2-D one that the user can switch between.

    I don't want a separate product either, but I'm convinced that adding 3D support onto construct2 would be a nightmare that would delay other (much more important) features.

    Like you said, even something simple such as panning around in the editor would require coding a separate camera and rendering engine - if you have a product that has two modes, it's basically the same as having another product.

    I get that you want to be able to use 3D stuff in normal projects, and I agree - I've wanted to do that many many times - here's an example:

    On a space game I'm working on, which is practically all 2D, one of the features is being able to choose a site on a planet to land on. Creating a 3D sphere with animated textures spinning around (simulating a planet) was a huge pain. Also, mapping mouse coordinates onto planet surface coordinates had to be done by hand using math. This would have been relatively simple to implement if C2 supported even basic 3D capabilities.

    Still, I think it would be better to have a mainly 3D product that is 2D capable than the other way around.

    Even if Ashley didn't intend to incorporate 3-D from the start, that doesn't necessarily mean that it will be difficult to implement. It might be, but you seem to have decided that it will be difficult and wouldn't succeed without knowing the underlying architecture like Ashley does.

    Yes, it does not necessarily follow that it will be hard to implement - but trust me, it will. Though only Ashley can confirm this.

    That doesn't mean a 3-D engine would generate too much garbage as well. They're not the same thing.

    I said that to illustrate how, even with a well planned feature, problems happen. A 3D engine isn't likely to generate a lot of garbage, due to such engines usually being extremely optimized, so yes I'll agree there.

    Here is a better example: most (if not all) 3D engines are meant to be used as a foundation for the rest of your engine, unlike box2d which is designed as an add-on. This means that, even if Ashley wanted to add 3D, it would need to be made in-house.

    Anyway, it's irrelevant because Ashley has said that there are no short-term plans to add 3-D, so even if it does get added eventually, it'll be quite a while until then. Unless some third-party plug-in developer makes it first.

    I don't think the chances of something good coming out of third-party plugin developers are in our favor. Look at MMF2: all those years third-party devs have been attempting to add 3D via extensions, with limited success (and poor quality overall - their best results are stuff like mode7).

    Maybe the shader guys have more luck.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Definitely willing to pay for it, but I cannot discuss price.

    Would I be willing to pay more than, say, UDK? Yes, if the quality is there.

    If it's able to produce something like this (that is, a little bit more basic than unity):

    <img src="http://1.bp.blogspot.com/-VPgn3SUa9rY/Tz36PnV-i3I/AAAAAAAAERw/qNK0xm97cdY/s1600/Download+PC+Games+Alien+Breed+-+Impact+2010+For+Free+4.jpg" border="0" />

    then I'd definitely consider paying over $200 for an indie version, and over $2K for a commercial version.

    If we're talking about this

    <img src="http://img.brothersoft.com/screenshots/softimage/0/3d_games_tvmax-30029-1.jpeg" border="0" />

    or this

    <img src="http://blog.mozilla.org/labs/files/2012/04/no-comply.png" border="0" />

    then I wouldn't be willing to pay anything for it, and I would think less of construct.

    I'm not expecting the same level of detail as cryengine or UDK, of course.

  • Still, I don't want a tacked-on 3D solution, an in-house thing would be better (and perhaps the only viable alternative).

    Keep in mind construct 2 was developed with a clear intention of integrating one (or maybe more?) physics engines later, so that's why it succeeded, and yet if you read Ashley's comments, it's clear he believes Box2D generates way too much garbage. I don't know if he cleaned up the code manually or left it as is, but it probably took a ton of work - and, again, this is something he was planning when C2 development started.

    I don't think adding a 3D engine as an afterthought would be viable. I could be mistaken.

    What I'd actually like, however, is some better eventing capabilities so we could fake 3D more easily.

    Implementing isometric, for instance, is very hard, due to being unable to add methods/functions to objects (even though we can add variables), not having access to z-ordering (must do an ordered loop), etc.

  • Ashley, I think you're overestimating the complexity of 3D and underestimating the capabilities of events!

    3D maths, generally speaking (and I'm oly talking about programming logic), are simply extensions of 2D algorythms into 3D (ex. Bresenham's line, A*). Most of the truly complex stuff has to do with rendering (with a few exceptions such as gimbal locking), and that would be handled by [a theoretical 3d version of] construct.

    Besides, what's keeping the event system from being as powerful (and faster) than coding by hand? I can't think of anything that can be implemented in code and can't be implemented via events - what's stopping events anyways? Most OO stuff can be directly adopted, such as custom variable types, object variables, pointers/direct referencing, inheritance (even if prototypical inheritance like js)!

    As for modeling, it's not REALLY that hard to get into. I personally find sculpting with zBrush much easier than working pixel art with the tools available, and 2D art is only marginally better (thanks to spriter). And the results often look better, too.

    I'm not saying Scirra should jump into a new product or try to cram 3D into construct 2 - First of all, scirra is too small to run two huge projects at once. Second of all, such a product would have to be designed from scratch.

    There is demand for it, though, and I definitely think it's something worth considering for a future project.

  • Bartosh, I'm definitely interested in your project, could you post more about it?

    Here are two of the most interesting resources I've collected when working on my massive ambitious project:

    red3d.com/cwr/steer <-- steering, seeking and flocking behavior

    gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php <-- massive interview with Tarn Adams (my favorite developer), of special interest are worldgen and fluid dynamics in tile based maps.

  • Yeah, native json parsing in construct 2 is very poor. You'll need to use Rex's plugin like lemo mentioned.

    I'd love to see a jquery jyntax on an official plugin, so we could feed it a string like "player[1].vehicle.movement.speed" and it would return a value.

  • It's a planned feature.

  • Ashley, I don't get the second problem.

    If a new version of an official plugin comes out with a bug fix, then it's automatically updated. The only plugins that are bundled with the capx are the ones not present in the global list of plugins!

    When saving a project, it looks at the global construct plugins folder. If the plugin is there, it skips it (regardless of whether it's an official plugin or a third party one). If it cannot find the plugin there, or if the plugin in the project folder is different than the version in the global folder, it gets bundled.

    It's not like it's supposed to pack *ALL* plugins in the capx... In fact, it shouldn't bundle third party plugins if they're on the global folder.

    The only way to have a capx with a forced out of date plugin would be to manually copy the outdated version into the project folder.