Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

API ideas for next version

edited October 2011 in Suggestions Posts: 8

Hello team,

first let me say, that Codify is a really nice app. For me, I think this app has very high potential of being a hit for programmers and (open source) gamers on iPad. I am Tapsi, I code on a advance wars clone for different plattforms and this one looks really nice and ( more important ) like a real way to port it to iOS as well.
So if I'm allowed, I would share my ideas of additional API with you. Feel free to discuss about it and give me hints as well. ^^

Network API:

Not much, but if we could connect two sockets into a session, than we could allow multi player games.

netHandler = socket()
netHandler.onMessage = f // sets the handler function, that will be called on incoming messages
netHandler.connect( ip, netHandler ) // connects to an IP
netHandler.sendMessage( msg ) // sends a message
netHandler.disconnect( ) // disconnects
netHandler.listen( port ) // listen on a port

but I don't know exactly what ports allowed to be used by iOS programs..

Persistent Storage:

Real cool games would be nice, but I think they need the ability to store data on the device ( like save games )

// gives you a persistent storage object for a name ( this way would allow sharing data between projects )
persistStorage( String storageName )

// storage object functions
st.save( String key, String value )
st.get( String key ) returns the value
st.delete( String key )

Misc:

sleep( Number time ) // pauses the program
setFont( family, size, modifiers ) // sets the font for printing text on screen
drawText( String text ) // prints text on screen
getInput( keyboardType ) // open onscreen keyboard and get the text ( closed with ENTER or such )

Hope somebody can use that.
At all I like codify a lot, hopefully we get something like the above API to make serious open source games for iOS :P

Greets Tapsi

Tagged:

Comments

  • Posts: 13

    +1 for sleep :)

    Even the 'ol really-big-for-loop-trick only gets you so far due to:

    Lua program has exceeded instruction limit

  • Posts: 12

    Can you not just wrap your draw function (plus any watchers etc) in an "if(!paused){}" to handle the pause?

  • edited October 2011 Posts: 13

    sleep() pauses the execution for a specified number of seconds (or sometimes milliseconds). Lua doesn't have a built-in sleep, but there are a number of ways to handle it (though all require os.* or io.* or socket.*): http://lua-users.org/wiki/SleepFunction

  • BortelsBortels Mod
    Posts: 1,557

    Hmm - the problem with sleep is that Codify's main loop is a draw loop, executed every 30th of a second. If you want to pause, you still need to redraw the screen.

  • SimeonSimeon Admin Mod
    edited November 2011 Posts: 5,054

    Tapsi: awesome API suggestions. Really like them. I think what you have for networking might be a bit low level. I was thinking the network API might automatically bring up a session list, allowing the user to tap another Codea session to join, which would simply return an ID to your code so you can talk to it.

    Good persistent storage, not sure if you need delete – just save( key, nil )

    I suspect you can simulate sleep-like behaviour using coroutines.

  • +2 for networking

    It would be preferable to be compatible with the existing standard Lua socket library.

    A Codea specific higher-level multi-player gaming API could be built on-top (as mentioned by Simeon) for simplicity.

    However, only having Codea specific networking would be a severe limitation, compared to general TCP/IP socket access.

  • BortelsBortels Mod
    Posts: 1,557

    I concur on general sockets; We can always build on top of that, but high level protocols may not allow the flexibility we'd need for other things. And - there's a giant, obvious advantage in being compatable with the existing lua socket libraries...

  • SimeonSimeon Admin Mod
    Posts: 5,054

    Okay that sounds like a convincing argument. Perhaps some of what gets built on top of the sockets library can be put back into Codea as the official high level networking API.

  • Posts: 13

    @Bortels "Hmm - the problem with sleep is that Codify's main loop is a draw loop, executed every 30th of a second. If you want to pause, you still need to redraw the screen."

    Not really :)

    Sleep should literally suspend execution of the process for the given amount of time. What if instead of drawing 30fps I want to only draw 15fps? or 1fps?

  • Posts: 13

    @Simeon "I suspect you can simulate sleep-like behaviour using coroutines."

    Somewhere I still need access to a clock so I know how long to suspend. I didn't see any way to get that info.

  • SimeonSimeon Admin Mod
    Posts: 5,054

    @jgjuice: Next version has os.time(), os.clock(), os.date() exposed. Though in the current version you could check against ElapsedTime?

  • BortelsBortels Mod
    Posts: 1,557

    Side Note: The more native APIs you have exposed, the happier I'll be. I like a high level API, but I like better the ability to "roll my own" if I need to. I can't imagine Apple would be upset with exposing read-only stuff (like access to time, acceleration, the compass if it's there, and [he says pushing it] music and photos). I can dream.

  • Posts: 13

    Thanks Simeon! I'll give it a shot :-D

  • +1 For more native APIs, especially compass and location; those would open up some great new possibilities.

  • I'm a total newbie to the iPad and Lua but Codea is a very interesting concept to me. I would like to try and write an app that gives me distance, bearing, time to go, etc to some specific lat/Lon that is user selectable. Is there any future plans to be able to tap into the iPads current position, altitude, etc? Is it even possible to do with Codea or do I need to look elsewhere? TIA

    Carlos

  • BortelsBortels Mod
    Posts: 1,557

    You can get acceleration (gravity and sudden movement) now. The iPad has gps - but it's not exposed in Codea... Yet. hopefully TLL will add it at some point.

    But you hit on an Interesting limitation of the iPad (and IPhone and android and so on) - there is no way to do absolute position. Gps will approximate it, but there's no way to locate the iPad in space with a high resolution (ie within less than a few meters). And that includes altitude. And I know of no solution for that short of cameras (no access yet) and image processing.

  • Yes, I saw the accelerometer functions in the reference guide which prompted me to look for gps location type functions. It would be nice to have a high resolution position fix but I would be very happy simply having the gps lat and Lon plus altitude info. BTW, is there a full screen Codea reference available (web page maybe?). I am still trying to wrap my brain to this new environment. Thanks.

  • BortelsBortels Mod
    Posts: 1,557

    Codea, semi-kinda - go to the Codea home page, there's a link to the Codea-specific docs.

    For lua in general, look on the wiki for links to PIL (programming in lua) and the lua reference.

  • Posts: 2,820

    "I was thinking the network API might automatically bring up a session list, allowing the user to tap another Codea session to join, which would simply return an ID to your code so you can talk to it." Yes. You finally got my point.

  • Posts: 622

    Zoyt, gotta call you on this. You joined the forum in Decemeber and the statement they "finally got" your point on was made in the prior month. So, unless you like Merlin are living backwards in time, I think you are coming around to thier point of view.

  • Posts: 2,820

    I know. I missed it before.

  • Posts: 2

    I like the Apis to be high level. makes prototyping faster. I think that should be high priority. low level access would be nice, but I think that should be less emphasized.

  • SimeonSimeon Admin Mod
    Posts: 5,054

    @tommy7xp that's our feeling as well. Getting stuff on the screen as quickly and easily as possible is the philosophy.

  • BortelsBortels Mod
    Posts: 1,557

    There are pros and cons.

    TLL providing a high level interface means the barrier to entry for end-users is lower, and there's a good chance performance will be better - both desirable.

    But - TLL has limited time money manpower - it may be the case where it's a low level API now, or a high level API... Maybe someday. Fonts were like that - before TLL built them in, we rolled our own. They weren't as good in most ways, but they did have the advantage of taking zero TLL development time.

    I'd rather have a low level API now, or soon, than a high level one maybe never. I believe that if we can solve certain packaging and distribution issues, there are enough end users willing to wrap low level API code and share that TLL could spend their time on other stuff we can't do.

Sign In or Register to comment.