Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Best practice for creating a game with levels.

Author
Message
bszaronos
6
Years of Service
User Offline
Joined: 7th Jul 2017
Location:
Posted: 20th Jul 2017 02:51
I have a question about how one should go about programming. I created my platform game but as I start to add additional levels things are starting to unravel. What I have currently is several #include files. One file is for my movement and detecting collisions on objects and jumps etc.
the other #includes are for loading the levels and placing things where they need to be. As I am increasing my levels my one movement #include is getting harder to keep track and handle all levels.

So my question has to do with how do others go about creating games with multiple levels. Do you program each level by itself ? If I did this I could have more control as to where the player is standing and to perform jumps and falls.
Or should you have one file that pretty much decodes everything and try to control everything by logic statements and variables ?

The way I went about my game was how do I get the player to move, when I got that, I added to it, So it was never completely planed out as to what I wanted it to do and how to go about it. It just keeps evolving.

Thanks
-Brian
easter bunny
11
Years of Service
User Offline
Joined: 20th Nov 2012
Playing: Dota 2
Posted: 20th Jul 2017 03:11
Not sure about absolute best practice, but here's how I did it for my game Na4:

[pseudo code]

game.agc


loading.agc

init.agc

You store all the info about the level in the global array assets (name it whatever you want). Then in DoLevel() you can loop through the asset array and take care of any game logic.

Not sure if that help you... Basically the key points are store the level info in a file, and when you load it, store all the info in a global array which you can access in your collision function

My Games - Latest WIP - My Website: Immortal.Digital - FB - Twitter
130,000 installs with AppGameKit and counting
bszaronos
6
Years of Service
User Offline
Joined: 7th Jul 2017
Location:
Posted: 20th Jul 2017 18:59
Thanks Easter Bunny that's what I have for mine. I have a main.agc, moveplayer.agc, loadlevelimages.agc, loadlevel1.agc, loadlevel2.agc, loadlevel3.agc, monster.agc. story1.agc, end1.agc, die1.agc, movelifts.agc.

What was throwing me off was the loading and creating of sprites. I was trying to load them at every level, and I didn't have to.
plus with having one agc file that detects all of my conditions it was getting harder to get all of the logic correct. So I re-did some of my code and it is getting more manageable.
I have three levels done, and starting to create more.

-Brian
Dybing
12
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 20th Jul 2017 19:58
Sounds like you are mired in spaghetti-code having dug a deep hole of gotos, ifs, magic numbers, giant functions and globals. Though how much of that apply is hard to say without seeing your code.

In general terms though, if you structure your data properly, structure the data-flow, keeping control is easy.
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 20th Jul 2017 20:31
Quote: "Or should you have one file that pretty much decodes everything and try to control everything by logic statements and variables ?"


Quote: "plus with having one agc file that detects all of my conditions it was getting harder to get all of the logic correct. So I re-did some of my code and it is getting more manageable."


The best way to go about this is to use what's known as a "State Machine", you set states for various parts of your game and this enables you to compartmentalize your game logic, 2 good examples in the thread I linked to but I'll break it down a bit here

so your main loop would look a little like this, you only process the code that responds to the level you are playing, all you need to change is the value of "gGameLevel" all need for other logic is removed


so say you have a function "ProcessCollisions()" that handle your player collisions and its becoming a mess not knowing what code is for what level, you break it down into states, a default state that would handle common collisions with walls, floors and such and level dependant code specific for each level in its own state

building your entire game like this with multiple "State Machines" can really help reduce the confusing logic load, combine it with a function for each state and you see you can have the collision logic or other logic for the entire game within a single file and understand exactly where you need to be editing and not a "if" statement in sight (yet)



and your main loop is simply calling "ProcessCollisions(gGameState)" or in your main loop state machine



Hope that made some sense
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 20th Jul 2017 20:35
Quote: "In general terms though, if you structure your data properly, structure the data-flow, keeping control is easy."


Yes, exactly that

Supertino
6
Years of Service
User Offline
Joined: 22nd Jun 2017
Location: Behind you!
Posted: 21st Jul 2017 09:05
Quote: "As I am increasing my levels my one movement #include is getting harder to keep track and handle all levels."


You need add logic to your movement code for every level you add? that sounds odd, assuming all levels are the same in how they play just with blocks, ladders etc in different places your movement code should work for any level you load in. - realise this does not help but found that line intriguing as to how your game hangs together.

For my games (2D) I always make a level editor (often find that process more fun than the actual game) that spits our a text file with level data, (tpye of object, position on screens etc) then I just read in the appropriate level file and using that data create the objects for the level, all objects are predefined in code (TYPES) to be a wall, ladder,elevator, spikes etc. and their interactions with the player has been coded once for each object type.
bszaronos
6
Years of Service
User Offline
Joined: 7th Jul 2017
Location:
Posted: 21st Jul 2017 13:37
Thanks for all the responses everyone, good stuff.

I did go through my code and cleaned up a lot. I did create a level editor for my game. That was fun. It spits out a txt file and I use that to load my levels.
I also implemented level variables so that it only does things based on a certain level. I also started making better comments in my code. Helps for going back and figuring out what is not working.

Steam says that I've only used this for a total of 81 hours, but i am loving this. I am learning a lot,


Jessika
6
Years of Service
User Offline
Joined: 8th Jul 2017
Location:
Posted: 24th Jul 2017 08:01
hii ,, i am also a game creator and game lover ,,

Login to post a reply

Server time is: 2024-05-05 08:56:49
Your offset time is: 2024-05-05 08:56:49