Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 106 Roadmap
- 358 Game & application design
- 315 Plugins
- 70 User experience
- 74 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 659 Bugs and issues
- 195 Introduce yourself
- 236 Announcements
- 105 Forum talk
- 403 Relax cafe
In this Discussion
Increasing the Awesome
bowerandy
Guru
There have been a few posts on this forum about what features should be included in future versions of Gideros. Some are requests for features to play "catch-up" with alternative frameworks like Corona and Moai and others are for immediate requirements for particular games (like my recent appeal for an async texture load feature) in production right now.
However, I've recently watched a video, which I think it might project a great route forward for Gideros that would just blow away the competition. The interesting thing is that you are almost there already. Take a look at this video (if you are in a hurry then you need only watch the first 15 minutes):
http://bit.ly/GD1rNb
I come from a Smalltalk world (http://www.object-arts.com) where a similar level of interactivity with the programming language has been available for some time but, sadly, the differences between Smalltalk and the more mainstream languages is just too large for many to grasp. Also most people don't see a need to change their working practices; until they see a video like the above! Mobile is hot now and you could take mobile development to a whole new level.
What brought me to Gideros from Corona and Cocos2D were:
1) You provide a built-in framework for dynamically typed object orientation in Lua. Yes, Corona can do this (because it is also Lua) but it is not an included part of their product. This means that shared class libraries just aren't built in Corona because there is no standard for them. Cocos2D (which is Objective-C, of course) has good object-orientation, because OC is effectively Smalltalk, but it is statically typed, ugly, and a pain to write and also didn't have proper GC until recently.
2) But the above isn't central to this post. I think the KILLER feature of Gideros is the Player. Running on the device and able to take-in incremental code changes and run them almost instantaneously. You are already the closest to the vision in the above video of any SDK/Framework out there. This is where I think you should focus future development - to me this is your differentiating feature.
There have been some calls to get the Gideros IDE working on the device itself; to cut out the desktop environment. With the way your environment works I can see that this would be eminently possible. It would be COOL, but I believe that ultimately it's a distraction. There is just not enough screen real estate (even on an IPad 3) to make this a viable IDE. But pumping incremental changes from the desktop IDE through to a RUNNING program in the Player, that would be both cool and game changing. Indeed, in the words of Steve Jobs, it would be AWESOME.
BTW, note how this way of working would remove the need for level builders etc. The way we work now the SVG Level Builder is a great tool and almost essential, but imagine a future...
Best regards
However, I've recently watched a video, which I think it might project a great route forward for Gideros that would just blow away the competition. The interesting thing is that you are almost there already. Take a look at this video (if you are in a hurry then you need only watch the first 15 minutes):
http://bit.ly/GD1rNb
I come from a Smalltalk world (http://www.object-arts.com) where a similar level of interactivity with the programming language has been available for some time but, sadly, the differences between Smalltalk and the more mainstream languages is just too large for many to grasp. Also most people don't see a need to change their working practices; until they see a video like the above! Mobile is hot now and you could take mobile development to a whole new level.
What brought me to Gideros from Corona and Cocos2D were:
1) You provide a built-in framework for dynamically typed object orientation in Lua. Yes, Corona can do this (because it is also Lua) but it is not an included part of their product. This means that shared class libraries just aren't built in Corona because there is no standard for them. Cocos2D (which is Objective-C, of course) has good object-orientation, because OC is effectively Smalltalk, but it is statically typed, ugly, and a pain to write and also didn't have proper GC until recently.
2) But the above isn't central to this post. I think the KILLER feature of Gideros is the Player. Running on the device and able to take-in incremental code changes and run them almost instantaneously. You are already the closest to the vision in the above video of any SDK/Framework out there. This is where I think you should focus future development - to me this is your differentiating feature.
There have been some calls to get the Gideros IDE working on the device itself; to cut out the desktop environment. With the way your environment works I can see that this would be eminently possible. It would be COOL, but I believe that ultimately it's a distraction. There is just not enough screen real estate (even on an IPad 3) to make this a viable IDE. But pumping incremental changes from the desktop IDE through to a RUNNING program in the Player, that would be both cool and game changing. Indeed, in the words of Steve Jobs, it would be AWESOME.
BTW, note how this way of working would remove the need for level builders etc. The way we work now the SVG Level Builder is a great tool and almost essential, but imagine a future...
Best regards
tweets: @ insidebowerhaus blog: http://bowerhaus.eu/blog/blog.html
+1 -1 (+2 / -0 )Share on Facebook
Comments
I agree, that this interactive style of programming is the future of GUI programming. I think it's already possible today by writing the app a certain way. LuaGravity's meta module treats all variables as function calls (accessors) so that anything (a coroutine that listens on the network maybe?) could change their values. Functions are variables too, right?... The thing I don't know is how you'd tell the running app what to do. Sockets?
Gideros Studio obviously already talks to the Player app but I don't know how it does that or if it could talk to the app while it's running and if we could tell Gideros Studio what to tell the iPhone.
If Gideros Studio is modified to allow us to send messages to the iPhone Player I would like to request that it not be exclusive to Gideros Studio though. I actually do most of my work on an iPad and iPhone right now by having an iPhone app that downloads the latest lua code from Dropbox and I edit the app on my iPad with Textastic and Nebulous Notes. I'd like to be able to tell my iPhone what to do without Gideros Studio in the mix.
In fact, if you loaded all of your source code (something I do to develop on my iPad) using the URLLoader class you could have it kick off every few seconds to check to see if there are changes. I'm not sure exactly how much code I could replace this way while the app is running... And when I have crash errors, how to do recover? Right now the screen just goes white and I press the home button and I put an exit(1) in the applicationDidResignActive delegate method of the Xcode project.
I should also request the ability to tell URLLoader to not download if the last modified date in the HTTP header isn't newer so it doesn't keep downloading data it doesn't need.
I'm actually really close to hackishly doing this right now (without the cool IDE though).
My apps: http://www.yummyyellow.com
First of all, in St, the units of compilation are class definitions and function definitions. One can change individual functions (in St they are called methods) without having to recompile the whole class. I don't think this would be a necessary feature to make it work in Lua though.
In St, when a class definition is changed, we clone the existing class and modify the clone. The clone then becomes the new version of the class. The existing class is mutated to make it compatible with the new definition and left in the runtime until it is garbage collected later when all existing instances have disappeared. Since Lua doesn't really have the notion of a fixed class definition at all (objects are just tables) I suspect that this complication may be wholly unnecessary.
What might well be required would be some way of handling function calls that are already on the execution stack. In St, when a function is recompiled, it is installed in the function table of the class. However, any existing invocations of this function (maybe you are stopped in the debugger) are left alone. They will eventually be garbage collected when the stack clears down. This is possible because, in St, everything (classes, functions etc) is a true object.
Now I wouldn't want all this complexity to discourage anyone from trying to get something like this working in Gideros without this level of detail. I think just by replacing whole classes at a time the effect could still be stunning. As Brett Victor said, "why should I (you) have to imagine what the computer is trying to do, when it can show you itself". This comment nicely emphasises the difference between creating code "at edit time" compared with dynamically "at runtime".
This way of coding also works great with test based design. You code your tests up front, let them run and then fill in the code missing function by function until it is complete and the tests go green.
As I say, I don't think we'd need this level of sophistication to reach "Awesome" in Gideros (it's pretty much there already) but it might be food for further thought. Please let us know how your hackish experiments turn out.
Best regards
line:addEventListener(Event.ENTER_FRAME, onEnterFrame)
After 5 seconds I fired a timer that downloaded a different file and used dofile to run it. The contents of the second file contained a slightly modified onEnterFrame function and nothing else. After 5 seconds my phone started drawing using the new function.
So, yeah, this is possible now but depends more on how we structure our projects.
I just tried loading the same file with lots of code and running it twice and it didn't work so well. I added a flag to run some code only once, and so far I haven't gotten it to work. I suspect scope has a lot to do with my failures. I took all of the locals out but it but I just need to keep playing with it.
@atilim, how does the iPhone Player not crash when bad code is sent to it? Right now errors end my app and I have to restart it. It's at a white screen so I'm sure it is still running. I haven't plugged it in and looked at the console with Xcode yet.
My apps: http://www.yummyyellow.com
http://magnusviri.calepin.co/gideros-downloader.html
My apps: http://www.yummyyellow.com
Yes, pcall is the answer. On the other hand, wrapping each function with pcall can be complicated. I cannot give an ETA, but I also want to improve the error handling. So that you can attach a hook and capture all the errors within the program.
My apps: http://www.yummyyellow.com