Really hope that everyone has been enjoying the #wdc as much as we have. One thing I’m keen to avoid as much as possible is the weekly challenges becoming “chore” or folks feeling like they have to participate in every single one.
With that in mind we’re trialling a new tri-weekly schedule for the next few challenges to give you better visibility and choice around how you spend your time in the Community.
Broadly speaking, we’ll rotate between an app (re)design challenge, a game development challenge and an open forum for users to share their own apps and experiences with the building and publishing process.
The premise is pretty simple - take an existing mobile or web app and use it as inspiration to create an app of your own. It’s interesting because the main limit is your own imagination. There is no one “right” way to build an app with Thunkable so entries can have similar appearance or functionality and be built in completely different ways. By sharing our ideas with the rest of the Community we can quickly get feedback on what’s working or suggestions for improvements and new features.
Weekend Game Jam
Similar to the Weekend Design Challenge but aimed at gamers, gaming enthusiasts, and game developers as a forum to showcase their unique skills. The aim is that the #WeekendGameJam will be a place for even more users to contribute to the Community and at the same time offer our regular contributors an opportunity for either a “rest week” if they want or a new type of challenge if they prefer.
Show Thunkable
Every third week we’ll make a #creator-lounge topic called “#ShowThunkable”. This is a space for users to show-and-tell us about their apps. Since everyone will be at different stages in the journey (designing, testing, publishing etc.) it gives users the option of either sharing what they’ve already built or to share their goals for their apps, i.e:
“I want to get my app published by the end of the month”, or
“I’m trying to find my first 100 users” or
“I built this app for class - should I keep working on it?” or
“I’m doing a full re-design of my app’s UI, what do you think of this?”
Of course it’s not a chore, at least for me! I’m enjoying every bit of the #wdc’s ! I’ve said it before, and I’ll say it again: Fridays are my favorite day of the week because of the WDCs. The tri-weekly schedule seems great. I also like the idea of #ShowThunkable. Can’t wait to get started on my travel-themed app this week!
Excited to think about Plant Nanny as a theme for this weekend’s challenge. It really has me a little stuck, though, because a game like that should be played in landscape orientation. I know it’s possible to preview a Thunkable project in landscape but I don’t think there’s currently a way to Design in landscape… is there?
I had last week’s Poodle Doodles game (built with the snap to position interface) working on phone in landscape and on the web previewer in portrait, but it was a huge pain the butt, since I was basically designing blind. Of course, since I was cloning, I was basically working blind anyway…
How do you preview in landscape? (Besides in Thunkable Live?) Am I missing a good trick?
Nope, just in Thunkable Live. Agreed, it’s not worth designing in landscape when you have no idea what it’s going to look like until you see it on a device.
I might be thinking of a different app? This one looks like it’s designed to work in portrait mode:
I suppose, the essence of this challenge will be to create a habit tracker, for logging data, but ideally one that give some nice visual feedback of the growth that’s happening as you maintain your habit too
Also really hoping the spawning and motion bugs can be resolved. I don’t think I can work on this challenge (edit: thought this was a bit different – see my next post) without having accurate positioning for sprites. Sigh.
Here’s a demo I made today that shows the problem. The initial “create Enemy” block should place the sprite at x=0 but not only does it not do that (@jane confirmed that sprites’ positions values are determined by a sprite’s top-left corner when ideally, at least as far as I’m concerned, they should be the sprite’s center)… it also “shoots” the sprite about 100 pixels to the right immediately after it’s created. The sprite has a speed of 1 (1 pixel per second, I assume) so it should move very slowly the whole time.