How would you guys proceed from here? Will you start to migrate to another engine? Or going to stay put to see if the Corona engine can be adopted by a group of developers and keep it compatible with the latest OS?
I will not be changing. I hope that things will get even better. Apparently ever since I got here there has been maybe one part- or full-time programmer working on corona. It is a great engine
i am not migrating anything. When I can’t build, can’t deploy and need an update that is when I migrate (if they are making money). I also have about 4 games in some sort of progress also in corona. Two in particular I paid somebody in these forums for the game mechanics, so no way I am abandoning them. I have also 2 native iOS game that I want to finish. 6 games is more than i can produce in a year. So nothing that happened today changes anything for me. When 2021 rolls around I’ll re-evaluate.
Coronalabs leaving the scene isn’t necessarily the end of the world. Corona will still exist and as an open source tool can still technically be kept up to date. The issues are that the marketplace will be closing, and that if nobody picks up active maintenance of the core, we could end up with broken iOS / Android support very quickly.
If we can drum up enough support for it, we’ll be building a new marketplace to take over from the current Coronalabs service. This fixes the first of those issues, provided we do it well enough, which of course is the intention. We’ve a plan for making sure existing purchases are respected by the new system, and for making sure updates to plugins are rolled out to all customers despite the SDK becoming an offline tool. Hell, it’s open source, we could even build in an automated pull.
If we do go ahead with this and the new marketplace generates some revenue, a percentage of that would be offered back via Patreon to anybody who’s interested in working on the core platform. There are others here who have expressed interest in supporting a core team via Patreon too. This potentially fixes that second issue.
Longer term, if a new marketplace proves financially successful, another percentage could be used to start marketing Corona again. There’s been comments for a long time about the lack of marketing by Coronalabs.
Please have a read through the below link and sign at the end if you’d like us to go ahead with this. We need to know enough people are planning to stick around and continue using the marketplace to warrant building it.
I keep using Corona - I really like it and hope, once the transition is done, it’s possible that the supported targets will be maintained and updated to whatever new ideas their vendors add to their platform.
With the new license it’ll be also more interesting to add niche features that wouldn’t end in the main dev trunk before, which made it rather unattractive to even try to experiment as the only way to use the results would’ve been to opensource your game too.
All I have is a couple of casual games for myself and some simple apps and casual games for customers.
It’s not my main job but the income is pretty sweet and I don’t want to lose it.
I really wonder what will happen when Google or Apple will demand a big change like 64bit support (android) or metal (coming in a few months for iOS).
Well, I’m supporting my live Corona projects although I’m not sure what I will do with the new ones.
Corona is the best environment for me but I can migrate everything very easily just in few months.
Of course if it was in my hand I would stay with Corona forever.
Thinking how we have reached to this point makes me… going slightly mad (Queen reference :P).
I’m hoping for the best and excited to support Corona (money and time) as we move forward as community.
Like everyone else, I am holding fast and seeing how things go moving forward. I’m willing to support Corona moving forward and if possible, I’d like to continue using it in the future. As a pure 2D engine, I think Corona is fantastic. With a little more work and additional features, it would be undoubtedly the best.
Great to see everyone still interested to keep using Corona in the near future. Hope this will motivate the core team to continue with this project.
I’m quite ashamed to admit it, but I have several plugin projects completely ready for launch… I’ve just been too busy with my other responsibilities and I’ve been pushing their release off for too long. Now literally. 
I’ve created:
- FontLoader , a plugin that will preload all of your app’s fonts and cache them so that they’ll be faster to use afterwards. Great for apps with multiple custom ttf and otf fonts.
- Morph , a plugin that can be used to… well, morph display objects with physics bodies in a way that the physics body adjusts with the display object when it is scaled or flipped horizontally or vertically.
- Resolution , a plugin I just wrote last weekend that allows for changing window size and managing the content area width and height for Win32 and MacOS projects. In other words, you could, using this plugin, change the resolution of your app from 1280x720, for instance, to 1920x1080 and everything would just work the next time you start the game. This plugin actually became possible only last week or so when new native.setProperty() features were added to Corona core.
- Weaver , a Twine 2/Yarn interpreter that allows a developer to create stories, dialogue, etc. within either Twine 2 or Yarn and then just load them in Corona using Weaver. The plugin will interpret all sorts of commands and determine what dialogue/passages it should return to the player. I already created a few demo scenes and I almost finished a simple and easily customisable visual novel engine to accompany it.
- Window , a simple plugin that will create window UI elements like Corona widget’s 9-piece button. I realised that I needed to create all sorts of different popup windows and backgrounds for in-game stores, etc. and as they changed from game to game, or scene to scene, having a plugin that could dynamically create such UI elements of any size was a no brainer.
- Shadows , now this is my pride and joy, a pseudo 3D shadow engine that can calculate and create shadows for display objects in Corona. By leveraging Corona’s image effects, canvas and masks, it can create soft shadows and make the shadows fade out into the distance, and much more.
Now that I am out of time in terms of releasing them to the marketplace, my plans are to release FontLoader, Morph, Resolution, Weaver and Window for free as open source projects under MIT license. That way anyone could use and modify them as they see fit. Of course, if a new plugin store is made, then I’d of course add them there too (for free). The one plugin, well, module to be precise, that I would probably charge for would be Shadows. But even with it, I’d sell it as a Lua file so that anyone who buys it gets the actual source code as well.
@Spyric - Love it! If you make a Ko-Fi page I’ll send you some coffee! I’ve seen a shadow of these plugins during our forum discussions - tips you’ve shared.
@sporkfin, you know… I’ve been meaning to set up a Ko-fi page as well… buuuuuuuuut… you know… “been too busy”.
I’ll make it my business to wrap up these things by next week, so I no longer need to lean on this old excuse.
re shadows… does that work with 2.5D display objects (and many thousand of them onscreen)? if so do reach out to me
lol thats a lot of plugins Cant wait to test them - the shadows especially. My game could use shadows!
@SGS, the way that the plugin works is that it considers every object to be either 1) a cylinder, 2) a sphere or 3) some sort of cuboid or prism. Basically, when the shadow module is given an object, it must be told how tall that object is. With sphere, the height is automatically set to it’s width (duh), but with cylinders and others, the height needs to be specifically stated.
For instance, if you had a pentagon shaped polygon in your game, then the shadow engine would treat it as a pentagonal prism and it would cast shadows based on its height as if the object was 3 dimensional and as if the light source would be on some 3 dimensional plane as well. The shadow module’s limitation is that it considers all rect/polygon objects to be flat, i.e. it wouldn’t work with pyramids or such shapes (although a pyramid would actually be super easy to add). Technically objects could have slanted tops, but I thought it was safer to just ignore such scenarios at the risk of some potential future users creating odd “crown like” shapes that would result in self-intersecting shadows. As long as the “ceiling” or “top” of these polygons/rects is flat, then such things can’t occur.
The plugin works by calculating the outline for the shadows and then, by default, it will create a shadow out of a polygon (for rects and polygons), a partially masked polygon and a circle (for cylinders), or a circle (for spheres). I haven’t tested it out with creating thousands of shadows, but I have run tests where it was able to create a few hundred shadows and update them on Runtime with a single light source. You could also, if necessary, just take the outlines that it calculates and use them to create the shapes yourself if you have some other higher performance tricks. I don’t think that creating thousands of shadows would be an issue for it, but I’ll need to test that next week. If the game needs to update them each frame, i.e. if you have a moving light source, then it’ll probably melt down the device. If it just creates them once and that’s that, then there shouldn’t be any problems.
But! I’ll do some testing next week and I’ll get back to you with some more information.
Why wouldnt it work with such special shapes?
It has to do with how I’ve written the shadow polygon self-intersection removal function.
When the shadow module casts shadows on concave shapes, then there is always a chance that some sides of the shadow will self-intersect and as such things “can’t happen”, I remove them. Now, this works perfectly for as long as the objects that cast shadows are “flat”, so to say, but if there would be some points (or vertices) that are significantly higher or lower than others, then the self-intersect removal that the entire module relies upon would no longer work. These “uneven vertices” would result in wrong sides being clipped and the plugin wouldn’t be able to determine the proper outlines for the shadows.
I dont really get it. But I guess thats fine