Old Game Dev versus Modern Game Dev: Biggest Hack

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.

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 :grinning:

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 :grinning:

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

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.

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)&nbsp; &nbsp; setPixel(x + 2, y, color)&nbsp; &nbsp; setPixel(x + 3, y, color)&nbsp; &nbsp; setPixel(x + 4, y, color)&nbsp; &nbsp; setPixel(x + 5, y, color)&nbsp; &nbsp; setPixel(x + 6, y, color)&nbsp; &nbsp; 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 :D 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  :lol:

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!  :smiley:

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

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  :wink:

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.