So ive been playing around with Codify (love it btw), but im not quite grasping how to use the program to create things like UIs and standalone objects. I was wondering if anyone had a link to some kind of walkthur tutorial i could check out and see where im going wrong.
Right now i have managed to add some sprites to my screen, but everythings done in the draw() function of main, which is defintely not what i want. So any tutorials, walkthurs, even a simple program code would be fanastic.
This confuses me - there are a bunch of examples that it comes with, the best suggestion I know of is to look at those. Understanding how those do what they do will get you 95% of the way there.
One thing that Codify doesn’t have much of, yet, are things like traditional UI elements - dialog boxes and buttons and the like. The initial aim is more toward processing-like projects (go see processing.org for examples).
Let me turn it around - what are you trying to do?
I think with Bortel’s font library you could probably do some pretty nice looking buttons. I think any UI stuff in the future will likely be user made libraries, it’s not something we’d like to focus on.
Theres a bunch of great examples, the problem for me was that there wasnt a really simple game example to follow. With the execption of few apps like Magica Gems, most code out there only posted their Class file and not the main.lua.
For example, say i just wanted to make a gem randomly move around the screen and when i touch the gem make it score a point.
Now last night i had a breakthru and finally started getting a Gem class to appear in my world (thanks Magica Gems!) and i think im about to figure out the touch part of it.
So heres my real confusion, im just not use to the constant repeating of the draw() function. Usually i control whether it repeats or not with my code and its making it hard to get a grip on how to use this new system for me. In my brain, i would think i would setup static objects in the setup() function, but anything i do there doesnt appear on screen or is wiped out by the constant repeat of the draw(). If i add a pause flag in the draw command, my screen flickers.
Im just having a tough time grasping how to program in this enviroment and i was hoping for some kind of step by step tutorial i could follow that would make more sense to my brain
@KStarfire yeah that can be a little tricky. It’s not an “object” based system by default. Basically you are responsible for drawing the screen every frame.
You can setup static objects in setup(), but this would be more of a object based system that you design yourself, and you would still need to tell all your objects to draw inside draw().
Just to be clear, your biggest issue is interpreting how the system gets things on the screen? I’ll try to think of a tutorial that explains it easily.
The thing to understand, perhaps, is that there is a “main loop” you don’t modify and can’t see, that basically does this (way overly simplified - there’s a ton more going on, and the point is you don’t have to worry about it):
setup()
while (break not pressed) do
draw()
end
It may help you to break down your own draw() routine as follows:
function draw()
-- update the state of my stuff
gem.x = gem.x + 1 -- for example
-- now draw it all on the screen
translate(gem.x, gem.y)
sprite(gem)
end
While your code is executing over and over, you really don’t need to think about it that way - you’re just updating the state of things, then drawing a picture based on that state. And yes - this is a different paradigm from, say, old-school BASIC - where you did
10 line x1, y1, x2, y2
and it just stayed there, static. They used to do it that way in large part because old computers were slow, so having you redraw each frame would be flickery - and so they did the redraw for you, in the background, and you didn’t even realize it was doing so.
Today, with faster computers, the “draw every frame” is exposed - and if you want to get back to “fire and forget”, you’ll need to do some sort of table of objects and have it go thru them in your draw() routine. I have an object-based system that does just that in the latest version of my font stuff (you can do “addlabel(“Hello”)”, then just do font.draw() in the draw() subroutine and it’s all taken care of), but there’s a ton of additional complexity there that may be confusing. Maybe it’s time to do a simple particle class to encapsulate some of this…
Thanks Simeon, yeah thats basically where im having trouble grasping it. Basically im thinking in an object based system, and this doesnt have that (unless we create it ourselves)
And thanks Bortels, that helps make a bit more sense.
For example, say i just wanted to make a gem randomly move around the screen and when i touch the gem make it score a point.
Create a class for the Gems with a state field in it, then another class for the logic of the game, doing this you can change the whole game only modifying a few lines in the core.
In this gameLogic class you create and handle gem classes.
For the example you wanted to do, set initially the gem to a state, flying and a velocity which is generated randomly (gem.velocity = vec2(math.rand(-1,1), …)) ,to animate this gem check the state in the draw() function which is called every single frame, and add the velocity stored inside the class instance of the gem…
Last thing is to check throught the main touch event if the touch position distance is near enought to the center of the gem position by using vectors: v = vec2(touch.x, touch.y) distance = v:dist( gem.position )
and change the gem state to another or just the velocity…
I’m a bit with StarFire’s first comment regarding beginner tuts.
Sure, Codify, sorry, Codea comes with a very nice set of mini-game examples. Problem is, they are completely worked out and it hard to see the mechanism of the program through all the text. I’m stil kinda stuck in the Basica/QBasic/Basic-256 mind frame and never made the jump to objects, inheritance and other weird stuff like that (yes, I’m old…)
What I would have liked to find and what I will probably create for my self-education is a step by step layering of code till we get to the real thing. Take for example the first game, Bit Invader. There should be a part one that only handles the background. No other code. Just showing the structures to be put in place for getting the starfield/rainy day effect, with lots of code comments. (This would even immediately let the student tinker with the effect without the danger of breaking anything else)
Then move to a completely new piece of code like the ship and controlling it. Then layer on the bullets, put in a separate ‘chapter’ for the enemies etc etc.
The initial replies to the OP immediately went from the obvious-but-hard-to-do-starting-from-zero (“Understanding how those do what they do will get you 95% of the way there”) to layering even more complexity on top (“I think with Bortel’s font library you could probably do some pretty nice looking buttons”) while the OP had already issues to get sprites showing in his ‘draw’ routine.
Now don’t take this wrong, Codea is great, I like it a lot, but to get into it as a beginner is not all that obvious
Perhaps we need to take one example and comment the heck out of it, as a “jumpstart”.
And I can see where this can be confusing if the last thing you did was years ago - not just the objects, the drawing model is quite different from how things were commonly done even 10 years ago. It used to be the screen was a wall - paint on it, and the paint sticks. The new model isn’t persistent - you draw() everything, every frame. The scenegraph-like frame-of-reference stuff (scale and rotate and all being cumulative) is also darn confusing to someone unaccustomed to it, who is expecting fixed screen coordinates all of the time.
While you wait for something specific to Codea/Codify - go look for tutorials on “processing”, the language that much of the graphics API is inspired from. The language is different - but not that much so - and it’ll cover a lot of the basic concepts.
I’ve also noted we have two rough groups here - the absolute beginners, and the old salts - and there’s value in both! If I (or anyone else) start talking “over your head” - let us know! I’m assuming people have a certain background, and so don’t want to rehash what I guess we all already know - but if you’re just learning, you don’t necessarily know it! The goal isn’t to confuse - it’s shared learning. But I can’t read your mind - if you need more explanation, ask.
Also, if you are new to this and to programming in general, it’s worth looking at “programming in lua” at http://www.lua.org/pil/ - it’s a good “get me started” document. It DOES assume you have some programming background - but I don’t know of a better free starter resource. And - ask questions! I can’t speak for the Codify/Codea guys, but I don’t think this board is inappropriate for general Lua questions, especially since it’s often unclear if the problem is Lua or Codify or both mixed up together in a bucket. If you do ask a Lua question, and get a URL back as a reply, don’t take it wrong - the manual or PIL pages will give you a better, more complete, and bookmarkable answer, along with links to find out more - something we can’t necessarily post here.
When Codify was released, I was excited beyond belief – thinking that it had the potential to be the best user-programming experience since HyperCard. (By user-programming, I mean someone who is learning programming to create a specific app or apps, rather than someone who wants to be a programmer.)
My concern is that tutorials and learning materials are going to be created for programmers who want to learn how to use Codea, rather than for non-programmers who want to either just create an app, or want an easy way into learning programming. With 10,000+ Codea downloaders, I would assume that they’re not all experienced hackers (in the good sense of the word) as the forum action would indicate.
Here’s the easy way to tell it Codea is going to be targeted at programers: “Blah blah blah Codea, here’s a link to a Lua tutorial.” Here’s the easy way to tell if Codea developers want to nurture beginners: “Our tutorials teach Codea and Lua simultatneously. When we discuss code, we will help you make a mental map from Codea source to Lua source. We’ll trace the path from our libraries/framework that you see in the examples, to their source in Lua tables. We’ll map how a Lua table simulates objects, methods, and inheritance (or whatever) so you can understand modern development methods used in Codea and other programming environments.”
Codea is a fantastic effort to create a gaming ide on the iPad. However, I think an EQUALLY fantastic effort needs to be made to make Codea an ideal learning environment. Otherwise, Codea becomes just another playground for programmers.
A possibly solution is to have this step by step tutorial in the wiki. It would start by mentioning to read the getting started in the app. It could then proceed by having the person add code a bit at a time for different concepts. By focusing on “non-programmers” we also aid teachers who choose to use Codea as the basis to teach coding. That being said I won’t be the best judge of good content. I was 14 (or possibly younger) when I learned basic on a C64 (remember, there was no Internet, wikis, or tutorials (it was shortly before that time fire was discovered)).
I think it would be great if materials aimed at learning programming used Codea. However Codea’s intention has always been to be a tool for expressing ideas. I don’t want to lose that focus, but I also don’t want to alienate beginners.
My thoughts on this are as follows - Codea will continue to be developed with the same goals in mind as it started with. More beginner oriented learning materials will either come from us, or others in the community. If I spend time working on tutorials, it means less time working on Codea. It’s going to be something to balance.
That said, I plan to write some more beginner oriented documentation. And will use your suggestions to try to teach both Lua and Codea simultaneously.
Hmm - problem is, Codea isn’t hypercard. I know people might want it to be, but it’s not.
The language it exposes - the language you need to learn a reasonable amount of in order to use it to it’s fullest - is much more complex than hypercard was. It has a significant learning curve, and there’s not that much that can be done to make it easier - to promise otherwise would be to lie. It’s far more akin to processing ( http://www.processing.org ) - which it was modeled after. Frankly, a lot of the really nasty bits already have been hidden - go look at some Objective-C for the iphone if you want your retinas to sizzle right out. Nasty, that stuff.
Having said that - something hypercard-like might be an awesome application or library to make for Codea. There are some language features (persistent data) that we’d need to get in place first, but once we get that it’s very feasible.
If I knew of a better reference for the beginning Codea user other than the PIL and the examples - I’d link to it, in a heartbeat.
Ipda41001 : Fourteen years ago, at age 11, my son learned to program using Scheme, and now makes a living as a developer. He’s a lot smarter than I.
Simeon: Beginners want to express ideas too. That was kind of my point.
Bortels: Codea isn’t HyperCard but, at least, you don’t have to assemble a complex series of interdependent libraries just to get started. Processing? I don’t know why anyone thinks that Java is a basis for beginners.
While Codea isn’t HyperCard, maybe it could be what Squeak has wanted and failed to to be all these years – both a scaffolding and (Apple willing) serious development environment. As the Logo proponents used to say: no ceiling, no floor (expect Logo had a really low ceiling).
My comment was not meant as criticism. It’s just that people who are really good at something don’t usually get what it’s like to not be good at something. And I think, in the long run, you’ll make a lot more money, and have a lot more fun, by keeping your vision large enough to include novices who want to express an idea. Thanks for your efforts so far. Codea is inspiring.
@gebloom: I completely agree that Codea should be more accessible. However like I said, it’s a trade-off for us: we’re a tiny development team doing this in our spare time (mostly nights and weekends).
I would love to spend some serious time writing tutorials, but would also love to improve the user experience and fix all the bugs, while adding features. I think we just need to strike a balance, and hopefully this growing community will also provide some help to beginners.
@gebloom - Apple has no input into this - only veto. That’s a good thing - Apple is frankly developer-unfriendly in many ways, and killed Hypercard on the vine, which is a pity. Bless their hearts, the only thing they care about is end-user experience; that development might be difficult is of no concern to them. I frankly hope that the vast majority of this slips under their radar - the spook easily, and have no real interest in a self-hosted development environment.
But - I don’t see Codea and Lua, as things stand, to be a reasonable Hypercard-level replacement, even with good tutorials (which are desirable nonetheless). You’re just a lot closer to the internals, you have to do too many things on your own, even with the excellent APIs provided.
As for processing - I’m not pointing at the language, per se (I’m of the opinion that Java is unsuited to both novices and professionals) - but rather at the tutorials. Processing is what Codify’s API is based on, but it’s been around a lot longer and had a lot more users providing input - if you can follow the Processing tutorials, then looking at the Codify examples will make a lot more sense. And as fun as it is to bag on Java (I do it a lot!), the tutorial examples are similar enough that they frankly map nearly one-to-one with Codify - calling an API with “rect(10,20,30,40)” is identical in both languages.
I do want to underscore something Simeon only implies - the time of the Codea devs is probably better spent on language features that the end-user community simply can’t create on their own - persistent storage, network sockets, and so on. If there is a real hue and call for lower level tutorial stuff - and it seems there may be - someone in the user community will leap into the breach - there’s pageviews to be had, to be totally mercenary.
The problem for beginners using Codea isn’t the Lua language. Lua is very easy to learn even for one who never do any programming before. Even my 10 y.o nephew could learn it in just a few minutes. Thanks to the simple and verbose syntax of Lua. Though personally I don’t like the for-loop syntax, I prefer ‘to’ as in pascal instead of just ‘,’.
The problem is the Codea’s programming model which is based on Processing. While the model (and paradigm) is very helpful for visual/simulation/game programming, it isn’t very helpful for beginners and general purpose programming. Well, with original intention and vision of Codea, I could very well understand why they chose this programming model and paradigm. If beginners have problems with it, I think it’s not Codea’s fault. If they think Codea isn’t for them, let them find other apps that are more suitable to them. There are many other Lua scripting apps on the App Store i.e. iLuaBox, Coders, etc.
So, I think Codea devs should focus to their main and original vision. Don’t get distracted by users’ requests and demands. Of course, Codea devs should care about their users, but that doesn’t mean Codea devs is OBLIGED to give the users EVERYTHING they want, especially if they’re not paralel with Codea’s vision. Keep the focus of the development to Codea’s original roadmap. And let the community do the rest by themselves. What Codea devs should do is to encourage and facilitate the community to do their “tasks”. The new wiki and tracker is good response from Codea devs. Thank you for that.
Btw, I support paying for the novice tutorials I’m advocating, probably through in-app sales. I think first-class iOS apps are ridiculously underpriced (and I understand that’s the way it is).
