lucid's Forum Posts

  • I think my previous replies still explain what all the fuss is about for most people tokinsom, but I just now realized a possible reason why you would think it was easier not use them. when you made minitroid, and possibly other games, you had a clever level editor so it was much more convenient to have the level editor load the level, create a generic object and assign it all the values it needed right then and there. That makes sense why you'd find it a hassle in that type of situation.

  • on bullet collision with enemy

    (subevent)Enemy.value=Goomba

    ------ Do anything a goomba would

    (subevent)Enemy.value=Koopa

    ------Do anything a koopa wouldquote]

    on bullet collision with koopa

    ------do something with koopa

    on bullet collision with goomba

    -do some goomba thingquote]

    This single enemy object could contain every behavior that could be activated/deactivated depending on what the enemy variable is. Animations could be set like

    -GOOMBA_Walk

    -GOOMBA_Squished

    -KOOPA_Walk

    -KOOPA_Squishedquote]

    enemy - play animation - enemy.value&"_Walk"quote]

    enemy - play animation - "walk"quote]

    Then when the enemy dies? More sub-eventsquote]

    +Enemy dies

    --- do something for any enemy

    (subevent) If it's a koopa

       --- do this

    (subevent) If it's a goomba

       --- do thatquote]

    enemy dies

    ---do something

    koopa dies

    ---do this

    gooma dies

    ---do thisquote]

    find that easier and more convenient than making totally different objects and putting them in the same family. Hm.. it's not like you must like families, but personally, in all the above examples, the family version seems much cleaner and readable. Also the icons make it much easier to read the event sheet as well.

    edit: also to emulate multiple families on a single object would make things a little messier still

    like Koopa could be in the 'enemy' family and the 'ground creature' family and the 'all character' family

  • I understand that you don't need more objects, but having multiple objects is visually and conceptually useful

    I this assuming 'badvulture' and 'evilsmiley' are in the 'enemy' family

    every tick

    --badvulture - move slow

    --evil smiley - cackle maniacly

    on bullet collides with enemy

    --destroy enemy

    i think that's how it should read, and making the events was effortless. the most elegant equivalent without families either involve some naming convention, private variable comparing, or some clever functions, or just rote memorization of animation names and such.

    I don't want to have to call functions, or use naming tricks, or remember what animation and what logic goes to who. I want the event sheet to have different icons of different enemies, or the single family icon, so it's easy to see what actions apply to who without reading anything. I want enemies to be able to collide with eachother, without having to check a name or a PV and some other workaround for multi-objecttype picking. And conceptually, I want the actual eventing process to align with what's going on in my head, which is separate types that share some common functions.

    it sounds like you're saying there's an advantage for not using them? is this to save memory?

  • I agree with telles0808. even though it's possible to do as you said with single objects, but what about objects with animations? that would definitely be very annoying without families. or if you wanted totally different logic for each enemy, or ui element.

    something simple like:

    On playerprojectile collides with Enemy -

    -----subtract (playerprojectile.strength-Enemy.defense) from variable Enemy.energy

    where 'playprojectile' can be all the projectile in the game, from arrows to lasers to machine gun pellets. 'Enemy' can be everything from walking soldiers to flying birds, to turrets. If your game has 30 projectile weapons types, and 50 enemies. without families that would be quite an annoying task to copy paste those to each enemy, and unthinkable to do some sort of animation frame based family equivalent. with families it takes a few seconds.

    simple functions like enabling and disabling, creation and destruction, positioning can apply across a broad range of objects. The readability improvements alone make it worth it, but it can shorten the cap length drastically, and certain tasks that would be annoying or infeasible with some other workaround are as effortless as any single object logic.

  • I don't know where the mess comes in. The use would be that if you want physics effects, like physics controlled hair, or antenna, or the as the OP asked, the ability to push or drag physics objects without having to make your character controlled by physics, then you can have both. If you want a fully physics controlled character, then platform movement doesn't enter the picture

  • Python has its special cc rules and quirks to get used to, and its less limited than events. you should be able to do everything you can with events and more.

  • You can combine physics with other behaviors, just set physics to immovable object, and expect the object to behave as if it has infinite inertia.

  • yes, you'd have to make a runtime for the plugins, but what I'm saying is even just sprite with only position actions and expressions and box collision, text, and touch, 2 or 3 basic system actions, and no behaviors would be useful. that was about what I made in android last time, so I definitely know it's possible and of a manageable workload. I don't mean to make an exporter that gives you complete ready to use files, but gives you files you can load and have ready to compile in the target language, like a cap translator.

    the programmer would be required to write a Drawing function for the runtime, and for each plugin, and set up the main loop where the bulk of this copy pasting finding replacing would occur.

    you would also specify how something included in the cap file would have to be included in the target language. You would have to create equivalent functions for any ace you will use in your cap. If you didn't care about time delta, you could ignore it. if you needed platform really badly, then you could include only the functions you needed.

    I could do alot with just sprite, and no behaviors, and I'd love to have a basic tool like that for android or iphone running natively. I have a few ideas of how the most of the translation process could be generalized for use with different languages, and automated with an app.

    Also, it was reading that blog post that gave me the idea. and then after having a look through C2's files, I think it's doable. obviously Ashley knows what he's talking about, and making a complete runtime is infeasible for pretty much anyone but scirra and html5 right now, but a very limited runtime could still be useful, just like c2 was in it's infancy.

    it could also be opensourced for people to do what they wanted/could, and if there were even half as many devs trying their hand at it as there are making plugins with js, but just adding features from c2 or specific behaviors, or objects new or old. maybe with some time, a specific platform could even get a respectable feature set.

    Edit:

    Hmm... interesting idea. What about exporting to something like allegro or SDL? Could then C2 hit Windows, Mac, Linux, iOS and Android with one exporter? Or are there too many differences between the platforms even using a framework like those?I don't know about those specifically, but I would guess most languages, aside from scripting languages, would need at least some platform specific code,

  • right, exactly, even without an edk, I imagine you could just make a translator from event sheet xml to equivalent functions in the target language. You could even limit the workload by establishing a set of bare bones ACE like Start of Layout, Always, sprite object with movement, resizing, touch commands, and text object with the same commands plus set text. and it could still be useful in many contexts. you could even ignore the edittime, and use the current one (which wouldn't give you any of the benefits of the target platform). Just using the xml and either a parser, or a find replace script, possibly several steps, but doing something like I did with CC and android, I'd imagine you could get much further given how well structured the c2 capfiles are. if/when my schedule eventually opens up, I'd like to try it, at least as an experiment.

  • I would say that's asking for trouble if you're trying to find loopholes in copyright law. Might not get noticed if the game isn't played much, but when you have as much money as the music industry, you can blur all sorts of legal lines

  • In the "Why HTML5?" thread in the C2 forums, the EDK was mentioned a few times. For those that don't already know, the EDK is the Exporter Development Kit that Ashley has mentioned eventually wanting to create for C2. I have no idea of the timeframe for it, I imagine it's quite a while away -

    but out of curiosity how many out there actually plan on using the EDK when it's released? I personally want to try to make an Android runtime. I dabbled with Android development(java) for a short time, and I enjoyed it. It was very straightforward, and easy to find example code online for anything you needed to learn how to do.

    At one point, I had made some android functional equivalents to some basic construct classic system and sprite actions, so you could export a very basic cap to text(simple sprite actions like changing angle, position, and dimensions) do a few find and replaces in a text editor, and it was working android code. It was rewarding work, and I imagine working with the EDK would involve alot of the same things. Once I had time to start on a runtime though, I'd definitely want to at least try to assemble a team.

    How many other developers out there plan on trying to do something with the EDK? alone or in a team? open-source? commercial? what platform? etc

  • I think a good move for Scirra is to release the EDK first, this way they can let users work on the exporters and they can worry about what they think it's more important.I'm not sure how close what Ashley's currently working on is to an EDK. For all we know, writing the edk may be as much work as writing an exporter. But if it is more like the combined time it takes to add 2 or 3 major features like local variables, grouping, and families - then I don't about whether it's a good move for scirra, but personally that'd be the feature I'd most look forward to.

    Ashley is probably weighing the potential userbase for the EDK into how much of a priority it is. I know of at least a few people in the forum who are experienced enough with coding they could make a runtime, and there's probably well over 200,000 construct downloads between classic and 2, so there's bound to be many more out there, but there aren't many users who've mentioned in the forum they'd like to use the edk, just the desire for the runtimes people would make with it.

    I personally would like to start such a project with android, and hopefully recruit a team. I've worked with android development before, and I enjoyed working with it, and it'd be an awesome platform to be able to make native apps for with c2. I'd be curious to know if there was anyone else who would want to contribute to such a project?

  • > ...............

    If there was a possibility of exporting a capx to Classic, there would be no problem and all problems would cease to exist.

    oh yeah, forgot to respond to this. classic already exists, and it has the exact same type of event system as c2, it would make no sense to do this. C2 is a vastly superior, albeit less complete(at this time) product. just messing around in the ide, everything works much more smoothly, and c2 improves on everything that was wrong with CC. Things like the file format, ide responsiveness, and ide stability, and greater extendability.

    However, from your statement, and many others like it, I think Construct Classic's brokenness is hugely overestimated in the C2 community(the part that doesn't also use CC). Obviously it had enough problems at it's core that Ashley thought it better to begin anew, rather than continue to iterate a flawed codebase. This is something to keep in mind, because it does have it's quirks, and bugs. Transitions don't work well(not sure if C2 has transitions), so you don't use transitions. Sometimes the IDE starts up with a blank layout, and you have to doubleclick your event sheet in the properties pane to bring it back into view before you begin. You have to save frequently, because the IDE is known to crash now and then.

    However, that being said, it's not so broken it's unusable, and the runtime(which is what really matters in the end) is stable. You can make games with it, that work on everyone's PC, run ridiculously fast(seriously, it's fast), and look as good as is possible in 2d on a pc.   I personally have some plans for webbased projects in the future, and Construct Classic, even in it's quirky state gives me enough confidence in Scirra that I have no doubt c2 is the best way to make web games(and eventually - any games). But right now, I'm working on projects that require that exe speed, so I use construct classic.

    The skills for both are interchangeable, and we're one big happy community, I really don't see why the "when will there be an exe?" crowd don't just buy the C2 license now, so they have it when they need it, and to support scirra since Construct Classic is free, and use CC in the meantime.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • HTML5 needs... gaming, game-pad support ( I have already seen this, but this just started ), much better full screen ( also know this is being worked on )

    it sounds like most of the problems you have are indeed being worked on, and this is just what you've heard of. you're not the only one who thinks the platform is incomplete. html5 isn't even done yet. I would say everything's moving amazingly quickly, as everything always does in the computer world. I mean, I didn't even hear about webgl until fairly recently, and now it's already supported on the chrome beta for android. adobe abandoned flash because of html5 and js(there are flash games on steam). There are plenty of big players who are looking to make it faster, better, etc.

    as far as very old machines? even construct classic requires dx9, and though there were a few people complaining about that, almost anyone can run a construct classic game. the best supporters of older machines in the industry as far as AAA titles go I'd say would be valve. and you'll notice some of their newer games, like portal 2 and left for dead 2(which was released a little over 2 years ago) don't run on older machines, at least not at any playable framerate. valve is known for their games having reasonable system requirements.

    ow long does this seem it's going to take?

    I don't think any of us know, probably a little while. my own personal pessimistic prediction is that within two years, some combination of these web technologies will be comparable to flash speeds, but I think 1 year is closer to the mark. also, I can't speak for scirra, but I'd think within 5 years, work on the next exporter would be begun, or the edk, or the web platform will be approaching the needed maturity.   if you need exe's support now, honestly, use construct classic. It's got your working audio, game pad support, full screen, exe, etc. especially if you're planning to develop a game so quickly that you're concerned about waiting a year.   it's already been stated that native exporters and/or the edk are in the cards. C2, js, and html5 are being worked on hard by people that are probably much more diligent than ourselves. it's not going to arrive faster by being upset it's not here yet. Honestly, cc is probably your best bet, or if you want to sacrifice alot of ease of use for more crossplatform compatibility, Unity is your best bet.

  • theres a few reasons why this happens, none of them make sense, so I won't list them right now. suffice it to say, this will happen sometimes.

    the solution is simple though, in the project bar(on your screenshot, it's on the bottom right), expand the application 1, then double click the event sheet, and the layout. usually the first one you double click will restore sanity