Advice for writing an event driven and object oriented game?

General
1

So I’ve been coding for about 5 months in this language, and I think it’s time to try a larger project. I am planning on writing a game where you move as a simplistic character and alter your color to advance through logic puzzles. There will be 1 puzzle per room, and each puzzle will be different in objective, obsticals, and rules. I feel like i should write a different class per room, and that’d be the best way to do it. I’m also going to rewrite my code until it’s as efficient and as smooth and as organized as possible, no band aids because that’s the kinda stuff that comes back to haunt you.

But I’m curious as to advice you guys my have, specifically on how to write a 10-20thousand line event driven game and writing puzzles? Would I use counters for the phase that you’re on of the puzzle? Feedback greatly appreciated, but please don’t tell me to table this for several months. I’d love any constructive insights anyone could provide.

Thanks guys
Kirk

2
  • event driven: use the event class posted somewhere ont the forum (or in codea showcase): it works wery well.
  • study cargobot button / panel / screen system: it works very well.
    That was my advice (although i dont make real games, and my programs stop at 5000 lines).

[edit] paragraph 1 of ignatz’s post below is a VERY. VERY valuable advice!

3

I think most professional advice (I am not a professional programmer, but I am channelling advice I have listened to) would be to compartmentalise everything you can. Break your code into tight classes and utility libraries, and test them thoroughly. Push tested libraries into separate tabs or even projects (and reference them into the main project). Also keep everything “loosely coupled”, so your game is as flexible as possible.

All this helps control the growing pains of large projects, including code sprawl, nightmare debugging (especially given Lua’s extremely limited debugging tools), and code refactoring forced by finding you’ve painted yourself into corners.

Codea saves as you go, which is usually good, but if you make some changes and break something, you will be wishing you’d kept the previous code. So I would save backups often.

One nice feature of Codea is that you can have two copies of a function and when Codea compiles, from left to rght, it will overwrite the first with the second, so only the second one gets used. So if you want to make some changes to tab X that might break it, you can do things like making a complete copy of that tab’s code to its right (or maybe just the functions you are changing) and then modifying it and testing it. It will be used instead of the original code, which is still there if you need it.

I wrote a 2D widescroller demo recently, and although it is way smaller than what you are talking about, I found the best design (for me, anyway) - after starting over about four times - was to build a set of images, a set of interactive object classes with behaviour, and a level editor that reads in a simple ASCII map and creates the level from that, using the images and objects. This allows me to create new levels in an hour or so, adding new maps, object classes or images freely. None of these things depend on each other.

So in your case, I would probably write the game framework to handle the UI menu, scoring, etc and room transition, plus anything that doesn’t change between rooms, then start writing room behaviour as separate object classes, as you suggest, but I would pull duplicated code out into utility classes (eg perhaps player movement) as you go.

4

@Invad3rZIM The above advice is very good and I think I’ll just be repeating some of it. In my game Aedif in Aedifico there’s 12000 lines of code, around 300 lines being in the Main tab, with an extra 80 odd tabs of code, so all I can say is just keep going forward and it’ll just happen. As Ignatz said compartmentalise while coding as this will lead to a self taught method of organising and structuring code. One way to do this would be to think about what you need and how you’ll act on what you need once you have it, for instance:-

I have a tab for Weapons that incorporates all of the way the weapons work but the Weapons tab only creates the mechanics of the weapons whereas the Player tab (which creates the whole player and determines how he works, looks like and moves) draws the weapons and aims them (also positions where bullets are fired from). I took this from my experience gaming in earlier days while programming and this is something you build on yourself in your own way.

Another one is:-

I have a tab (class) for the Box, Ball, Seat and Platform objects in my game, but for the Dynamic (prop) objects (the class that spawns all different models/props) I have one class that reads from a list to create many different types of objects whereas the former classes only spawn one object, this ideology is derived from the necessity of different uses from within each class. The box and ball are both resizable and so they need their own class because they work differently to every other prop, the seat and platform have their own class because they work differently in the sense that they are coded to interact with the player (sitting down, sticking the the platform) and make the player act differently.

Although it’s a bit long I hope it makes sense, you will learn to figure out what makes for good ease of use and what doesn’t when making classes interact with each other and even just for creating more than one object (not duplicating code unnecessarily).
As I said before if you need help with any of it then message me.