What I think is missing.

General
1

Because Codea 4.0 is in an active development phase, I would like to start this thread to talk about the features, as a user, I want to see coming to future releases.

First, I would like to mention that I am a professional game developer in a small company, and we develop cross-platform mobile game using C++.

I’m using Codea since version 2 I guess. I like it a lot. It helps me test game-play rapidly and improve my knowledge on different subjects related to games.

BUT

But, I’m also disappointed by it, and I will take the time to explain all my points.

  1. Codea is not a enough to make games.

For me, Codea is more like a game library. It provides some of the core feature that are required: a scripting language, low level access to graphics API, a project manager, a way to import and export our stuff, etc. My favorite feature is the mesh() object. It provides access to one of the needed features to create 2D games: batching. For the peoples who don’t know, it’s an approach used to reduce the number of draw calls made on the GPU and increase drastically the FPS.

Making a game is basically two big bunches of works:

  • the development of the game engine,
  • and the production of the assets used by the engine.

For this 2nd part, Codea as almost nothing.

It has the ability to import images and organize them into folders, that’s nice.
It has an embedded tool to create waveform, that’s neat.
It has an embedded shader editor. Cool but it crashes a lot.
It has a minimal text editor. hmmm.
It has AirCode. OMG don’t mention it.
I think, that’s it, and I say: “that’s not enough.”

If I can list rapidly what is missing and It will probably make no sens because Codea is meant to be used on iOS and it is limited by it. Imagine if we don’t have any limitation, in a hypothetical version of Codea that will never exists, what can it do:
UI widgets, atlas creation, auto batching, tiles editor, image editor, font-to-bitmap, module tracker, sound editor, animation timeline editor, fast array, a lot of built-in functions always used in a game, translation, virtual joypad… what else?

iOS is providing a feature that allow us to create assets from an App and import it into Codea, and it’s basically the way it should be used. The other solution is to create assets on a computer at home and transfer it to Dropbox. Sure, if you have access to a computer, why don’t you make the game directly on it? It will be waaaay more easy.

But I digress. The question is:
What Codea can offer to help users to produce assets?

  1. Codea is crashing too much.

And If I understand correctly, Codea 4.0 is targeting this issue by redoing a lot from scratch. I can’t count the number times I loose my works because of a sudden crash.

  1. Frame drops due to Lua garbage collector.

That is a serious issue. It can instantly put a project into the amateur category. My solution is generally to force calling the garbage collector every frame to make it have less work to do at each frames, but It’s not enough.

It had this problem on my iPad mini 1 and still have it on my iPad mini 4.

I hope, this will improve by the refactoring of the Codea source code. Fingers crossed.

  1. I don’t have answers for all those points and there is probably good reason why Codea is what it is. But that doesn’t mean I should not dream about something better, right?

There is two domain where game editor tool can provide features for:

  • helping the development of the game engine,
  • or helping the production of the assets.

I would like to read the feeling and comments of every Codea developers about this subject.

2

@moechofe2 I don’t think Codea was meant to be a professional game development system. Especially when it only cost a few bucks and created to run on an iPad or iPhone. I’ve used it for 10 years starting on an iPad 1. Very seldom has it crashed on me or have I lost anything, and if I have it’s mostly been because of something I did. Do I write anything big, no, do I want to write anything big, no. If I did then I would do it on a PC with everything I needed. But those days are behind me and I’m just after something that I can do on an iPad and Codea fits that bill.

3

i like Codea being minimal, although I do think development should continue, i would prefer the focus be on the native code and making the bridge from Lua to native faster. part of the joy of codea is having the basics and building up your own code around it.

asset workflow is going to vary based on your needs, i draw my games in procreate, export as psd, open in affinity design and move around manipulate whatever, export as psd again, and then use Pythonista to chop and create assets, and make data exports (size, position, etc) all on the ipad - the only thing i need a pc for is making normal maps because there’s no good sprite illuminator alternative for ipad and compressing pngs to super small sizes.

codea doesn’t have all the bells and whistles you might want to make things easier but i don’t think you need them, but the things you mention about batching is interesting - can you elaborate more? what is batching exactly and how would it be implemented?

4

@moechofe2 - I do tend to agree with @dave1707 and @skar. Codea, at the moment, is not a toy - it’s a development system based on iPads and iPhones for generation of predominantly graphic oriented apps - largely games, limited by the scope of the hardware.

Having said that - I do think TLL have missed a trick in improving integration with external kit. Air code and coding in a browser is useful but tends to crash often. Other languages, on PC/Mac’s are open to well developed code editors - the Editor in Codea has taken up most of the early development in Codea and still raises issues with each generation. It would be nice to have an import function in Codea so that you could prepare code/resources on a PC/Mac then import them into Codea on you Pad.

Alternatively - a wrapper for Codea was written years ago LoveCodea, which enabled users to write Codea code on a PC/Mac and run using Love2D. Unfortunately it was not maintained as Love2D progressed.

Maybe another option would be to use Xcode with a Codea interpreter on a Mac, or better still Codea on a PC or Mac.

5

At first, I want to say: In the minds of a thond users, there are a thond different expectations for Codea.

First, let’s talk about what I think the current version of Codea is suitable for, and then let’s talk about what we would like to see in future versions of Codea.

I think Codea is good for rapid prototyping, validation, and small-to-medium scale projects, especially for ideas that come to mind, not so good for projects that are too big, because the bigger the project, the more likely it is that Codea will crash in use. In my experience, the definition of a medium-sized project is: no more than 20,000 lines of code for the entire project, and no more than 5,000 lines of code for a single tab file. If the project exceeds this line, the Codea will become unstable (a limitation of the Lua virtual machine itself) and the code will be difficult to navigate on the iPad. For me, the best fit is no more than 500 lines of code per tab.

Next I want to talk about my expectations for future versions of Codea. Some users want Codea to be a big, full featured game development platform, while I want Codea to be small and sophisticated, it doesn’t have to be all things to all things, like a Swiss army knife, to get the basics right, and I wish developers to focus on some key basic features and deal with the stability of those modules, and try to balance performance. For more functionality, consider opening up the third-party interface (depending on whether the iOS is open) , using a mature and stable third-party module. The latest objc support from developers is a good attempt, as is @Steppers’s shared support for javascript, web assembly, moonscript, etc.

Finally, let’s talk about the difficulties Codea faces, I think it should be a shortage of manpower. There are only three developers/maintainers of Codea. Their workload is very heavy. They have to deal with the development of the new version, there is documentation to be done, and Bugs to be dealt with. As far as the Codea is concerned, I think they’ve done a very good job, which is not easy.

In addition, I learned a lot in the community, where users shared many good snippets of code(@dave1707 gives a lot of good examples), even complete sample projects(There are even more sharers involved:@Ignatz, @RonJeffries ,@UberGoober, @SugarRay, @Bri_G, @tnlogy, @blacatena, etc. so many, sorry for I can not list them all). But over time, many of these pieces of code and projects have been deposited on the forums, and it’s only when curious new users arrive that they dig them up like a treasure trove. The next step is to think about how to make the code or projects that users share in the community work better (WebRepo is a great attempt to bring together projects that many users share) .

6

I agree with some of what @moechofe2 mentioned, especially as far as the garbage collector and crashing, which happens every now and then in big files, is concerned. Not sure if garbage collecting can even be addressed, though, as that seems to be a limitation of Lua. Nevertheless, I value the simplicity of Codea as you only need to understand a few basic concepts and commands to get started.

Some more advanced functions such as APIs for particle systems and animation would be welcome. There are simple workarounds for those, so I don’t think it’s a major deal, but it would still make development simpler and quicker. Those are features that are commonly needed in games, but can easily be ignored for everything else.

That being said, Codea 4 already makes a really huge leap forward with the scene editor, gamepad support and the new runtime. Maybe some of the other ideas make it into a future version and cross-platform support also seems to be on the table, which is amazing. With built-in support for creating UIs, it might be possible for the community to build visual editors for particle systems, etc.

I’m extremely happy about what Codea 4 will offer, it seems that the update required a massive amount of work and most features that I’ve wished for Codea to have, are already a part of that. Judging from the features we know of, the developers have done a fantastic job.

No doubt, Codea’s biggest strength is its simplicity and I agree that whatever features are added, this concept shouldn’t be abandoned. But more tools or advanced functionality that can be used if needed or ignored if not, probably won’t bother anyone that values simplicity and will be of use to some of us. The new scene editor is a good example: I don’t need it for my current project, so I will ignore it while working on it. But it’s great to know that it is there and for future projects of mine, I will definitely look into using it. As long as Codea remains easy and fun to use and especially as long as the developers see value in it and aren’t overloaded with work, a new feature is always a great thing to have.

Regarding the long-term future of Codea: Codea doesn’t need to become a fully featured game development platform, I think those expectations are unfair to the developers and would go against what many users expect and like about Codea. I definitely understand and agree with that point. However, there is also a portion of users that would like to create apps and games with Codea (which is already absolutely possible!) and would profit from more functionality, tools, better ways to organise and view assets and a more stable editor for larger projects. I believe that other users would benefit from many of these things as well. Codea 4 already addresses many “issues” that game developers face with Codea 3, regardless of whether the developers focused
intentionally on that group or not. At the end of the day, though, I think we all will profit from the new features and that’s a great thing!

And maybe an even more capable Codea could attract new users.

Edit: And it would be absolutely fair if some of these features would cost extra. I’ve been using Codea for almost a decade now and would love to support the developers.

7

@moechofe2 @binaryblues @Elias I am not too sure the garbage collector itself is to blame here.

In my experience, memory issues have primarily been caused by loaded graphical assets. Due to the nature of Lua it can often be tricky to ensure that an asset is de referenced everywhere. If a single (non weak) reference remains then the resource will not be freed.

Unless you’re doing large data processing tasks you’re unlikely to hit issues with plain lua values.

I’ve worked on a few large scale mobile games in the past and each has hit memory limits on iOS at some point. As a result, each game has utilised ASTC texture compression to greatly reduce the memory footprint. It’s surprising just how quickly 32bpp RGBA8 textures can fill an apps available memory. 4MB for a single 1024x1024 texture vs 64KB as ASTC!

8

My uses for Codea is just for fun. I’m not after writing a game to be put on the App Store, so the way Codea works now is perfect for me. I’ve mentioned several times that I’ll write code while I’m watching TV. I’ll grab the iPad and check the forum to see if anyone has questions about anything (or to remove spammers). If there’s a question to be answered or an example to be written, I’ll do it while I continue watching TV. I have no use for an external keyboard or to write code on a PC and transfer it to Codea. Everything I need is right there in Codea on the iPad. I believe that was the initial point of Codea, something simple yet powerful enough to be useful on the iPad. I think trying to add more and more external support of things to Codea just causes more problems. Like I mentioned way above, I don’t have crashes or loss of data (unless it’s my fault) because I use Codea as is without external keyboards or extra large code. I’m not sure if I’m in the minority or majority when it comes to Codea. Is everyone trying to use Codea to write code for the App Store or are they just using Codea for the fun of coding.

9

each game has utilised ASTC texture compression to greatly reduce the memory footprint. It’s surprising just how quickly 32bpp RGBA8 textures can fill an apps available memory. 4MB for a single 1024x1024 texture vs 64KB as ASTC!

@Steppers is this something we can implement in codea? if so, how? i would love to use any tricks possible to improvement performance in my projects

10

@skar Not on the Lua side unfortunately. This would need to be done on Codea’s backend to support a different texture format. Functions like image.set() would also need changes to ensure texture conversion is done correctly if at all in those cases. Chances are it would be easier to change a loaded texture to RGBA8 if it is modified.

You have a valid point on the performance side actually, as the textures are smaller it reduces the GPU bandwidth required so actually speeds things up a little too :smile:

11

All your point of views are interesting. Thank you all for joining the conversation, and it seem we all use Codea for a different reason and with different flows.

@skar, about batching:
If you have 2 sprites that use 2 separated images as texture, then you’ll get 2 draw calls on the GPU side. But if you join these 2 images into a single texture and use 1 mesh() object with 2 addRect(), then you will have 1 draw call. The performance gain is increasing with the number of sprites you can manage to group into a single draw call.

I’m also using another App called lowresnx that I’m using to create games. It’s a fantasy console like pico8 but it works on iOS, and it has all the tools needed to complete a game: images, tilemap, sound and music can be (as to be) made directly on the App without quitting it. This tool is more limited, but the goal to makes a game too.
I particularly love the way custom editor can be added to the tool, you just need to code a program, for instance an image editor, and then register it as custom tool, and then you can use it inside your project to edit your assets without quitting your project.

It’s actually possible to code an image editor in Codea (I already did one) but the flow to import/export/move produced assets is limited or difficult.

About fantasy console, pico8 is a great success because it can attract developers but also artists, and they manage to create contents that can please other artists that join the community.
There is also “Castle - Make and Play” that is full featured. Give it a try.

12

@Steppers Thanks for the info, that’s interesting! However, since I’m mostly using pixel art (in the range of 24x24-32x32) and I’ve seen issues with memory when e.g. spawning many particles, which is heavy on CPU, I don’t know that’s the issue. Certainly, optimisation can help a lot here, but as a single developer there’s only so much time you can spend doing that.

@dave1707 I don’t know whether you are in the majority or minority, but I guess many people use Codea for the exact same purpose as you do (and I fell into that category, too until a few years ago). Also, because you mentioned helping out on the forums: Your help is really valuable and appreciated!

I think more (optional) features won’t change what Codea is now and I don’t believe they will introduce more problems. In fact, many (possible) new features like a debugger solve issues for everyone.

I absolutely understand that everyone using Codea for small prototyping projects don’t want Codea to change into something else, leaving its simplicity and ease of use behind - and I definitely agree with that! But take gamepad support, the scene editor, maybe a debugger or built-in support for UI as examples for what Codea 4 will offer - or even take a look at Craft. These features are all amazing for everybody working on larger projects or games, but if you’re just quickly prototyping something for fun, you can ignore them. Also, not everybody has an iPhone or iPad and I think cross-platform support to share a small or large project with people using a different type of device seems nice to me.

At the end of the day, I think it really comes down to what TwoLivesLeft want Codea to be.

13

@Elias fwiw this is available:

collectgarbage(“count”) ? Returns the amount of memory currently used by the program in Kilobytes.

14

for what it’s worth, in my experience running the garbage collector every frame is a huge performance cost, it’s better to just let it do its thing normally, but you can also slow it down using some additional commands - https://www.tutorialspoint.com/lua/lua_garbage_collection.htm

slowing down the collector would probably not be a problem since ipads and iphones have so much ram now

15

@moechofe2 @dave1707 @skar @Bri_G @Steppers @binaryblues @Elias Very helpful to see all the different perspectives on Codea

@moechofe2 I’ve been considering the idea of editor extensions for a while now, but I haven’t landed on a good design for that. One idea was an “active-tab” which is a tab that can be run in the project which can display an editor inline. The other idea was registering custom editors for specific types. We have a system for that now when you click on an asset in Codea 4 (like the built-in model viewer is just the runtime loading a script). This could be be exposed to the end-user which is something I really want to have

16

As for garbage collection issues this is a bit out of our hands (in the sense that it’s an issue with Lua) but we also made some conscious API design choices which have impacted this. Mainly things like vec2/3/4 classes will generate new objects when applying operators (±/* etc…) so this will quickly create a huge number of garbage objects

My solution to this would be adding some static functions like vec2.add(v1, v2, result) that lets you perform vector operations that do not generate garbage. Anything that returns a vector type though will still generate garbage. Some ways to avoid this might be a garbage-less alternatives like vec:set(entity:getPosition()) where getPosition() returns x, y, z as multiple values and vec:set(x, y, z) updates the vector.

Basically the garbage collection issue is a tradeoff between performance and simplicity. Unfortunately Lua does not have the concept of value types so we can’t offer both performance and ease of use ;-;

17

@moechofe2, thanks for starting this discussion! I believe the discussion touches on the key points of what has made and what will make Codea a powerful and successful IDE/SDK/API (will defer to @John as to the proper terms): the features and ease of use it provides its users. However, like @binaryblues mentioned, users have multiple ideas for what they believe would make the app more useful or should be included as features. Like @dave1707, I primarily use and program on my iPad because I am a long-distance commuter (non-computing professional). However, perhaps unlike dave1707 and others on this thread, I program in Lua because I am a novice programmer, and Lua’s syntax is easiest for me to remember and use (having growing up programming in BASIC in Silicon Valley in the 1980s). As my daughter is into art and 3D graphics, Codea is one of only a few IDE/SDK/APIs I know that allows me to write Lua code on the iPad that can work with complex 3D objects (others include LuaStudio and LuaTouch, but neither are as well developed as Codea is).

Yet, I believe the real strength of any coding ecosystem is its community members. @binaryblues already touched on the strength of the community (many members on this thread have personally helped me bring some of my 3D demos to fruition) and the responsiveness of @John and the other developers to the interests of its members. However, I believe that business/user collaborations also drive innovation and success of IDE/SDK/APIs like Codea. I’m aware that there are or have been other Lua 3D development applications (LOVR, http://lua-users.org/wiki/LuaGraphics), but I don’t believe any of these are available for developers to use to develop on an iPad. Thus, I believe that Codea is in a unique position to lead in helping developers create graphical Lua projects on an iPad. Being able to cater to the key features and ease of use desired by both professional developers like @moechofe2 and casual users like myself, I believe, will ensure Codea’s continued growth and relevance. Like @Elias stated, I think cross-platform support would be beneficial, and I would also be willing to pay for additional features.

18

@John I like this idea of the registered custom editors, it will perfectly fit my needs. We will ned an API to access the edited ressource, or better the name of the project so the editor will have access to whole assets.

19

Just two thoughts:

On garbage collection… so, after programming for literally 50 years, for fun and profit, every language, platform and project faces design constraints and trade offs. I usually discuss this with my developers in terms of trade-off triangles. For example, consider, the three restrictions of time-to-develop, functionality, and performance. You can write the most functional and high performing game in the history of ever… given unlimited time. Or you can write a game with everything you want it to have in a reasonable amount of time, but it will perform poorly (slow, crashes, etc.). Or you can write a game quickly that runs great, but isn’t very interesting.

The usual real world path is to balance all three… write what you can in a reasonable amount of time, with reasonably interesting functionality, but no more than will run well in the environment (software, language, developer tools, hardware platform) for which it was built. If it runs too slowly or is taking too long, back off on the functionality. If you have a performance problem, put time and thought into working around it, trading time and/or functionality for the needed improvement.

Given that, the solution to any memory management issues in Codea is to make trade offs. Lower your resolution. Reduce the number of objects (do you really need 4,000 individual particles to render an explosion?). Put serious work into managing garbage collection yourself (use weak tables, make absolutely certain you haven’t forgotten the “local” reserved word and inadvertently used a global forever-variable, research using shaders instead of lua code for some tasks, etc.)

The original animated video games like Dark Castle would have just one animated “background” object, such as a flickering torch, that only had two frames in its flicker animation. Wolfenstein 3D managed to do a first person 3D without OpenGL or a GPU or anything else, and in a microscopic memory footprint. The developers succeeded by working within known constraints.

So, what you make is part of the skill of recognizing what you can make, and executing within those limitations.

Now, that said (second thought, here), I think the greatest value in Codea is that those limitations are relatively manageable and only fractionally limited due to the broad functionality Codea offers. There’s virtually nothing you couldn’t make with Codea, as long as you are willing to refine your approach just a bit to stay within what limitations Codea does have. Consider the example of loresnx. It is great for doing really, really tiny, side scrolling (maybe top-down) 8 pixel games of very, very, very limited complexity. The only advantage is that it does so much for you, you don’t need to find other tools (like a sprites editor) and write a lot of foundation task management code (e.g. loading and organizing sprites from images). So it makes it easy to write games by taking away a ton of capability. On the other hand, there isn’t a single game I’d spend time developing on loresnx, because it’s just too limited.

IMO, Codea is a fantastic middle ground. With occasional unexpected roadblocks, I can make it do just about anything within reason, or adjust my reasoning just marginally to fit within Codea’s limitations.

MY ONLY REPEATED COMPLAINT about Codea is that because you do have to write a lot of foundation code, even the simplest project can be huge… and good, object oriented code has a lot of very small classes — failure to adhere to this principle is the usual source of bad, difficult to read/remember, difficult to modify, and buggy code. Codea really desperately needs, beyond anything else, a project-folder structure. Without that, all of the new functionality and everything else can’t (IMO) really be used, because no matter what, the project quickly becomes too large to be manageable. I’ve overcome that somewhat by breaking my code into subprojects and using dependencies, but its really annoying to have to switch projects frequently just to look for what I named a class or function or what the parameter sequence is (I’ve discussed elsewhere the utility of getting in-editor hints for parameter lists for programmer-designed, not just built-in, functions and methods… basically, a JavaDoc style approach to letting the developer add annotations in comments that provide what Codea needs to provide hints while editing).

If the only way to get a nested project-folder-file structure is with Codea 4, I cannot wait! Is there any projected delivery date for that? Or for access to the beta? [And when the beta is released, will it live in it’s own world, so we can export/import existing code, without risking getting it corrupted by instability?]

20

Ooh! Ooh! New idea… okay, rather than a complex, time-intensive, “JavaDoc” style editor-hint structure, what if:

All functions and methods (only) are kept in a table, with pointers to their “start line” in the code (file/link number).

Have another side-pane (like Reference, Find, Assets, Dependencies) called “Code Helper” (or whatever). Like autocomplete, when a user is writing or positions the cursor within a .xxxxx or :xxxx bit, maybe even when the first “(“ or “{“ is included (marking that the function name is complete), if the “Code Helper” window is open, list all functions/methods of that name (with the enclosing file name or class name). Touching a name in the list (just like in Reference) opens up a non-editable view of the code for that function, starting from the first comment prior to the actual definition of the function, and continuing to the “end” statement. This makes the comments and parameter list readily visible, as well as further code in case inspection is necessary (I obsessively comment functions and variables, so this would work well for me, and would encourage others to do the same).

Because this leverages the existing “Reference” side-panel structure, it might be easier to implement.

This approach eliminates the need for any “context sensitive” funny business, or tracking anything at all besides function/method names explicitly associated with function (reserved word) definitions. It should be easy to implement and perform well, while providing enough functionality to be immensely useful in larger projects (see “trade-off triangles” in the comment before this one!).

[You could take this farther, like by adding a “search” box to the panel, to filter results or find specific lines within a currently-displayed function/method, or by doing some context-sensitive stuff, like recognizing that self:something() will be “something” in the current class, or that myInstance:something() will be “something” in whatever “myInstance” is, if that can be inferred from the nearby code. Of course, all of this adds more useful-but-not-necessary functionality. It’s nice, but not needed. The basic plan of “track function names/recognize via the .: then xx then ({ form, display in sidebar” is more than adequate.]

[You could also expand this to include fields, not just functions, but that gets trickier, especially if inheritance is involved. Personally, I’ve learned to feverishly avoid writing direct references to table attributes outside of its own class; I always write and use getters and setters, so I myself don’t need this, and would be motivated to avoid breaking my own rule if a getter appears in Code Helper but a field does not. Yes, it’s a bit more work to write getters, and yes, in theory there’s a tiny performance hit, but the advantages of making the code safer and more extensible and modifiable always wind up trumping that momentary inconvenience and puny performance hit.]