I’m open to other methods, but I personally prefer OOP. It helps me break down anything into simple problems. Do you have a better way of organizing games?
Well, there’s nothing preventing you from breaking things down into simple problems without the use of OOP. Think of the millions of applications that were coded in C, with no OOP features at all. Lua has tables that can be used both as arrays and hashmaps, its functions are first-class citizens, and there’s some syntactic sugar that makes table entries look like properties. That’s enough to handle just about anything.
Having been “raised” as an OOP developer, I also tried to do everything in Lua in an OOP fashion, but after spending a lot of time with the language, it seems to me now that I was just facing the law of the instrument - “If the only tool you have is a hammer, you tend to treat everything as a nail”.
Now I only use OOP sparsely in my Lua projects, if I use it at all. Instead, I love the freedom of not being forced into constructing elaborate sets of classes and fields and private and public methods and getters and setters etc, when all I need is to store a couple of values in a table.
Anyway, to answer your original question: I found these two tutorials useful. Have you already read them?
So, any examples? I’ve seen the source code to C games, they aren’t pretty. I’ll let procedural programming stay in the dumpster where it belongs.
I suppose you could look at e.g. the code of Corona SDK’s widget library, which is open source:
https://github.com/coronalabs/framework-widget/tree/master/widgetLibrary
As you see, it uses tables to do some simple encapsulation, but doesn’t bother with things like inheritance or polymorphism.
caveat: comments based only on reading, not running…
evolable’s new() doesn’t return self, so player’s new() is trying to setmetatable on nil. doesn’t matter tho, still wouldn’t quite work: player CLASS has a stepNow() but the player INSTANCE (“self”) does not - you’d need to copy down the class methods into the instance (or “deepen” your __index metamethod)
but… seeing all those semicolons suggests you might be new to Lua, so i’d suggest some reading and exploring other implementations to help the learning curve, fe: http://lua-users.org/wiki/ObjectOrientedProgramming
hth
Semicolons are optional in Lua.
my point exactly 
You have no point.
When I first started to use Corona I was looking for classic OOP patterns as well but they aren’t necessary to write clean code.
The Composer Library: https://docs.coronalabs.com/daily/guide/system/composer/index.html
and Lua have whatever you need to build a well maintained project. Example public/private module:
[lua]
local M = {}
function M.new(pNum) – constructor
local public = display.newGroup()
local privateProperty = pNum
public.publicProperty = 42
public.anotherPublicProperty = ‘foo’
local function privateMethod()
– code
end
function public:publicMethod(pStr)
– code
end
return public
end
return M
[/lua]
Simple Lua OOP
http://theindiestone.com/forums/index.php/topic/8023-simple-lua-oop-without-metatables/
That was such an ill-mannered response to someone trying to help you. 
Wow. In full agreement. I thought I’d jump in here to help until I read that response. No help from me then.
All I see is a culture of developers constantly looking for ways to one-up each other. That’s where all those media sterotypes come from; It’s toxic, and quite honestly has to stop if anyone wants to be taken seriously.
Any chance we can rename this thread ‘Issues with paranoia’ ?
The majority of the posters on these forums are among the friendliest, patient and helpful I’ve come across. Unless you burn your bridges, that is.
Oh, darn, I was one upped.
Agreed, that’s what I love about this place. It’s a small community, but a good one 
Okay, enough with the bickering and back to the topic. My hunch is the error is in setting the evolvable metatable. I might be wrong, but I don’t think there is a need to set Evolvable’s metatable to Evolvable (because it already is by definition), and that the error could originate here.
the “classic” way to implement it would be to have the child class itself be an instance of the parent class. plenty of links to more-rigorous and/or more-extensive treatments have already been given (if the OP cares to look), but one common bare-bones pattern looks something like this:
Animal = {} Animal.\_\_index = Animal function Animal:new() return setmetatable({},self) end function Animal:speak() print("huh?") end ----- Cat = Animal:new() Cat.\_\_index = Cat function Cat:new() return setmetatable({},self) end -- override, or comment out to inherit function Cat:speak() print("meow") end ----- Animal:new():speak() Cat:new():speak()