Fimbul's Forum Posts

  • I don't get what you mean either, ASHLEY.

    With intel's i3/i5/i7 series, all you have to do is go into the bios and select PCI EXPRESS GRAPHICS, that will completely disable the integrated H55 chipset, right? Cause otherwise gamers would be furious and flocking to AMD since intel would be gimping their system.

    Either I'm missing something, or you misunderstood the OP (hint: he's not talking about SLI or Crossfire).

    My advice is go for AMD graphics card and not nVidia, Your choice

    My advice is the opposite, go with nVidia: AMD suffered from poor drivers in the past, especially in regards to OpenGL (which is what makes WebGL work).

    • License changes from "Per Project" to "Per Developer". Makes more sense for this category, buy once and use in any projects you're developing forever.
    • Max price $5 USD. Current plugins are in the £15 - £20 range which we are not comfortable with. This is a significant % of the cost of a Construct 2 License. We're happy to allow plugins for a higher price than $5 USD but only with special permission and if we think it's justified. We also don't want potential customers for Construct 2 browsing our store and thinking that they will be locked into or tricked into having to buy expensive plugins once they own a license.

    Those are massively discouraging words. I thought the store was supposed to be a viable way to generate income... there are so few coders in the community, is a developer's work really that cheap? Seriously, did Scirra forget Tigerworks already? Making addons is hard work!

    Let's explore the differences between asset and addon creators:

    • Audience:
      • Addon: Limited to construct 2 owners, since addons don't work anywhere else
      • Asset: Unrestricted. Addons work with all game creation software (MMF,GM,Unity,GameSalad,etc), as well as custom engines.
    • Skillset:
      • Addon: Must know how to program (which technically means you don't even need construct). Must learn the SDK. Work produced is only applicable to C2 and doesn't work anywhere else.
      • Asset: Can recycle your old work, as well as sell said work in many other asset stores.
    • Price:
      • Addon: Maximum price is $5 (and that's probably before scirra's and payment processor's cut). A single chargeback eats the profits of at least three sales.
      • Asset: Unrestricted pricing.
    • License:
      • Addon: Per developer instead of per project. This means each plugin can only be sold to a user once. Depends on a steady flow of new users to remain profitable.
      • Asset: Per project instead of per developer. A user can potentially buy as many licenses as he/she has projects.
    • Support:
      • Addon: Breaking changes means new versions have to be tested for compatibility and quickly fixed, or else you'll get a swarm of angry users and a reputation hit.
      • Asset: Once uploaded, never has to be changed. Files are all but guaranteed to continue working forever. "Conversion" permission means the user never has to worry about files becoming obsolete or incompatible.
    • De-Listing:
      • Addon: Can be de-listed if scirra makes a similar, official version - all your work goes to the trash. Official versions will most likely work better than your addon version, since the SDK is incapable of many things official addons can do (such as spawning custom interfaces in the IDE and modifying engine code both at edittime and runtime).
      • Asset: As long as your work is original, it will not be de-listed, even if the art pack included with construct 2 is updated to include a functionally-similar piece.

    The only saving grace is that addons are massively more reusable - a feature never gets stale, whereas art/music seen repeatedly across games screams "unoriginal". This benefit is negated by having per-developer licenses.

    In the near future, with modularity, addon developers will also have to face modules as competition. Modules will probably be more desirable, since they're accepted in the arcade and suffer less from breaking changes.

    So let's make a quick calculation: a person working full-time for minimum wage in the US makes around $290/week. In order to make that much selling addons, that person would have to sell 58 licenses per week (this doesn't take into account Scirra's cut). Is that viable? I don't think so. Even if it is, one can probably make more money by selling javascript code in other stores (i.e. codecanyon).

    Current plugins are in the £15 - £20 range which we are not comfortable with. This is a significant % of the cost of a Construct 2 License.

    Why aren't you comfortable with that? Look at the unity asset store - scripting section. Those prices are quite hefty, yet I don't think a user looks at that and thinks "gee, I'll have to waste a lot of money buying all of those", instead they look at it and think "wow, this is so flexible! Look at the possibilities!".

    I've said in the past, we need an editor SDK (look at what unity can do) as well as a more powerful runtime SDK to make construct more extensible, but with that statement it appears you think all (of most) functionality should be out-of-the-box...? That the more addons exist, the less a user will be inclined to buy construct? I don't agree with that viewpoint at all.

    The only way I see to work with a $5 per-dev-license would be to flood the store with single-purpose plugins that can be coded in an hour or less.

    Now, I know that many developers have an inflated sense of what their plugins are actually worth (I'm not going to point fingers, but really, look at the current offerings in the store...). However, keep in mind there are IMHO only two sensible approaches:

    • Either let the market self-regulate, in which case competition and the rating system will ensure that those plugins wither and die (albeit generating some angry users)
    • Or price items yourself. I supported this approach in the past and continue to support it.

    Keep in mind the primary goal, above all else, should be to maximize profit for content creators (as with any store), not to garner more customers for construct - that's a secondary benefit stemming from giving potential users a multitude of options. Putting that goal before content creator's income is the kind of conflict of interest that makes me think maybe an unofficial construct store would have been a better option.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Indeed a popular request, and one that I stand behind.

    See my topic about it here.

  • > I think that something happened in the latest versions of C2. I don't remember seeing this problem before, at least around the time that the lights-shadows system was introduced. I might be mistaken though.

    >

    The plugin has always had this limitation. So long as you have more than one light, you'll end up with incorrect shadows. This is because the plugin is a shadow caster, rather than a light caster. If one light casts a shadow onto another light, said light will be in shadow. Very strange, but so far sadly unusable for me.

    What about this post from earlier in the thread? Doesn't that solve the issue? The new shader is already included.

  • My favorite game of all time, as a gamer, is Fallout (1 or 2, doesn't matter).

    Tactic's combat wasn't all that bad, though.

    I'm a top-tier backer with Wasteland 2 - they have many people of the original team (you should recognize Brian Fargo). Finally after all those years I'm getting my fix!

    The funny thing is, even though I adore Fallout (1&2), and have spent many playthroughs exploring every corner and every little bit of dialogue (even going as far as digging the conversation files to look for inaccessible branches - yeah I went that far) of that game, it's not a game I'd find fun to create. As a developer, I don't particularly enjoy the thing - worldbuilding and story are much better experienced than created (some people have a complete opposite view, and I'm glad!)

    As a dev, I much prefer Dwarf Fortress.

  • I think the chrome audio issue was a sort of honest mistake from scirra (using a beta feature of chrome in a good chunck of versions), but even then I still think relying on chromium devellopers not breaking things is an issue.

    You have to count the good in with the bad, though. Yes the proprietary chrome audio api was an issue, but many other things were not (such as webGL, which eventually got adopted in IE and Android).

    Also WebRTC was implemented right on time, if scirra had chosen to implement multiplayer early, with the first draft of websockets (which included UDP) or DataChannels, we'd have a problem today, but fortunately Ashley chose wisely.

    With node webkit [...] Crosswalk [...] cocoonJS [...] awesomium

    Yeah, wrappers have dropped the ball recently. CocoonJS appears to be the only game-oriented wrapper, I think webkit is geared towards application developers, otherwise they'd cut many unnecessary things to reduce the overhead.

    Intel apparently worked out better, though.

    you should be able to convert them on your side

    You are able to convert c2 projects to work with many wrappers, but it's a bit of a pain. Many users have done so in the past. Construct's exporters just abstract away the conversion process.

    we are adding yet another third party over that,

    I absolutely get (and agree with) what you're saying, but keep in mind the intention is never to leave those wrappers permanently. Ashley is intent on cutting every proprietary or third-party tech possible (jQuery used to be a c2 dependency).

    The problem is that, outside the browser, our options suck. The sudden appearance of HTML5 exporters on competitors (MMF, GM, Unity, etc) won't change much, since those competitors have their own native exporters as well, which in turn tends to make HTML5 a second-class citizen.

    We all know the solution: make a first-party native exporter. But as Ashley stated multiple times before, that's not going to happen: maintaining multiple codebases is exponentially more difficult, and will slow down development a lot (and fast iterations are one of the major selling points! I don't think there's a single person in the forums unhappy with the pace of development at Scirra). If we had a bigger userbase, a commercial exporter could be viable - the XML format is pretty easy to work with, even if it has its issues - although past actions by Scirra have shown they don't exactly welcome this approach. Keep in mind a native exporter would break all plugins, requiring them to be written in said exporter's language (a garbage requirement IMHO).

    Personally, I'd like to see development move in the opposite direction: move the editor itself from C# to HTML5, so we could extend it a bit more easily. The same arguments apply in support of my thinking: less dependency on third parties, less vendor lock-in, multiplatform support, better consistency between edittime and runtime. Note that I'm not talking about a browser-IDE or cloud-editor like Impactjs' Weltmeister, but a full-on desktop javascript-based application such as Brackets.

  • Communicating with APIs in Construct is very easy. Even if it weren't, you can still use the plugin SDK (which is in javascript) and make a plugin to do the heavy lifting for you.

    The problem with construct is that canvas video is sometimes inconsistent (i.e. delays when pausing, little control over buffering, FPS drops depending on the platform/device, though you should be fine with chrome/firefox), and the video plugin abstracts away many of the nuts and bolts, which can be a problem in some specific circumstances.

    Besides, I don't know what you want to use the backend calls for, but I'm betting it has to do with appending relevant information to the video and/or creating a "choose your own adventure" type game. In that case, keep in mind that construct has very poor interface building options, and it's even worse with manipulating the DOM.

    Unless you need LOTS of interactivity in your video (i.e. a custom slideshow or a virtual class), I'd say simple jQuery does the trick better.

  • It's too bad you can't do something like this Set text Function.Param(0) | "Placeholder"

    But instead have to do this Set text to Function.Param(0)?Function.param(0) : "Placeholder"

    It's even worse in javascript. You have to do:

    (Function != undefined && Function.param != undefined && Function.param[0] != undefined)?Function.param[0]:"Placeholder"[/code:167kpfnq]
because undefineds don't "cascade". If your function is undefined, then trying to access "param" will result in an error, since "undefined" doesn't have a "param" attribute. The logical thing would be that a non-existant attribute of a non-existant object would be undefined, but browsers disagree.

    Fimbul

    Soo my Interface is just a dump of free stuff? Well thank you

    It's just like you guys mentioned. The liscence of the font i used allows commercial-purpose for graphics texts etc. So technically it is okay (besides including it in the package) to use it for selling graphics, which it just are. I also see heaps of flaticon-icons already, so that there won't be a single Interface that could be 100%secure

    I'm sorry Beaverlicious, I thought you were reselling a free font separately! I see now that you're using it as part of your work. Forgive me for my confusion!

    In that case, I agree with you: I don't think you're in violation of anything. If the font you used has a license that allows you to use it for other projects, including commercial ones, and also allows you to redistribute it as part of your project, you're in the clear. The only thing you can't do is resell the font by itself, and you're not doing that - you're using the font as part of some work that you did - the font is fulfilling the exact purpose it was designed for, the fact that you need to redistribute it is a mere technicality.

    However, examining the contract linked by shinkan:

    [quote:2pa3mwih]1.4: If the Fonts are free, you may distribute the Fonts within the same company or household, provided this license agreement is included.

    That could be a problem.

    [quote:2pa3mwih]2.4: Embedding of the Fonts in documents (e.g. PDF files) is permitted for viewing and printing, but not for editing. If someone at a remote location wants to edit a document which contains embedded Fonts, they must purchase their own license. Internal corporate documents with embedded Fonts may of course be edited on licensed workstations.

    So you can't make editable content with that font, unless of course all your customers become licensed users of said font by purchasing it for the incredibly steep price of free (that was sarcasm by the way, their agreement is dumb).

    [quote:2pa3mwih]2.5: You may not rent, lease, sub-license, distribute, disseminate, give away or lend the Fonts. You may permanently transfer the Fonts provided the recipient accepts the terms of this agreement, and if you delete all your copies of the Fonts.

    This kills you. You can't use the fonts at all in that manner! They don't even make concessions for free fonts! Might want to contact them and see if they can alter their agreement, but unless they do so, you cannot include the font files, just the PNGs generated with it.

    An common solution seen in many sites is to just not include the font, and add a README.TXT or FONTS.TXT including the links to where you can download the fonts yourself. This frees you from any liabilities and makes your content suddenly legal, since photoshop doesn't pack the fonts with the PSD (unless you tell it to).

    I foresee some issues with templates using third party plugs at some point.

    The license on those is already somewhat sketchy.

    Let's wait for the sellers agreement to clarify those issues.

    Besides templates, we also have issues with plugins that depend on other plugins. Also, while the obvious solution is to go "well duh, the guy has to get a license for the plugin if he wants to use the template commercially, otherwise he's fine!", this has the problem of how exactly is the buyer supposed to get the extension since the capx doesn't include it? Also the seller of the template can't just pack it in, since that would constitute piracy.

    Right now I see three alternatives:

    • Templates cannot include third-party for-profit plugins: this is not a real solution to anything, and is incredibly dumb.
    • If licenses are sold separately: potential buyers will only be able to open the template if they have the required plugin (which they must buy). This has two possible outcomes:
      • Either we need a dependency checker, preventing the buyer from purchasing the pack unless he already has all required licenses.
      • Or the sellers must add disclaimer informing buyers that they need to purchase other licenses separately - I foresee a lot of complaints
    • If licenses can be bundled:
      • Either the author of the template must purchase one license of the plugin for each sale (which violates the no-transfer clause of the current buyers license). The template author would need to arrange with the plugin author for some other licensing scheme. This would have to be done outside the scirra store, since scirra's license wouldn't allow that.
      • Or Tom creates the bundles himself: a ton of work, and major delays for template sellers
    • A "Template" license. Obviously files that opt for a template license can't also have an exclusive license (since the "exclusive" aspect wouldn't preclude it from being used in templates). Templates that adopt third-party for-profit plugins can still opt for exclusive licenses, but obviously that doesn't include the plugins as part of the exclusivity deal. I like this option best - it even allows for infinitely deep templates within templates

  • Just check the syntax of ternary operators

    Condition?valueIfTrue:valueIfFalse

    so if you want to nest ternary operators, you can use parenthesis:

    Condition?(ConditionIfTrue?valueIfTrue:valueIfFalse):(ConditionIfFalse?valueIfTrue:valueIfFalse)

    and so on and so forth. Keep in mind you can also nest in the "condition" parameter, and you don't have to nest in both value (true/false).

    if (Touch.Y=gold)
gnew=Touch.Y-(gold*gspeed)
else if (Touch.Y>gold)
gnew=Touch.Y+(gold*gspeed)+a
else if (Touch.Y<gold)
gnew=Touch.Y+(gold*gspeed)+b
else 
gnew=Touch.Y+(gold*gspeed)+c[/code:1kd3g4vc]
can be written (just to make it easier to visualise) as
[code:1kd3g4vc](Touch.Y=gold)?
	true= gnew=Touch.Y-(gold*gspeed)
	false=(Touch.Y>gold)?
		true= gnew=Touch.Y+(gold*gspeed)+a
		false=(Touch.Y<gold)?
			true= gnew=Touch.Y+(gold*gspeed)+b
			false= gnew=Touch.Y+(gold*gspeed)+c[/code:1kd3g4vc]
which then becomes:
[code:1kd3g4vc]gnew=(Touch.Y=gold)?(gnew=Touch.Y-(gold*gspeed)):((Touch.Y>gold)?(Touch.Y+(gold*gspeed)+a):((Touch.Y<gold)?(Touch.Y+(gold*gspeed)+b):(Touch.Y+(gold*gspeed)+c)))[/code:1kd3g4vc]

As you can see, this is a nightmare to write, and outright impossible to understand. Avoid nesting ternary operators if at all possible.

    This is serious violation of this font license and Scirra Store Terms and Conditions.

    You should remove that file from your packaged immediately and be glad that store is not public yet and no one bought your assets.

    Indeed.

    We don't have the sellers agreement yet, but I'm sure it will include a clause stating that you, the seller, must hold all the rights to the work in question (which by the way you, Beaverlicious, do not).

    Even if that were not the case, this store isn't supposed to become a dump for free content! Not only does that practice reek of dishonesty (even if not wholly illegal), but leads to disgruntled buyers, when they find out that the assets they purchased are available elsewhere for free.

    Also, what happens when a buyer buys the exclusive license, expecting the content to be taken off, then finds it available elsewhere?

  • 1. Cloud save to Google Play, iCloud, and Steam.

    Similar to the auto-save dropbox integration or do you mean something else? Maybe you mean exporting directly to steam? That's unlikely to ever be implemented. I don't think it's even allowed.

    A simpler way to create a grid scrolling game like Zelda or Pokemon. The current tilemaps don't provide that much in terms of walk permissions or front-back depth.

    You might see some answers to those problems with the new scirra asset store. Those requests are pretty common and also pretty easy to do via third-party addons.

    Actions over time. Instead of just set position to x,y, I'd like something like glide to x,y over z seconds. It would make designing the UI a lot easier. Even Scratch had stuff like that.

    Check the "LERP" system action, it does almost exactly that. It takes three arguments, FROM, TO, FRACTION.

    So to make a "glide to x/y" you can do x=lerp(currentX,destinationX,timeElapsed/totalTime) and same for Y.

    Nodewebkit seems to work great as an exporter without any noticeable problems. Or am I wrong?

    Yep. The exporter has a ~40Mb overhead, generates a ton of temp files, doesn't respect flags properly (like ignoreGpuBlacklist), frequently messes/breaks effects and doesn't work (or works but is unusable, or works but requires you to recompile) on linux or mac. It's pretty garbage, unless things have changed in the past few months.

  • If I may suggest something, and I think it has been suggested before, it would be to be able to do something similar to custom behaviours using events, it is not a nessecary thing, but being able to define your ennemies with behaviours that you do in events could be a nice addition for some people.

    Sounds a lot like "modularity". People used to suggest this feature under the name "widgets" as well.

    people think the html5 is the added value, while it is the product.

    I think you hit the nail on the head with this sentence.

    By the way Tom, I don't think the product page (AKA single) works in the current layout.

    Compare this item from the scirra store with this item from codecanyon

    I guess we don't need full HTML access, but surely BBCode (like we have here in the forums) would be fine...? Also surely we should be able to iFrame (or directly embed) a c2 game demo directly in the preview page?

    There are also too many "Add to basket" buttons, the description box is too cramped, and the "single project license" box obscures part of the image.

    IMHO, to un-cramp the single, both the FAQ and Package Content should be moved into their own tabs on the product page.