Hi all -

I am trying to find legal information related to publishing games as an "amateur" / "hobbyist".

Basically I will soon be in a position to sell a small game I developed but I don't know much about entrepreneurship and legal company stuff.

This all depends on localisation (Europe here btw) and I will want to see an accountant (or solicitor, or tax/business advisor) at some point, but for now I am gathering information to review the options at my disposal. Additionally, with modern technologies (international distribution platforms, paypal, etc.) it is not always trivial to find tax experts that are also up-to-date on internet specificities.

The core question could be formulated as : I created a game at home, what is the legal process to sell it ?

This could also apply to lots of other disciplines (painting, writing, music, etc.)

From what I've read so far, I see mainly 3 cases :

• Independent worker, as a main income-generating activity. This is relatively well covered, with lots of suitable business statuses (sole trader, limited company, etc.)

• Freelancer, working on demand for a client ; btw apparently it is possible to be freelancing while being incorporated or not

• Hobbyist, producing something of value without any real business structure

My situation is quite close from the last one, I think ; I don't have an infrastructure (no office, no dedicated hardware, only my home equipment), no order (not creating the game as a request for a client), no fixed working hours (personal free time)

I am trying to limit the administrative paperwork while remaining on the legal side to sell a product.

Lots of applications are being published by individuals on a regular basis on many platforms (itch.io, gamejolt, etc.), so I'm thinking there must be an easy way, but actually finding the legal info is far from trivial. Most of the websites talking about indie games focus on the development process, not really the legal/business side of things for individuals.

If I can make a simple revenue declaration to pay the relevant taxes without being incorporated, that would seem like a practical solution.

Well, if anyone has ever published games as an individual or has experience with this, any advice would be greatly appreciated.

Thanks for reading

Thanks for the confirmation, 'much appreciated.

I've created a minimal test scene demonstrating the problem ; bug reported :

Problem Description

This bug report relates to the following thread : load-assert-getobjectbyuid-and-quot-wait-until-afterload-quot_t163350

Performing an UID lookup in "on created" triggers during layout transition fires an assert "Do not call getObjectByUID in loadFromJSON: wait until afterLoad() to look up"

Attach a Capx

https://dl.dropboxusercontent.com/u/526 ... ssert.capx

Description of Capx

2 layouts, a "menu" and a "game level"

Menu : Space to go to the "game level" layout ; F9 to load a game state

Game level : 3 entities : ground, player, pickup. I'm not too sure if/how object creation/destruction works with game states, so having a player being able to collect pickups provides a quick way to "collect" some of the entities and try different "save/load" configurations. On creation, the pickup entity performs a UID lookup (pick by UID) with triggers the assert

Steps to Reproduce Bug

• Menu, press "space"
• Game, press F6 to create a save state
• Restart the game / reload the page
• Menu, press F9 to load the save state > an assert is triggered

• Menu, press "space"
• Game, press F6 to create a save state
• Restart the game / reload the page
• Menu, press "space"
• Game, press F9 to load the save state > the assert is NOT triggered

Is seems the assert fires only during layout transition.

Expected Result

The assert seems to have no impact ; the event logic seens valid, therefore the developer expects no assert

Affected Browsers

• Chrome: YES

Operating System and Service Pack

Win10

Construct 2 Version ID

C2 r216 64b (Steam)

Confirmed the hunch !

OK, this is indeed coming from UID lookups in "on created" triggers during loading phases that cause a layout transition.

I worked around the issue by duplicating a bit of code in all entity creations, or delaying UID references (lazy-ctor style), as I was mostly mimic-ing a super-constructor behaviour via function calls ; this makes it virtually impossible to factor creation logic with "interfaces", but isn't too bad to deal with once you're aware of the limitation.

Thanks R0J0hound for the input, just boucing some ideas and formulating possible causes to explain the problem help to think properly, in these cases.

Ashley if I have time I'll try to recreate the assert in a smaller test scene to report it properly as a possible "bug" (or undocumented unexpected behaviour)

In the meantime I'll try to play around with my "on created" events to try to eliminate/delay all UID lookups. Hopefully this will solve the problem...

*edit* Hmm on some further investigation, it seems it might be coming from the system I use to mimic "inheritance" via families and function calls -

Basically, most of my entities follow this pattern :

• Entity belongs to Family ; Family is used as an "Interface" to factor some data and logic
• "on Entity created" > call function "Family_method(Entity.UID)" (almost like a constructor calling a super-constructor to initialise data of higher-level interfaces)

A concrete example : Guard entity (a simple sprite of a guard patrolling left/right with a sine behaviour) that belongs to my SuspendableIF "interface" family (factored logic I use to suspend/resume entities when far away from the player so they don't cost any performance in my large levels when not close to the action)

Guard : on created

set some member data / behaviours (sine magnitude and period)

calls SuspendableIF_Init(Guard.UID) ; this generates some functions names (Guard_Suspend, Guard_Resume, Guard_Advance) that are cached in the SuspendableIF to be called later (removes the cost of dynamically generating these names from "class" info lookups)

Anyway, short version : the problem I'm facing might be coming from these UID look-ups in "on created" triggers during the loading phase !

I might try to summon Ashley on this one to confirm how things actually work in terms of entity creation during loading :

Ashley : using UID lookups in "on created" triggers when loading game states that cause a layout transition seems to fire a "Do not call getObjectByUID in loadFromJSON: wait until afterLoad() to look up" assert. Does this seem like an expected behaviour ? If it is, are there any good recommendation to easily work around this ?

Thanks for the input, 'really appreciated -

I tried going through the call stack, but but with limited understanding of the underlying low-level logic it doesn't give me much to go on to be honest ; it's definitely fired during the loading process, and it does seem to have to do with "on created" triggers, at which point it all becomes indices in condition arrays and event blocks and I get a bit lost in the events that are currently running when the assert triggers.

assert2 (preview_prelude.js:11)

Runtime.getObjectByUID (preview.js:2863)

cr.add_common_aces.cnds.PickByUID (commonace.js:475)

Condition.run_static (eveng.js:1303)

EventBlock.run (eveng.js:868)

EventBlock.run_subevents (eveng.js:996)

EventBlock.run_actions_and_subevents (eveng.js:935)

EventBlock.run (eveng.js:888)

Runtime.executeSingleTrigger (preview.js:4843)

Runtime.triggerOnSheetForTypeName (preview.js:4762)

Runtime.triggerOnSheet (preview.js:4694)

Runtime.trigger (preview.js:4665)

Acts.CallFunction (Function_plugin.js:180)

Action.run_object (eveng.js:1852)

EventBlock.run_actions_and_subevents (eveng.js:931)

EventBlock.run (eveng.js:888)

Runtime.executeSingleTrigger (preview.js:4843)

Runtime.triggerOnSheetForTypeName (preview.js:4762)

Runtime.triggerOnSheet (preview.js:4694)

Runtime.trigger (preview.js:4665)

Layout.startRunning (layout.js:381)

Runtime.doChangeLayout (preview.js:2743)

Runtime.loadFromJSONString (preview.js:5499)

Runtime.handleSaveLoad (preview.js:5302)

Runtime.logic (preview.js:2610)

Runtime.tick (preview.js:2322)

Runtime.initRendererAndLoader.tickFunc (preview.js:649)

As for the triggers I am using, well... Quite a lot ; it's a full platformer game - I'm unable to reproduce the issue on small test scenes, and binary chopping through my events doesn't get me very far in terms of narrowing things down.

Hi all -

I'm facing a problem with loading/saving, and I'm not too sure what's triggering an assert.

The assert is : "Do not call getObjectByUID in loadFromJSON: wait until afterLoad() to look up", and it's coming from preview.js:2863

Runtime.prototype.getObjectByUID = function (uid_)

{

assert2(!this.isLoadingState, "Do not call getObjectByUID in loadFromJSON: wait until afterLoad() to look up");

var uidstr = uid_.toString();

if (this.objectsByUid.hasOwnProperty(uidstr))

return this.objectsByUid[uidstr];

else

return null;

};

Initially I thought it was to do with objects dynamically created and destroyed by other objects (typically : on created > create some more stuff, on destroyed > destroy some more stuff the was previously created)

I had a nice repro-case with a pickup object. A pickup item is manually placed in the level ; on creation, the pickup item creates a "floater" item (could be some text, icon, effect, etc. floating above the pickup) ; the pickup keeps a reference (uid) to the floater it creates ; when the pickup item is collected by the player, it is destroyed , which also destroys the floater.

I moved things around a bit to avoid looking up UIDs in "on destroyed" triggers, and it seems that helped a bit.

Still, I have more cases of this assert firing when loading game states from a different layout (game menu) :

I breakpointed on the "return null;" and that never triggered, so I *think* this has actually no impact on the game (and I can't see anything wrong when playing the game after loading with the assert).

Nevertheless I'm still confused - what's the actual sequence of events when loading a game state, esp. regarding object creation/destruction ?

Has anyone ever faced this assert when loading save states ? Any idea what might be triggering it ?

I've been investigating on smaller test scenes and binary chopping through my events, but at this stage I don't have much left to go on and I haven't been able to narrow it down any further ; any pointer or random guess would be appreciated !

Ashley : my apologies ! I recently cleared some old links I submitted in the past for other bugs/demos and it seems I mixed a few things :/

Correct .capx for this bug : https://dl.dropboxusercontent.com/u/526 ... onBug.capx

You'll be delighted to see it only has 6 events <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> Thanks for finding the time to look into this !

BasicTribe : yeah well, sorry for not knowing all the posts from all the users from the past months... Only trying to help ; I'm not wasting time re-creating a project for a problem I'm not facing.

This thread has gone full circles too many times ; I'm done for now on this one.

when i make a simple Capx with 15 small objects on layer and the framerate is going down

It sounds like it's simple enough to reproduce easily ; please submit a sample .capx for the interested parties to investigate ! I too would like to know how it's possible to bring the framerate down with only a handful of objects (unless they're all supermassive blended textures on a very old device, which would kill the fillrate and pixel units anyway, regardless of the technology)

Depends on your budget ; people have been creating games for decades on computers that were less powerful than a recent mobile phone. It's only a matter of scale and comfort.

If you can, go for multiple monitors straight from the beginning ; all creative activities (art, design, programming, etc.) benefit a lot from multiple monitors in terms of productivity (develop on one screen, have the documentation opened on another, see the game running on a third, etc.)