Regarding coroutines, I am writing some material that builds on and supplements what I mentioned during the show, including some new stuff I didn’t get to include in the sample code. If all goes well, that shouldn’t be too long coming.
@atrizhong:
I only allude to it in the same material, but I’ve tended to use coroutines for AI, where each enemy, say, runs inside its own coroutine. This is certainly concurrency, but I don’t know if that’s what you have in mind. Unfortunately, I don’t have anything distilled down to a small example just yet.
As for the show, a few topics come to mind:
-
Lua 5.3 just became final today (what’s new). That’s topic fodder in its own right, but it also invites some speculation about Corona: if / when other language versions (or languages!) are added, how would it be done? What breaks? Does the version become an option, or will it be mandatory to update, and what does that mean for modules?
-
For all I know it’s been covered already (although I imagine few topics will ever be declared “settled”), but I would find it interesting to see guests who have worked in localization or writing for games. On localization at least, there are also some development issues; a few people have made stuff for that, but I can’t see whether it’s widely known.
-
There’s probably a good segment or two just dealing with ergonomics / fitness / nutrition, given how sedentary most development is. Then again, I have a hard time imagining such a show not being awkward. :)
-
I often watch longplays, usually of older games, while I eat or whatever. Now and then while doing so, I’ll start noticing stuff about the game’s design. “Oh, they did that because you might show up here without that item, and still need a way out.” “They put that thing there so they could blow it up later, and it would be cool.” “They put those limitations on the assets, since it still lets them do something impressive in spite of the old hardware.” (Hello, parallax on the NES.) Anyhow, I wonder if that would be interesting from a design point of view. On the downside, it would probably be difficult finding a good, short game, and there might be a lot of dead air besides.
-
The art of making custom widgets…
-
…and editors…
-
…and save file formats.
-
Debugging. Tools, strategies, diagnosing error messages, etc.
-
Math. As a developer, you’ve probably left (or soon will) the ranks of the “I never used that stuff once I left high school!” crowd. But you may not have developed an intuition for it, nor know how to put it into practice; seeing it translated into something visual might provide that “Aha!” moment.
-
Optimization. Has been touched on in past shows, of course. Further exploration:
* Caching, e.g. recycling tables and coroutines, keeping invisible images waiting in the wings, etc.
* Memoization: Caching meets function calls. Save the output of an expensive operation. When called with the same inputs, reuse the result.
* Dynamic programming: Unsure how to summarize… incremental algorithms, I guess. Often depends on stuff like memoization.
* Amortization: Spreading costs around.
* Laziness. Put off work if it doesn’t need doing… you might never need to do it at all. (Note: actual CS concept, not real-life advice. :))
* “Big O” notation and complexity analysis: Studying how a problem scales (run time, memory use, and so on).
* Approximation: Turn a hard problem into an easier, “good enough” problem, and solve that instead.
* Using better data structures / algorithms.
-
With respect to that last bullet, there are also approximately 39483940 other interesting ideas in any algorithms or data structures text, just waiting to solve somebody’s problem.
-
Design patterns.
-
Domain-specific languages.
-
Functional programming.
