I came across a pretty interesting licensing method recently, that being the Unreal Development Kit (UDK) license. You may already be familiar with it.

I figured it would be worth mentioning since it sounds like you guys are still surveying your options.

Bellow is a summary, followed by some thoughts on the pros and cons of the main aspects of the model. It's a little long, but I hope it'll be helpful.

In summary, the UDK is licensed like this:

* 1: The UDK development tool is closed source.

* 2: It's free to use for non-commercial purposes, for as long as you want.

* 3: You can also buy a 99$ license, which grants you the ability to sell games commercially.

In this case, as you accrue revenue from selling your game, you would pay nothing to Epic Games, up until you make your first $50,000.

After your first $50,000, you would begin paying 25% of any additional revenue to Epic Games, keeping the remaining 75% for yourself. Obviously, for Scirra's purposes that royalty threshold of $50,000 should probably be a little lower, if you want to include that aspect of the license.

I don't know how effective this kind of license model would be for Scirra, (obviously Epic Games is quite different from Scirra structurally), but it has some interesting properties.

* 1: The tool remains closed source. (Strictly speaking this is optional.)

Pros:

You don't have to worry about a nefarious third party stealing it, modifying it, repackaging it, and selling it out from underneath you, as a form of direct competition with your business. Granted, making it closed source would not protect you from such a miscreant stealing it, NOT modifying it, repackaging it, and selling it out from underneath you, as a form of direct competition with your business. This has happened even to products where the legitimate version is freeware. Though in the case of freeware, the legitimate authors don't have to worry about the bad guys undercutting their price. That threat of theft and price undercutting might be a valid reason for Scirra to consider closed source, at least initially.

Cons:

Good third party developers won't be able to help out as much, and this might slow the development of the software. This tradeoff is explained at length in Eric Raymond's well-known analysis of open source phenomena "The Cathedral and the Bazaar", available online. Additionally there will undoubtedly be some community resistance to a change from open source to closed source.

* 2: It's free to try the full version, for as long as you want, for non-commercial purposes.

Pros:

New users have no entry cost to trying out and experimenting with your software. (No monetary entry cost at least. There's still time and learning involved.) This gives new users the unusual opportunity to see first-hand how useful the fully functional software will be to them.

Because they aren�t stuck with a time-limited trial, they can learn the software at their leisure. This non-rushed atmosphere is especially welcome to people who have a strong interest in the product, but have many other obligations occupying their time, or an otherwise unpredictable schedule. In effect, the time-limited trial adds an additional (non-monetary) cost onto trying out a product, and that is the commitment to spending the next X days learning it to the best of your ability, while not daring to actually start a real project in it, on the off-chance that it's ultimately not worth it. Understandably this cripples a new user's ability to truly get a feel for using the product.

(That's not to say that time-limited trial's are all bad, but anecdotally, I wouldn't even have considered investing the time to learn UDK had it been a time-limited trial. I simply had too many other things consuming my time. As it turned out, it was a full 6 months after I downloaded it before I finally got time to work with it. And when I finally did, I was able to begin building something worth while to me, in broken patches of time over a few months, as I wasn't looking at potentially losing all my work after 30 days. )

Some users have more free time and some have less, but by and large, they all have a willingness to pay for software that they come to like and enjoy using, especially if they can make a business of it.

Cons:

If you release the software for free, there is a chance that some nefarious so-and-sos will use it to produce and sell games without buying a proper license. This is less of a problem for Epic Games, as their engine has a distinctly recognizable look to it, and I assume they also have a sizable legal staff. To my knowledge, Scirra unfortunately lacks these things, although it is conceivably possible that some kind of encrypted watermark could be included in the exported files. Though this would not be entirely tamper proof, and in the case of HTML 5 the code would be openly viewable and editable, pretty much eliminating the purpose of an embedded watermark in the code.

Again anecdotally, I myself am interested in starting a business in the near (hopefully) future, and I ran into the same kind of dilemma. I spent quite a while thinking about how I might surmount such an issue, and finally it occurred to me that doing nothing may actually have a better cost to benefit ratio than any of the other only theoretically effective solutions I considered. This is because it only takes a single person to bypass the security measures on a piece of software for it to become downloadable by anyone. If super-massive industry giants can't thwart this phenomenon, then

(A) I can't expect to do much better;

(B) all the time and effort I spend learning and perfecting the "completely-unrelated-to-my-actual-business" skill set needed to safeguard my software, could be better spent growing the functionality and value of my software; and

(C) there are oceans of people who devote all their time to reverse engineering software, and I, as a single individual, have no interest in spending an equal or greater amount of time learning how to stay a step ahead of all of them, in a futile mental arms-race which will likely only serve to make my software harder to use for my actual customers.

This is not really as bad as it sounds though. All it really means is that most honest people will be honest, most dishonest people will be dishonest, and no matter what kind of security system I add to my software, I'm not going to get the dishonest people to buy it. When you think about it, that's not really much of a revelation. On reflection, I realized that I really didn't feel too broken up about not being able to capture the dishonest-people corner of the market. Practically speaking, when you start a business, instead of asking, "Are there enough people interested in my product to support it?" you should instead ask, "Are there enough honest people interested in my product to support it?"

In Scirra's case, given the support and impressively helpful and kind nature of the community on the forums, I would guess that there are by far more than enough honest and well-meaning people to keep Scirra going as a business.

It's hard to imagine that anyone reading this is unfamiliar with Minecraft, but that is perhaps the pinnacle example of the influence honest users can bring to bear on the success of a small business with a good product. (Admittedly, Minecraft is something of an outlier, in that there is scarcely anything else quite like it, but the same can be said of an HTML 5 compliant Construct 2.)

* 3: To sell games commercially, users simply buy an inexpensive commercial license with a royalty threshold.

Cons:

(Yeah, I'm doing the pros and cons in reverse for this one.)

As a business, Scirra wouldn't necessarily begin getting buyers right at the outset of C2's development. This is because even buyers who are strongly considering buying it could hold off for quite a while as they continue working on their projects. For a massive company like Epic Games, this initial lag in sales is likely easily absorbed. For Scirra though, this could potentially be a bigger problem. Although, C1 has been free for 4 years, so Scirra might be able to stand waiting for revenue for another few months even after starting up the official C2 license model.

Pros:

That said, with people already looking to become paying early adopters, the future looks bright for Scirra indeed. As new users spend more time with C2, their ability to leverage its capabilities will increase, and it will literally become more valuable to them. However, before the value of C2 has grown on them, you might run the risk of chasing them off by requiring an upfront payment of a tool they have no practical experience with. Likewise, those with commercial games in the works will almost certainly have no problem buying a license whose cost they can expect to make back in a few sales.

Additionally, for new users who start out making games for free, the software itself will train them for as long as they wish, at whatever rate their comfortable with, until if they're persistent, they reach a point where they could actually make a commercial game, and buy a license to sell it.

The strange beauty of this system, is that since the user is in control of that entire progression, it doesn't matter how fast they learn, if they have unlimited free time, or almost no free time; once they feel they've reach the commercial-capable threshold, that is exactly the same time they will be willing to buy a commercial license. They will know the software inside and out, and they won't ever have needed to take anyone's word that someday they'll know it well enough to be a commercial developer. This is even true of user's who start out not expecting to ever make it to that level. Users who might otherwise shy away from trying to in the first place as a result of the price. It's oddly self regulating. Or more accurately, its user regulated.

Interestingly, UDK has been using this license for a while now, though they actually recently raised the royalty threshold at which sellers start paying royalties from $5,000 to the $50,000 quoted at the top of this post. That would seem to indicate that Epic Games is becoming more confident in this model.

Having said all that, (certainly more than I was expecting to when I started writing), I'm not trying to say that this is the best model for Scirra. You guys have a birds-eye view of Scirra's specific assets and limitations that I don't have. So you'll ultimately be a better judge of what looks viable, but I figured that at least presenting this as a possibility, and explaining my thoughts on it, might help to provide one more option to the pool of things to consider.

Take care.

-fisholith

If I start an app with a Python based timer "time.time()", and then log out of windows, the timer seems to stop working at the moment that I log back into windows.

Am I doing something wrong, or is this a common thing?

I've seen that

nohup python script.py &

is supposed to fix this kind of thing on some platforms, but I'm not sure if it works for windows, or for my specific problem. Also, I'm not sure what I would put in place of the "script.py" part of that code, since as far as I know, the script is built into the compiled exe, (unless "script.py" works on all scripts).

• - Overlapping shadow:

The way shadow casters and lights work is that the shadow casters essentially "paint" shadows into the light object's image. Therefore the shadows will be at the same z-order (front to back layering order) as the light casting them.

So, if you want the shadows to appear underneath all the objects, then you need to send the light object to the back of the z-ordering. If you have multiple layers, then you need the light to be either at the back of the layer with the shadow Casters, or on a layer below the shadow Casters.

(Note: To send an object to the back of the z-order, right click it and choose Order > To Back.)

• - Round shadows coming from square objects:

You have created a single barrel object, and you have placed 4 "instances" of that object in your level. You have also applied the "Shadow Caster" behavior to this one barrel object.

So far so good.

Here's where the problem arises.

You have used a custom shadow collision shape for the shadows that this one barrel object will cast, but for your barrel object, you have created two different images stored in frame 1 and frame 2 of the animation strip. Frame 1 is a circular top view of a barrel, and frame 2 is a square side view of a barrel.

If you create a custom shadow collision shape for your "Shadow_Clutter_Medium" object, it doesn't matter which frame of that object is showing, every "instance" will use that same shadow shape.

To solve this, you'll need a unique object for each shadow collision shape you want to use.

Hope that helps out.

I'm trying to reduce the CPU (and GPU) usage of an app I'm building, but without limiting the frame rate too much. I'd like to leave it at V-sync if possible, but I'm not sure how many other ways there are to tweak the app.

Strictly speaking, all I'm looking for is for this app to never noticeably impact the performance of any other running programs.

It's essentially a specialized clock that automatically logs the amount of time spent on various tasks, and provides a nice visualization. Being that it's a clock and logging tool, it will be running non-stop.

The application needs some of the graphical elements of the DirectX runtime, but very little beyond just animating some sprites.

Obviously, I don't really need GPU acceleration for something like this, but I'm not even sure if I can disable it. I can probably get away with knocking the FPS down to 30 without anything really noticeable changing, but I'd prefer to exhaust other options first.

Is there a way to set the application to the minimum process priority at startup for example?

Does the Process object do that? I tried using it, but it doesn't seem to change the priority, at least not in any way that I can see from the task manager.

Is it possible to access a "Box" object's private variables from Python?

(Just to be clear, by "Box" object, I mean the object found in the "Insert new object" dialogue you get from right clicking in the layout editor.)

I've tried using the following python expression,

Box.Value( 'privateValueName' )[/code:38ktw271]

but it does not seem to work. I get nothing back.

Now, for other object types, such as "Sprites" or "Panels", it does work.

Am I doing something wrong, or can python simply not access "Box" object variables?

Okay awesome, I just built another test cap to try it out in a simpler environment and it works.

What worried me is that I had tried a simple test earlier and gotten back nothing, so I must have just done something wrong without noticing.

Thanks.

Is it possible to access private variables from Python?

I've been trying to get expressions like

Sprite.Value( 'privateValueName' )[/code:3vrx0x9k]
to work in python, but so far it seems like I only get back some kind of null value.

What is the purpose of the "PreviousTexture" mentioned in the wiki?

http://sourceforge.net/apps/mediawiki/c ... el_Shaders

It seems to be exactly the same as "BackgroundTexture" when it is the first effect, and exactly the same as "ForegroundTexture", when any effects come before it.

Is it just so you can make effects that work on both the background and the foreground depending on its position in the effect chain?

This may seem like an odd question (and it's unrelated to Construct), but is there a way to flip the entire XP desktop vertically. By "flip", I mean mirror vertically, not rotate 180 degrees. By "desktop" I mean everything shown on the monitor. That is to say, the mouse pointer, windows, menus, text; everything would be upside down, while the computer continued to operate in real-time. I know there are ways to rotate the display, but that isn't what I'm looking for.

e.g. If you laid a mirror flat across the keyboard of a laptop computer, ordinarily the reflection of the screen would be flipped vertically, but not horizontally. To make the reflection appear right side up, you would need to vertically flip the image on the monitor. Rotating the image on the screen 180 degrees would not work, because you would get the reflection right side up, but it would be flipped from left to right at that point.

Essentially I'm looking for anything that will allow me to flip the screen along the X or Y axis in software. I don't know if there are any third party tools or plugins for windows that do that but I figured I'd ask.

I've looked around for something to do this for a while now and if anyone knows of anything, please let me know. Thanks

One of the most awesome features added into construct since I've started using it is the ability to transfer objects and code between cap files.

Does anyone have any recommendations on how best to write code, break up event sheets, and, name objects to make such transfers as simple and modular as possible.

I've been investigating this on my own for a while, but I'm curious what advice is out there.

Ideally, I'd like to be able to build game engine modules in separate cap files, and then pull them together into full applications, if that makes sense.

What is the purpose of "Object Folders"?

Is there anything special you can do with them?

For example, can you place two different objects with the same name in separate folders, to avoid name space conflicts?

Just curious, as I can't find much documentation on them.

One thing I have noticed is that if two different objects have the same name, the "Object List" will only show you one object listed under that name, while the object folder will actually have two distinct objects that share the same name listed.

You can get two different objects with the same name by copying an object from another .cap file and pasting it into a .cap file containing an object with the same name as the object being pasted. At least it works with "Text" objects. I think you can also get away with renaming objects so that they have the same name if you're using the "Object Folder" view, and that method appears to work on any kind of object.

Okay, cool. I'm just glad I'm not going crazy.

I figured it might be a means of sidestepping the weighting calculations to get a performance gain. I ran into premultiplied alpha a while back using Maya. Granted, you can get away with disabling premultiplication for Maya, because Maya is by no means a real-time application.

It makes sense that Construct uses it to speed up compositing, since the name-of-the-game is flooding the screen with sprites, and 99.9% of those sprites will get drawn onto a fully opaque backdrop. Though actually what about transparent layers? Do they just force z-ordering, unless you tell them to render themselves as an intermediate texture?

Sadly though, it seems then that you can't store arbitrary alpha maps without irreparably degrading the image information in the RGB maps.

For example, the divide by alpha method you describe, is the same method I described in the 5th paragraph of my first post, and it's not capable of retrieving the original RGB values, because they have already been degraded by premultiplication, followed by quantization into the 8-bit color model. The best you can get is a quantized/depth-aliased approximation that gets less and less accurate as transparency increases. (Unless I'm thinking about this the wrong way, but I've already tried a number of different methods and it would appear that the original data really just isn't there to be retrieved.)

One of the reasons I was interested in getting at the original RGB image data is that I wanted to make a small painting application that could do gamma accurate color blending. For that I would need to have access to the unaltered RGB and alpha maps.

I can't really complain though, a lot of the cool things you can do with separated channels aren't really what Construct is designed for, so like everything it's a tradeoff. And I agree that in Construct's case premultiplied alpha is the way to go.

If there was a way to disable premultiplication for certain objects though, that might be nice, but understandably that probably won't be a priority any time soon. Even so, it might be worth looking into the problem with the Construct image editor (see 6th paragraph of first post).

That said, is there a way to use effects to apply a grayscale texture to an object as an alpha map? I know there's a "Mask" effect, but I'm not sure if you can set it up to punch through only the object one z-index behind it. It's seems like you couldn't, because any object one z-index lower would have already been flattened into the scene. Then again, I'm not that familiar with DirectX.