One Step Forwards

One step forwards and three back… it seems to be for me right now.

Not sure if I’m dumb or this is a normal ‘coding’ thing

Currently I’m working on a very very simple (in theory) game and when I spend 5-10 mins adding something new, it takes me 2-3 HOURS afterwards to debug the mess and fix the problems it introduces.

Seems like 80% of my coding time right now is spend debugging and ‘attempting’ to fix errors that seem to just ‘pop’ into the game when I alter/add something.

is this a normal thing or is it just me?

While I’m here can someone explain ‘classes’ to me in a very simple way?

I’ve trying searching on here and googling and although I find many things explaining them, I still don’t seem to comprehend what the point is of using them and why you’d use one rather than keep your code in the main loop.

Maybe every 25% of the things I try to add work out the same way. Most things I add are small, and sometimes create errors, but every here and there I add a bit thing and it can take me up to a few days to debug it and eventually revert to its original state after I rage about how I can’t figure out why it’s not working.

And, as for classes, it could be all in the main loop, but classes make things a lot easier and cleaner. For instance, if you’re making a game, and want to have multiple enemies of the same type, you can create a class for them that handles initializing, drawing, getting touched, possibly when a key on the keyboard is pressed, the orientation is changed, or there’s a physics collision. And it’s all kept away in a separate tab so you don’t have 2K lines in your main tab and you don’t have to look at it. I’m not joking about the 2K lines, by the way. And you can keep all the instances of that class in a table, and whenever you call draw() or touched(touch) or whatever, you can just say

for k, v in pairs(entities) do

or whatever. It just looks a bit nicer and takes up less lines of code. As for how they work…

--# exampleClass
exampleClass = class() -- Create a class.

function exampleClass:init(x, y) -- Initialize exampleClass with two variables: x and y.
    self.x, self.y = x, y -- Set them as variables in our class.

function exampleClass:draw() -- Seperate draw function.
    sprite("Cargo Bot:Codea Icon", self.x, self.y) -- Draw the Codea icon at our variables, x and y.

function exampleClass:hello()
    print("Hello World!")

--# myClass
myClass = class(exampleClass) -- Create another class, that inherits all the functions of exampleClass.

function myClass:init()
    exampleClass.init(self, WIDTH / 2, HEIGHT / 2) -- Call the init function from exampleClass, with the instance as self.
    self:hello() -- Call the hello function, inherited from exampleClass.

function myClass:draw()
    exampleClass.draw(self) -- Call the draw function from exampleClass, with the instance as self.
    text("Hello World!", WIDTH / 2, 200) -- Draw some text, after drawing from the superclass.

--# Main
-- Classes
function setup()
    class = myClass() -- Initialize a new instance of our class.

function draw()
    background(255, 255, 255, 255)
    class:draw() -- Have our class instance handle its own drawing.

I think that was fairly well commented. You can paste into a project with the correct tabs by copying that and long pressing on add new project, and selecting paste into project.

This message would have come sooner, but my cat came along and meowed very loudly, demanding to be pet.

A lot of things in coding can be simple in theory :wink: but generally things will take time to perfect, but the more you learn the easier this gets. Try to remember the “gotchas” that you’ve had previously so they don’t get you again :slight_smile:

From you saying “why would you use classes over having all your code in main” this makes me cringe and shudder a little :slight_smile:

Classes help you organise your code into units of related functionality and attributes, essentially they a description of something in terms of values that represent things about an object (for example width and height) and things it does (functions). A class solves exactly one problem and it should do it well. Rather than try and solve lots of problems at once (potentially poorly) which will cause things to get complicated quickly.

A class allows you to focus on a particular problem and everything about that problem isolated in one place which keeps things simpler during development, makes it easier to add and remove pieces of functionality and simplifies debugging when there are bugs because you can just resolve them in context to the problem they solve rather than their problem and everything else’s.

You would use them over putting all your code in main to avoid bugs that “pop out of nowhere” because of overlapping problem domains. Which I would describe as adding/fixing one thing and breaking 10 others :wink: (perhaps more). Main is a really good place to use your classes together to make your game / solve the common problem, each one being like a little piece of the puzzle each doing its own little job (with emphasis on doing its job well :wink: ).

Here’s a small example of a rectangle:

Rectangle = class()

function Rectangle:init(position,size)
      self.position =position or vec2(0,0)
      self.size=size or vec2(10,10)

function Rectangle:draw()

function Retangle:inflate(size)
   self.size.x =self.size.x+size.x
   self.size.y =self.size.y+size.y

In this particular case the rectangles attributes and “position” and “size” (information which describes where the rectangle is located and how big it is). The functionality is “draw” and “inflate”. Draw allows it to be displayed on the screen and the rectangle knows how to draw itself so you can just ask it to draw from main and you don’t have to worry about telling it how to draw in main aswell. Inflate allows the rectangles size to be increased, again you just ask it to increase its size, you don’t have to tell it how.

There is a lot of theory and philosophy to classes and programming techniques in general there is no right or wrong way really… just better and worse ways :wink:

Another reason for classes… If you crash, it tells you the tab name and the line, so you know which class the problem is in, or if it’s unintentionally broken by another class (such as changing a parameter in init, but not where it calls init.)

@Mene - it’s normal, it gets easier with practice. Perhaps you need to do some more reading on Lua and Codea before attempting to program. I had quite a lot of other programming experience when I started Codea, but I still didn’t try programming a game until I’d read all the tutorials and manuals I could find, looked at the demo projects, and practised the language a bit.

You don’t need classes a lot of the time, especially for simple projects. But if it helps, I’ve written some posts on classes, see under Class heading
(the last of the four tries to explain when you would use a class)

To make it easier on yourself, try just adding a couple of lines at a time and running your code. Use the print command to show you what values your variables have. Use functions to

@Mene everyone started where you are, I remember the first time I looked at lua a few years ago and it looked like an alien language. The thing is, you will start off having to debug a lot, this is normal and I’m sure any coding ‘guru’ you see on this forum started off where you are or worse, but give it time as with everything and you’ll be flying before you know it, give it a week and you will feel like you understand about 4x as much as you understand now, depending on how much work is happening on your end…

If I were you I wouldn’t look at classes just yet as you most likely wont need them. A great way to start off is by using the physics engine and drawing over the bodies, you can make 100s of different games just using that, but it isn’t just drawing and physics, you add all the logic of the game which when you finish feels like a proper success, it did for me anyway.