TL;DR

Please name one or more features of Corona that new users use today (perhaps incorrectly or unnecessarily) to solve game dev problems that used to be solved 'manually'.

 

 

Intro
I was answering emails and forums questions today and it occurred to me (as it sometimes does) that today's game developers are incredibly spoiled (for choice and solutions).
 
I mean that in this way:

• In the old days of game dev (late 70s early 80s for me), we as game developers had no game engines, etc. etc.
• At the same time we had to solve many of the same problems: animations, movements, collision detection and response, sound ...
• Additionally, we had extremely limited resources and CPU cycles to solve these problems with.

I am no complaining, but rather this got me thinking about how to better introduce new developers to the art of game making.

 

 

The Question

"What are the biggest hacks used by new users today?"

 

By this I'm asking, "What feature or features of Corona do new users go to in order to solve a problem that used to require hand-coding?"

 

 

I am specifically looking for cases where the new user has turned to a feature because it is easier to use the feature than learn to solve the problem correctly.

 

 

Final Note

This is NOT a complaint thread.  I am really curious what other older/experienced developers think about this.

 

I sometimes feel bad for new folks because they get to skip the learning and hard bits.  This gives them a huge head-start but often leads to a big crash later when they encounter hard problems. 

 

Thanks!

All I can think of at the moment does not have to do directly with Corona SDK's features itself but is related to it.

 

A lot of users may end up looking for "plug and play" code samples. Samples that may have been written under entirely different conditions but newbies may attempt to directly force into their projects. Now I am not that experienced, but I have seen this happen. (my ineptitude at vector mathematics)

 

Now I can only imagine how programming was like in the "early days" as I like to call it. I was not even born to see it for another few decades, but I would presume that if I were to program something like a tic-tac-toe game in the 70s or 80s with those resources you spoke of and then come back to Corona, it would probably feel like heaven-on-earth. 

The only thing I can think of (off the top of my head) is the built-in physics engine.

Without that I'd be stuffed.

"Ahh... Just write you own!" they say.

 

Pfffffff!!!

i'm from the time even to do a simple concatenate we had to do it manually not "hello ".."world".

 

more like this:

#include <stdlib.h>
#include <string.h>

char* concat(const char *s1, const char *s2)
{
    char *result = malloc(strlen(s1) + strlen(s2) + 1); // +1 for the null-terminator
    // in real code you would check for errors in malloc here
    strcpy(result, s1);
    strcat(result, s2);
    return result;
}

that was in another life, and I pretty much forgot C all together. but the foundations are there and thinking how to resolve a problem when I encounter one is like breathing. when i encounter newer and younger programmers, i notice that they take ages to understand the way to resolve a problem. that just means they don't dont fully understand the language. They just know how to use certain functions already made from anothers. It's normal in my path working and talking with other programmers, tell them how to resolve their problems, even in languages i don't know. they just lack basic "algorithm education".

 

Regarding of your topic, I think Corona all together is a big Hack. all functions are way shorter versions than native ones. Corona spoils us. 

I'll respond to my own post now lest I forget to later.

 

To me, the #1 hack new users make/use is the physics system.

 

I frequently see new developers using physics when they don't need to and often to solve a problem best solved in another less expensive means.

 

i.e. Instead of learning to solve the problem at hand, they use a side-effect of the physics engine to solve the problem.  

 

At the end of the day, I think new devs treat the physics engine as a sort of 'swiss army knife' of solving things.

At the end of the day, I think new devs treat the physics engine as a sort of 'swiss army knife' of solving things.

 

I almost fell into this trap a few weeks ago because of collisions when in reality all I needed was a super simple overlapping rectangle function.

 

(   And I would have gotten away with it if not for you meddling kids!  )

Maybe not quite on topic but i get the impression many are looking for code snippets to copy and paste without neccessarily understanding that code.

Then when something goes wrong, ask for help on forum without checking out the documentation, which may not even be helpful since they dont understand the code in the first place.

I only wish i had a dollar for each time i say, please read the documentation 😀

It may feel nerdy and slow, but studying the corona documentation helped me tremendously, and i personally dont use code snippets from the web, but instead study them to figure out how to write my own stuff. I believe it is better in the long run and hopefully makes me a better programmer, albeit slower st times 😀

Forever more to be know as the 'Cut-Copy-Paste' Hack.

 

Maybe not quite on topic but i get the impression many are looking for code snippets to copy and paste without neccessarily understanding that code.

Then when something goes wrong, ask for help on forum without checking out the documentation, which may not even be helpful since they dont understand the code in the first place.

I only wish i had a dollar for each time i say, please read the documentation

It may feel nerdy and slow, but studying the corona documentation helped me tremendously, and i personally dont use code snippets from the web, but instead study them to figure out how to write my own stuff. I believe it is better in the long run and hopefully makes me a better programmer, albeit slower st times

I'll respond to my own post now lest I forget to later.

 

To me, the #1 hack new users make/use is the physics system.

 

I frequently see new developers using physics when they don't need to and often to solve a problem best solved in another less expensive means.

 

i.e. Instead of learning to solve the problem at hand, they use a side-effect of the physics engine to solve the problem.  

 

At the end of the day, I think new devs treat the physics engine as a sort of 'swiss army knife' of solving things.

 

Do you mean "collision" as a side-effect?

No, not exactly.  In this case the detection of and response to a collision would be side-effects that a user might use to solve some other problem.

 

I understand your question, but to clarify, a collision is not actually a stand-alone concept in games.  More exactly, you have collision detection and collision response(s):

• Collision Response - Bouncing, friction, pushing, rotation, etc.
• Collision Detection - The engine determines there was a collision and does something like call a listener.

 

Example of Misusing Physics

Sensor objects have no response and allow you to detect when two or more objects overlap.  While perfectly valid as an overlap test, it isn't suitable to that purpose in all cases.  Such a test (overlap) can also be done using very simple and relatively low-cost math equations.  

 

A new person may decide that using physics sensors for overlap testing is the best and easiest way to achieve their goals, but then get in trouble when they have 500 physics bodies floating around.

 

The right solution in that case would probably be an elegant piece of code that does the test with math and limits what bodies get tested using some simple rules.

Edited by roaminggamer, 04 August 2018 - 07:53 AM.

I've got a couple of anecdotes to add to this.  

 

1. Using Physics to detect if two objects are overlapping.  I never understood why people would include physics just to get collision detection. It took several years of using Corona and being part of this community for me to understand that the main benefit is that it's event-driven which is more Corona like behavior, but still doing a simple bounds check to see if two objects are overlapping has way less overhead than running the physics engine if that's the only physics parts you're using. Which is a good segue to: 

 

2. Many will never know the value of "Unrolling loops".  Back in the day, CPU cycles were so precious, it was too inefficient to write:

for (i = 0; i < 8; i++) {
     setPixel(x + i, y, color)
}

instead, we would unroll the loop

setPixel(x, y, color)
setPixel(x + 1, y, color)    
setPixel(x + 2, y, color)    
setPixel(x + 3, y, color)    
setPixel(x + 4, y, color)    
setPixel(x + 5, y, color)    
setPixel(x + 6, y, color)    
setPixel(x + 7, y, color)

The added instructions at the machine level to run the for loop was significant and too costly.

 

Today, people don't even know what blitting was, just draw the sprite at x and y and have it animate for you.

 

Rob

Ah, the physics system is indeed a miraculous one  I know for a fact that when I started using Corona, I used it too liberally without even considering simple and lightweight math only solutions.

Physics is definitely high on the list, but I'd also like to suggest using the Amazon GameCircle, Apple Game Center and Google Play Games Services for creating online leaderboards or achievements. Without those plugins, you'd also have to setup a server and write the server-side code, which meant having to know things like PHP and MySQL in addition to lua.

On this note, think about plugin(s) like Photon. Oh, the horror of setting up a small or large scale real-time multiplayer game by yourself, but with plugins like that, it's somewhat easier 

Of course, with all cases, if you would set up the leaderboards, achievements or multiplayer by yourself, you'd definitely come up with more creative and lightweight solutions.

Man, computers move at such breakneck speeds compared to my Atari 800 that my old Atari Basic methods that I only dreamed of being able to implement back then handle with ease 30 years later on a modern device! 

 

Game stuff is no problem for me. The hardest part for me by far is maintaining all the deployment minutia. 

I had an Atari 800 too. Life was really different then.

Such fun times! And the mechanics are the same. A solid game loop is the most important thing in a game. 

Oh, yeah to answer the question... I don't know many new users especially since the irc went silent. (#freenode #corona btw) but I do know these two fun hacks:

 

1.Get really good at breaking your game.

 

Break:setSequence ("Break") 

 

There is no object named break. or even a sequence like that. But it lives nicely in the code until stumbled upon. I think they called this 'Forcing an exception' 'Throwing an exception'... back in the day? 
 

So that way I can force an error and know that it got to the point I was working on. If it skipped it, I can understand that it leaped passed it. Some people even get more advanced and hook listeners on there to throw it in a sort of suspended animation and also print extra garbage. But I usually just do my print checks before the break.

 

Also 

2. Listen to your code work correctly.

 

Before I even had a sound engine with tracks working, I would fire off a sound at various parts of the code and there was no way I was going to find it in terminal with a print output. 

 

Also really helps you discover if you are firing things multiple times without knowing it.  Also there are good chances you will want to keep the sound effect, change it later, etc.

What I would most like is "break, edit and continue" like .NET has.

 

The ability to modify variables at runtime would be amazing.

@SGS

 

excellent suggestions!  Those would help so much in testing and debugging.

Isn't this possible using Zerobrane already? I've only evaluated it quite some time ago but it had a debugger and a watch option and I'm almost sure you could modify the watches too.

Physics engine as a swiss army knife - that's me!  I use it liberally everywhere but had to develop some optimizations first.  Now I can get thousands of physics bodies playing nicely together with sensors galore!  Eventually I go back and do "real" coding but being able to mock everything up in the physics engine is an amazing ability.

 

Plugins from the marketplace are like super snippets and I pepper them all over every project as well.  However, there are some things that you really have to roll up your sleeves and dig into like elaborate touch controls for an app - there is no short cut for that but we are still a long way from Atari BASIC 

 

Object oriented principles in general are a world away from my Atari 400 and my Atari 520 ST - so far that I can't even compare the experience really.

Definitely have to say the 3D engine.

 

One specific to Corona is the group layering - or even the whole Graphics 2 engine which Corona Labs have built. Simply Amazing!

 

One specific to Lua (ok, all languages these days) is string manipulation. Yes, most languages could do this forever already, but 20+ years ago it was a huge NO-NO to use strings the way we do today. It was simply too memory and CPU intensive, so ALL DATA got squished to fit into the tiniest amount of space possible.

 

In general: Network libraries. This was also possible for a long time, but the resilience and ease of use these days is nuts compared to 25+ years ago.

There seems to a few people from my generation lol

Programmers today do have it easy, I was self taught and my first language was machine code, I would write the instructions on paper and convert them to hex bytes and then type the numbers in and run (with fingers crossed), I had to use tape cassettes to back up anything I did and they couldn’t always be relied on so I’d have multiple tapes, just the fact today you can type code, hit run and get instant feedback, change something hit run again is the biggest advantage you have today. Of course as time went on programmers found ways of speeding up the process but new equipment was so expensive that it wasn’t always feasible.

Don’t even get me going on something as simple as printing an image or animating a sprite, nowadays all the hard work is done for you.

I remember having to write a color bar generator on a machine that had 2 colors per block, the only way to do it was time the machine language instructions perfectly so that by the time the scan line on the TV hit the next line you changed the color.

Looking back on it I enjoyed the delving into the machine and seeing how it worked, but little did I know it was setting me up for a career that has now spanned *cough* a long time. Going through that learning process helps me solve problems far quicker than some of my younger counterparts.

Ok I ramble and a lot of people here will probably not understand half of what I’m saying (what’s a cassette tape?) but today’s programmers don’t realize the path of their predecessors that has made it possible for them to do it today at speed.

Oh there are quite some who used tape drives on their 8bit machines

 

One great thing about this to me is, that there's not only those who managed to get into high positions in AAA studios (I sometimes feel like a complete failure because I'm still doing the small scale stuff)

Haha, same feeling as many of the other posters here: I started out on a C64, drawing sprites in notebooks of grid paper and calculating the hex values for each byte - no graphics software whatsoever! After some dabbling in Basic I tried my hand at machine language (load accumulator, stack accumulator), but that proved too difficult for my young age back then. Still, the seed was planted!

 

After that I had an Amiga 500, probably the most advanced computer concept at the time. It was so versatile and powerful for it's time that even years later I had problems understanding what PC users were trying to tell me about their new multimedia cards, from the Soundblaster / Gameblaster era. Most of my conversations were along the lines of "So the SoundBlaster add audio capabilities to your PC? But what did you use before the SoundBlaster then?" Same for graphics cards... I just didn't understand what the big leap forward was, since my Amiga had been doing that stuff for 5 tot 10 years...

 

But I digress... Biggest hack or advantage? All the software and hardware at our hands that only high-end studios had a couple of years ago, all for free or almost free. Unreal, Unity, Corona, ... Add a dirt-cheap computer and an affordable Creative Cloud subscription and your set --> No excuses anymore not to get cracking!!!