clyde

Amateur Game Making Night

Recommended Posts

var xDir=0, yDir=0, num=1;
for (e=0;e<numberOfRooms;e++){

        ds_grid_set(grid_layout,open[e,1],open[e,2],num);
        num++;
        
        free=false;
        //choose a direction
            roomDir=0;
                
                while(free = false){
                
                    roomDir = irandom(3)+1;
                    if (roomDir = 0){
                            xDir= 0;
                            yDir = 0;
                    }
                    if (roomDir = 1){
                            xDir= 0;
                            yDir = -1;
                    }
                    if (roomDir = 2){
                            xDir = 1;
                            yDir = 0;            
                    }

                    if (roomDir = 3){

                            xDir = 0;
                            yDir = 1;
                    }
                    if (roomDir = 4){       

                            xDir = -1;
                            yDir = 0;
                    }
                    
                    if (e>0){
                        for(i=0;i<e;i++){
                            if (open[e,1]+xDir=open[i,1]) && (open[e,2]+yDir=open[i,2]){
                                free=false;
                            }else{
                                free=true;
                                break;
                            }
                        }
                    }
                    else{
                        free=true;
                    }
            }
            if (open[e,1]<layout_width) && (open[e,1]>0) && (open[e,2]<layout_height) && (open[e,2]>0){
                open[e+1,1]=open[e,1]+xDir;
                open[e+1,2]=open[e,2]+yDir;
            }else{
                open[e+1,1]=open[0,1];
                open[e+1,2]=open[0,2];
            }
}

 

Gah could anyone help me out? I must be doing something stupid here. This is level generation code that chooses an active tile, picks a random direction, and creates another tile adjacent to it. That works fine, but when I tried to make it choose again if the tile in the chosen direction is in the coordinates of a previously placed tile, it either doesn't work outright or gets stuck.

 

I know now that it gets stuck due to an edge case where a tile can be placed surrounded by other tiles, but I can't seem to see what I'm doing wrong elsewhere.

 

Sorry for the unusual looking code conventions. I'm doing this in GameMaker so it's super weird.

Share this post


Link to post
Share on other sites

I strongly suggest you adopt a coding style that fights against logical problems.

 

I find it extremely useful to put comments in code that say what the code is supposed to do. In fact, typically I write these comments before I write the code. Hopefully this is tied in with invariants - things you expect to be true at different stages and can check against.

 

Here are some things I see eyeballing your code:

 

1. The use of '=' to test equality. (Apparently this is a thing in Gamemaker, but deprecated?)

 

2. num appears to be e+1 always

 

3. You can choose an xdir and ydir of zero, which means select the tile you are already at (this would be bad no?)

 

4. Except you can't actually hit the zero case, since you are adding one to the result of irandom

 

5. The case where e equals zero seems very strange to me. This is choosing the first seed tile? If you have a loop and your loop contains a test for just the first iteration of that loop that's usually a good indication that your loop is wonky.

 

6. If your layout_width is 6 and open[e,1] is 5 your if statement will pass, meaning your range is actually from 0 to 6 inclusive, when 5 (if I understand correctly) should be the last possible index

 

7. This check is also weird in that the if statement will fail if open[e,1] is zero, which should be ok if xdir is zero or one. (basically your bounds checking looks messed up) The starting tile being on the far left is only a problem if you are trying to add a tile to the left.

 

Here is how I would comment your code, the way it is written now:

 

 

//1 For the desired number of rooms, find a direction we can add a tile in and add that tile

 

   //2a. Pick a random direction and test to see if that space is already filled (wait...do we already have one seed tile??)

 

   //2b. Keep going until we hit a direction that works.

   //TODO the way this code is written we can test the same direction an indeterminate number of times, and there's no way of knowing if we've unsuccessfully tried all 4 directions

   //TODO it's possible that no direction works, in which case we should pick a different tile to try to attach to and cross this tile off a list of viable tiles to expand from

 

   //2c At this point we know that the xdir and ydir address a free space adjacent to our current tile,

   //except that this free tile could be off the map, which we probably should have checked for in 2b and rejected at that point, now what?

 

-----

 

Now here is how I would write the "correct" version:

 

//1. Pick a starting tile bound to the map

 

//2. For the desired number of rooms:

 

    //pick a direction to test from the last "open" tile

    //test to see that direction is open and in bounds (I should write a function for this!)

    //if not cross the direction off the list of available directions

   

      //if we find a working direction put that tile down and repeat

 

     //if we've tried each direction unsuccessfully pick a different tile from our "open" list to work against, and remove this tile from the "open" list

     //NOTE: we didn't actually put a room down in this case, so we shouldn't increment our counter vs desired room total

 

---

 

Basically, come up with an idealized notion of how the code should work, then write the code to match. This also makes it easy to debug - if things are going wrong you have a good understanding of what the code should be doing so you can just print stuff out to make sure that it is doing that - in this case print out the list of directions you've tried and rejected, print out when a tile gets marked as closed, etc.

 

Writing code that is correct, or at least easily made correct, is an important skill to develop. In large projects the difficult bugs are bugs that deal with multithreading, memory use, or code interfacing with other code such that what the code is doing becomes less and less clear, and these are the sorts of problems that are best dealt with via prevention rather than debugging.

Share this post


Link to post
Share on other sites

Today I wrote a script and then looked at it. I was able to erase about 3/4ths of it and still have it work. I enjoy this process, but it's super hard. Reading this thread is helping. Tommorow I'm going to try that method of imagining the ideal path in comments and then writing the script for it to happen that way.

Share this post


Link to post
Share on other sites

What does open do blambo? I can't figure it out from the context:(

Share this post


Link to post
Share on other sites

I've been wanting do learn Unity & C# aswell. So after reading and watching tutorials & scripts I did a simple day/night cycle. I also had the craving to do some old school diffuse only texturing ca 1998. The grass billboards are default unity though, this scene is a hodgepodge at the moment. Not sure what I want to do with this.

 

daynightcycle1.jpg

Share this post


Link to post
Share on other sites

Yes it was totally the rare solar eclipse feature I'm working on. No but seriously, you're right, it was too dark. When you pointed it out you could almost say it dawned on me. :eyebrow:  I replaced the above screenshot and lazily adjusted the ambient lighting for maximum viewing pleasure.

Share this post


Link to post
Share on other sites

I strongly suggest you adopt a coding style that fights against logical problems.

 

I find it extremely useful to put comments in code that say what the code is supposed to do. In fact, typically I write these comments before I write the code. Hopefully this is tied in with invariants - things you expect to be true at different stages and can check against.

 

Here are some things I see eyeballing your code:

 

1. The use of '=' to test equality. (Apparently this is a thing in Gamemaker, but deprecated?)

 

2. num appears to be e+1 always

 

3. You can choose an xdir and ydir of zero, which means select the tile you are already at (this would be bad no?)

 

4. Except you can't actually hit the zero case, since you are adding one to the result of irandom

 

5. The case where e equals zero seems very strange to me. This is choosing the first seed tile? If you have a loop and your loop contains a test for just the first iteration of that loop that's usually a good indication that your loop is wonky.

 

6. If your layout_width is 6 and open[e,1] is 5 your if statement will pass, meaning your range is actually from 0 to 6 inclusive, when 5 (if I understand correctly) should be the last possible index

 

7. This check is also weird in that the if statement will fail if open[e,1] is zero, which should be ok if xdir is zero or one. (basically your bounds checking looks messed up) The starting tile being on the far left is only a problem if you are trying to add a tile to the left.

 

Here is how I would comment your code, the way it is written now:

 

 

//1 For the desired number of rooms, find a direction we can add a tile in and add that tile

 

   //2a. Pick a random direction and test to see if that space is already filled (wait...do we already have one seed tile??)

 

   //2b. Keep going until we hit a direction that works.

   //TODO the way this code is written we can test the same direction an indeterminate number of times, and there's no way of knowing if we've unsuccessfully tried all 4 directions

   //TODO it's possible that no direction works, in which case we should pick a different tile to try to attach to and cross this tile off a list of viable tiles to expand from

 

   //2c At this point we know that the xdir and ydir address a free space adjacent to our current tile,

   //except that this free tile could be off the map, which we probably should have checked for in 2b and rejected at that point, now what?

 

-----

 

Now here is how I would write the "correct" version:

 

//1. Pick a starting tile bound to the map

 

//2. For the desired number of rooms:

 

    //pick a direction to test from the last "open" tile

    //test to see that direction is open and in bounds (I should write a function for this!)

    //if not cross the direction off the list of available directions

   

      //if we find a working direction put that tile down and repeat

 

     //if we've tried each direction unsuccessfully pick a different tile from our "open" list to work against, and remove this tile from the "open" list

     //NOTE: we didn't actually put a room down in this case, so we shouldn't increment our counter vs desired room total

 

---

 

Basically, come up with an idealized notion of how the code should work, then write the code to match. This also makes it easy to debug - if things are going wrong you have a good understanding of what the code should be doing so you can just print stuff out to make sure that it is doing that - in this case print out the list of directions you've tried and rejected, print out when a tile gets marked as closed, etc.

 

Writing code that is correct, or at least easily made correct, is an important skill to develop. In large projects the difficult bugs are bugs that deal with multithreading, memory use, or code interfacing with other code such that what the code is doing becomes less and less clear, and these are the sorts of problems that are best dealt with via prevention rather than debugging.

 

Dude thank you so much! I took your advice and just redid it, while actually planning out the steps. It totally saved me a lot of unnecessary headache.

 

Got dungeon generation and camera work up, now it's AI and pathfinding time:

i7WfkIsOdnfDu.gif

Share this post


Link to post
Share on other sites

A* pathfinding is very similar to what you've already done. You have a list of open nodes, directions you've tried, etc. It's basically the algorithm I outlined above, just with a non-trivial heuristic.

 

Good luck

Share this post


Link to post
Share on other sites

Hi! I want to start posting on the Idle Forums more because of how well regarded it is on the podcast. Anyways, I've been making a fighting game for a little while now. The idea is that its going to be a 3 vs 3 (MvC3) fighting game with a team drafting mechanic (DOTA 2 Captain's Draft). Right now, its just a 2v2 because I don't have enough characters to support a draft right now, but I'm getting there. I've got 5 characters at the moment, but I'm aiming for around 16. 

Here are some gif! 

bloodwitchVsTempa_zps1f4cbd8a.gif

 

and

 

zetVsTempa_zps838d078e.gif

One last thing, here is a video I uploaded to my youtube channel of 2 bots fighting against each other.

The video really exposes all of the bugs, so it looks a bit wonky at times. 

Share this post


Link to post
Share on other sites

Very ambitious! Very cool. Gonna be really curious to see how it progresses. What made you want to make this, beyond that you (probably) love fighting games?

Share this post


Link to post
Share on other sites

Very ambitious! Very cool. Gonna be really curious to see how it progresses. What made you want to make this, beyond that you (probably) love fighting games?

Thanks! I'm 9 weeks in, and still going strong so I think I'll be able to make my goal (given enough time). I wanted to make this because I found it interesting how important the character selection process was in DOTA. It was like a game before then "real" game. Fighting games seemed like the perfect fit for something like this. All of the characters have a simple control scheme so you don't have to learn special inputs. Since you will be doing bans and picks, you aren't in full control of what character you will play.Its my hope that by making easy to play characters, you won't play a set team repeatedly but be able to play the majority of the character roster. 

Share this post


Link to post
Share on other sites

I haven't had as much time to work on 7DRL/Procedural Death Jam this weekend as I wanted but check out what I got so far

 

http://danimo.net/Scavenger/Scavenger.html

 

insert number (range: 2-16), press button, get dungeon. The "dungeon" is meant to actually be a space ship, so no long corridors like in nethack, but a bunch of rooms connected to each other of varying size. 

Share this post


Link to post
Share on other sites

Hey I've been working on my 7DRL as well! Two days in now. I think the core mechanic is going to be the bombs: defeating enemies, blowing up walls etc. 

 

https://vine.co/v/MqtvXMEYOX3

 

It's ghost-based because a. I can't draw very well, b. ghosts are pretty cool and c. trying to somehow connect each playthrough together while still having permadeath lead me to some kind of spirit-based game. It's not a fully-formed idea yet, but I wanted some kind of permanence between playthroughs that's not just "you get your previous gold/items/stuff!" I think the idea is that all ghost are connected and by altering the levels and also killing other ghosts you alter the collective in some way. I haven't quite worked out what that alteration is (could be as simple as affecting base stats for new playthroughs) but the idea is there.

 

Might also be too much of a deal for seven days. There's still a lot of groundwork to do and the weekend is over so I'll have less time to work on it during the week. Oh well, fun stuff!

Share this post


Link to post
Share on other sites

Progress Report Week #5

What were my goals?

What are my goals for week #5

- I want to make sure that I don't stop working on the dance-game just because I have a little to show for it (I have a history), so that is the first priority. I want to make sure I add something to it. There is plenty of room for more. I'll probably add another character and hopefully one of their animations. Once I have two lovable characters on the screen, they will tell me what they want to do for a narrative.

- After Dinosaursssssss's audio-experiment build, I really want to do something in that area. I'm imagining a 3d

kinda thing. I was already successful in making some bouncing balls that play a tone when they collide. I want to make it so that their pitch is a function of their size, make that alterable through controller input, and also create an interesting environment for it. No rush, I just want to work on that some too.

-I need to read more about Unity's Mecanim. That thing is a beast and it's incredibly useful.

What challenges might I face and how can I prepare for them?

- I can't do most of this at my job, so time is a factor. I think the best I can do to prepare for this is to just prioritize my goals. I might not be able to do them all this week. Dance-game progress is the first priority.

- I'm planning on using rigidbody physics for the second character. It won't be the same situation as it was with Patricia. I suppose I can prepare by being willing to switch to a character who is animated in a similar way as Patricia if I get stuck.

- I may get really into the 3d hanenbow experiment. If I don't input another sprite into the dance-game by Thursday, then no more 3d hanenbow until I do.

- Mecanim is my nemesis. Maybe I should switch to a character who animates rather than the rigidbody one. That way I will get more comfortable with Mecanim. That's what I will do. Second character will be a standard sprite animation that plays animations with controller input.

Which of my goals did I accomplish?

-I drew a new character. Imade some animation frames in Gimp and then imported them. I successfully used Mecanim for the arms and face and used rigidbody physics for the legs. This was for the dancing-game, so that goal was accomplished too.

-I didn't work at all on the 3d Hanenbow idea. I ended up doing something completely different.

What happened?

-Monday I drew the sprites. It was an interesting process because I was aiming to do different things with different parts. I'll be doing more of that in the future. I like the paper-doll mixture of animation and physics for separate body parts.

-Tuesday I made the sprite-sheet and imported it. That was also when I did the physics on the legs and worked with mecanim. I still haven't assigned any logic to it. Wait, I guess that means that I didn't use mecanim. I lied; I didn't accomplish that goal. Oops.

-Wednesday, I woke up with an idea for the cyberpunk game-jam and thought it would be easy to do. I quickly found out how little I knew about scripting movement with controller-input. This sent me on a long journey of discovering the difference between value-variables and reference-variables. After some struggle and advice from the forums, I came out more capable than before.

-Then I tried writing script in my notebook for the first time. I know enough for it to be really fun, but I haven't tried the code out to see if it works. Writing away from the computer was interesting because I try to compute initial values myself (imagining what theinitial values would be and going through the script to see what would happen). At the computer, i tend to make guesses about why the script doesn't work, change a little bit, try running it, change it a little bit, repeat. It works, but I felt that my book work was significantly different, enjoyable, and gave me a greater capability. I still need to type it in to see if it works. I know it won't if C# says 1/0 is an error.

http://doodle-plans.tumblr.com/post/79190682328

Then I worked on GUI again.

What are my goals for week #6?

-I want Veronica to have an animation for standing. It hurts my back looking at her crouched down like that for too long.

-I need to tie the animations to controller-input in mecanim.

-I want to think up a process for me to continue to focus on learning, but also result in small finished products. I feel like everytime I learn how to do something, I move the goal-post for what I want in a game. I want to be putting very small games out regularly and I'm pretty sure that I now have the capability to do that. The cyberpunk idea I have is currently beyond my capability, but it provides a good impetus for learning about designing my own character-controllers, but I also want to frequently work on small games which are entirely within my ability. This week I plan to keep this on my mind so I can add something into my routine that will encourage this. Maybe I spend one week out of three making a game that I know how to make. I don't know, I'm thinking about it.

What are the challenges I may face, and how can I prepare for them?

-Titanfall. I think I'll be alright. I'm pretty much just planning on finishing Veronica. I don't expect to run into anything I can't solve in two hours.

Share this post


Link to post
Share on other sites

.

-Then I tried writing script in my notebook for the first time. I know enough for it to be really fun, but I haven't tried the code out to see if it works. Writing away from the computer was interesting because I try to compute initial values myself (imagining what theinitial values would be and going through the script to see what would happen). At the computer, i tend to make guesses about why the script doesn't work, change a little bit, try running it, change it a little bit, repeat. It works, but I felt that my book work was significantly different, enjoyable, and gave me a greater capability. I still need to type it in to see if it works. I know it won't if C# says 1/0 is an error.

 

 

I went to Target and raided the school supplies for graph paper, folders and colored pencils. I don't straight up write code on paper, maybe pseudocode, but its pretty nice to have that shit around to quickly scratch out ideas.

 

also yeah I think you'll get a runtime error when the velocity.x is zero.

 

also also you may want to use Time.deltaTime instead of Time.time, that way you can just set float countDown = 0, in Update() you can put countDown += time.deltaTime. This way instead "if (countdown + timer < Time.time)" you can just say "if(countDown >= timer)" then reset countDown to zero after getting input. If i'm reading things correctly and you just want the input have a timer seconds delay before accepting another input.

Share this post


Link to post
Share on other sites

http://danimo.net/Scavenger/Scavenger.html   Progress!

 

new features: 

 

-a dude, with an impairment that only allows him to move in the 4 cardinal directions( controls: WASD)

-press M for zoomed out map

-the door tiles between rooms are now traversable - currently just spit you out on the other side, real door mechanic will come later

 

-you can still generate new layouts with the UI for fun/debugging.

Share this post


Link to post
Share on other sites

Oh, when you said 3v3, i thought you meant like IK+:( Looking really awesome though, that's amazing work for 9 weeks!

 

international-karate-plus.png

Share this post


Link to post
Share on other sites

Thanks! I made a new video showing the more polished UI and some fights between me and the computer. 

 

 

Some GIFs:

mainMenu_zps987689a5.gif

 

characterSelect2_zpse8252346.gif

 

sunsparkCombo_zps3476bb3e.gif

Share this post


Link to post
Share on other sites

Thanks! I made a new video showing the more polished UI and some fights between me and the computer. 

 

Too cool.

Share this post


Link to post
Share on other sites

Thanks! I made a new video showing the more polished UI and some fights between me and the computer. 

 

 

Some GIFs:

mainMenu_zps987689a5.gif

 

characterSelect2_zpse8252346.gif

 

sunsparkCombo_zps3476bb3e.gif

 

What I really like about this is quirky character animations - With the three on three battles it'll difficult to spot them out, see gaps and work your advantage. I'm a big fan of that!

If the game is going to have 3v3, perhaps you should include a character with reversi powers? So when he/she gets hit, the other player are damaged, but if they hit the other players, they themselves are damaged. Have it so this character is constantly punching or attacking on a timer, rather than input by the players. It's a stupid as heck idea, but something.

Share this post


Link to post
Share on other sites

Latest progress on Ghost Roguelike: https://vine.co/v/Mb5gJbUrLpV

 

Next I need to figure out a win condition for each map. I'm thinking something like in 868-HACK where you can just exit the level at any time and the focus is more on your score which you can get from collecting something (TBD) and killing other ghosts. Maybe add in some kind of bonus based on how many turns you took before exiting. It's just throwing things at the wall at this point.

 

I only have two more days (until midnight on Friday) for it to be a 7DRL, but I think I can get something that at least resembles a completable game.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now