Every noob who wants to make a command prompt? :p (And that one guy that actually wants to make a game too) I might even use this to cleanup my Lowerdash compiler... (if I can solve longest match...)

This isn't even Lowerdash! Texty is pure basic (for now)

Here's Texty! I guess I just wrote a tiny framework for text-based games. Texty lets you specify possible inputs as interpolated regular expressions that point to DEFs. THAT MEANS IT CAN RECOGNIZE MANY SENTENCES FOR THE SAME ACTION! This is very much an experiment, but I'd like to explore this idea more in the future. key: B233F3GJ

A wave is a great idea! I'm piggybacking on native SPHITSP, so a circle might not be possible... I'll give it a shot. I wonder its time to start doing ARYOP...

Maybe because I arbitrarily spawn the asteroids first :p I didn't add a lot of detail, but conceptually, I think I have the right order. My game involves multiple teams, each spawning new ships in during gameplay. When those ships spawn, the rest of the world already exists. My solution of randomly jumping both 1. can get infinitely stuck 2. is jarring in a dense field of clutter

What's the actual error / symptom?

I guess I can just randomly teleport ships when they're constructed...

Oh... That is a terrible spawn... Anyone have any input on the best strategy to avoid this? So far, intense wiggling is ineffective. (wiggling the physbody for a few frames and check collision)

One thing to note: Lowerdash is a superset of SmileBasic! Loading a background is the same in Lowerdash as SB: ''' BGLOAD 0, BGDATA ''' With Lowerdash, you might make a module "Level" that does that same code in a method 'start' that also sets up coins and stuff. Later you could just write: ''' curLvl = new Level('level name') curLvl.start '''

Yeah! I can hit the sprite cap!

I thought those rocks were a clever censor... Seen here: buttery 60fps performance! Not seen here: Endless space and the 80 or so randomly distributed asteroids; one of which hit something. (Also I drove my ship into another one in the same frame)

@Raimondz: I was aware that could happen, but I didn't realize I could just keep calling SPHIT(). By post-poning collision until all sprites are resolved, I at least guarantee some hit happens to each. What I'm curious about is how I would manage the memory around multiple hits. Each call to 'Hit.bind' allocates memory for one collision. How many collisions do I really need to preallocate?

Whoopsy!

There is indeed a massive reference manual on SmileBasicSource. I've also attempted to walk through my object-oriented design process in a tutorial on there. Of course, I managed to overcomplicate it :p. I hope to try an even simpler guide soon. What kind of tutorial would be most helpful to you? Do you need to see a game in motion?

Peeps might recognize this technique from all my physics demos. The difference this time is that behaviors are coupled to sprites - physics calls SPOFS directly. This is in contrast to each entity polling physics for a position in an update method.

Callbacks? In my BASIC?! I manage all sprite collision through a single object operating on plain arrays. When two things touch, their "onHit" method is called. Anything not actively being controlled by a player or AI doesn't require an update! THE SAVINGS!!!

Like all of Lowerdash, the method name still has to be looked up. But you don't pay for any heap operations. Well... unless you use the heap... (me._sp% lives there) So... I guess exactly the same speed as before? The speedup really comes from being able to couple behaviors to sprites through the much faster built-in SP* operations. Physics etc. doesn't need to talk to individual objects.

Using Lowerdash virtual methods to abstract away SB sprite code. This is super fast, and can be inherited by sub-classes! e.g. ''' module tomato proto sprite end ... myTomato.rot = 90 ... '''

I heard we were supposed to make games about "industry", so I made a factory for my factories...

aka: the one where I forgot to put Lowerdash in the OP...