JeeshusChrist

LD28

There can only be one…. Ninja!

There Can Only Be One...
So this is our first game jam! We are a team of 5 students, who just started this fall. We are programming in python with our school’s in house engine.

Yesterday…

It took us about an hour – hour 1/2 hours to get our idea concept. It’s inspired by the days playing Golden Eye 007  with Golden Guy, the one shot and one bullet gun.
We’ve been struggling getting controllers throughout the process, since it’s our first time any of us are using them. But we finally got everything working properly with the controls.
Now the only problem we are trying fix is the setup for players joining with keyboards and/or controllers.

The Game:

You can play up to 4 players in this arena duel. The goal is to be the last ninja standing. There is one shuriken that randomly is given to one player.
They throw the shuriken at the other players to try and kill them. If the shuriken hits a player, they will die. Players can take the risk of ducking under and catching the shuriken.
Ducking is for a very brief time, so doing it is very dangerous. Otherwise when the shuriken hits a wall it can be picked up by any player. The game is played till the number of kills you specify. You can also add number of rounds that are played, so to win you must win the majority of the rounds specified.

Progress:

Once we get the joining system working, we will have a fully playable build. We have four levels with assets, player assets are done but needed to be added and animated into the game, working on a few sounds to add. Another teammate has finished with basic AI pathing and now tweaking it, so you can play solo or fill in any empty slots with bots when playing with friends. We should have a playable build by the end of night hopefully… and tomorrow will be play-testing, balancing and polishing if we are on track.

Thanks for reading! Best to luck to everyone!

There Can Only Be One… Ninja! Update!

Our Team Logo!

   Our Team Logo!

I came up with idea this morning and we finally decided to use it! I love this logo, haha.

Throne room level

Throne room level

Here’s a quick screen cap on one of our levels with each of the ninjas in it.

Progress:
Some of the issues with the controller data was keeping us from having a fully functional playable build. Now those issues have been resolved and the only thing we have left is fixing that there is only one shuriken in the level and who to give it to. All the art assets for each other ninjas and their silly animations have been imported and all of our menus are finally done. So tomorrow we will be play testing and implementing all of our polish features, which include sounds, announcer, possibly a player tracker through playthroughs and among other things! We’ve been playing a little bit as we can and it’s definitely a ton of fun. We will post our playable build tomorrow when we finish wrapping it up!

The Can Only Be One… Ninja! Postmortem

Each team member that wants to post a postmortem will be posting their own, in order to give our own views on how we saw the weekend going.

Game Link: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=21804

Gameplay Video: https://www.youtube.com/watch?v=RRsR_DTW6JI

Joshua Louderback’s Postmortem

What Went Right:

1. The Team:

Our Team worked very well together. We are all friends and mess with each other a lot. Even when we got pissed at each other, which really didn’t happen. There were a few moments of high frustration at least for me, but never did it lead to anything unproductive. If something went bad we would get upset for a minute and then all jump back onto it. That leads me into the next thing I want to talk about….

2. Workmanship:

There was barely any slacking, if there was any at all color me surprised. Through the entire weekend I took two breaks from the game. One was to cook dinner and the other was to get some groceries. From what I saw looking around no one did either, besides to eat or cook. We crunched hard and that’s what got us to the end.

3. One Location:

The one thing that I believe helped the most is that we were all located besides one person at the same place. The other person would still come over and work alongside us throughout a period of the day, which was nice. The best part about this is if there were any problems we would encounter, we had each other right there to help out. Plus the moral of us all working hard motivated each other to work hard and the joking helped ease the frustration. I don’t think we would have made it if we were all separated because our communication might have failed.

4. Communication:

We were constantly talking to each other. At least I was constantly keeping track of where everyone was at on their tasks. I guess I took up the role of the producer. It sort of is my natural instincts to keep things organized. Usually I am the one who is also lead in the design aspects, so making sure everything runs the way it should is something I do naturally. I know sometimes I had to be a bit of a mean person and boss people around. Everyone took it well and listened, which was a great part of our success. We followed a chain of command. If anyone needed to know what to do next they just asked me. Also bugs when ever we encountered a bug in another persons code we notified them immediately with full details of what happened and we usually had ideas behind how to fix them. There were a few disconnects in our communication that caused giant problems, but after the we endured the suffering we caused ourselves we learned from our mistakes and communicated more.

 

What Went Wrong:

1. SVN:

I should note that it was the first time the majority of us have used SVN, so we were learning how through the course of development. Half way through the project we got working on a SVN rather than passing our code via flashdrive. First of that is a horrible way to work because it takes way too much time to combine everything together. The only good thing I can say about it isthat at the beginning when we were all bouncing between each others code, we would have a lot of collisions on SVN that would have been bad. Once we started using SVN everything went pretty smoothly. We had a few hiccups along the road that delayed us, but there was one massive mess up the put us back 2-3 hours. This is one of the massive communication disconnects we had. Someone pushed their code overwriting updates me and another person worked on that we didn’t know were broken till two hours after the fact. At that point after our few mess-ups with SVN we got good at constantly updating and committing changes. The problem there was we had, so many build updates that we couldn’t find were the builds went wrong. What was worse was this happened at 1-2am on Monday morning. We worked till about 5 am to get all of that stuff back into the game. At that point, from the lack of sleep at least on my part, I could not remember what I’ve done the past two hours before that. Trying to remember all of the minor bugs fixes and changes was a pain.    

2. Controllers:

Menus are just horrible. Our whole menu system is really bad. I know that. They get the job done, which is the best we could do with the time we had. We had to recycle code on some screens and we didn’t want you to completely quit out of the game when you hit esc. But at that point we had barely any time left, so we had to do some really dumb stuff. When you hit esc and go back to the screen before the menu, it does that because if you go to the menu page it would instantly pickup the esc key and kick you all the way out. We didn’t have enough time to get all these issues ironed out. If we didn’t have so many issues with the menus in the first place, they could of turned out much better.

3. Menus:

Menus are just horrible. Our whole menu system is really bad. I know that. They get the job done, which is the best we could do with the time we had. We had to recycle code on some screens and we didn’t want you to completely quit out of the game when you hit esc. But at that point we had barely any time left, so we had to do some really dumb stuff. When you hit esc and go back to the screen before the menu, it does that because if you go to the menu page it would instantly pickup the esc key and kick you all the way out. We didn’t have enough time to get all these issues ironed out. If we didn’t have so many issues with the menus in the first place, they could of turned out much better.

4. Art:

I’m not saying our art is awful. I think it is not appalling, but it really isn’t that great either. I am a coder and I was doing the character art work and death animation along with another coder who was making all the levels. It is not an ugly game, but it could have been better if we had a dedicated artist.

What To Do Next Time:

1. Learn First:

Our biggest issues throughout the entire project is that we were all doing things we have never done before. But honestly there was nothing we could really do about it unless we made a game like ones we already have. This is my second game and the first was a school project just completed a week before hand. This was all of ours first game jam and the second time we’ve used this engine. It was probably most of our second time ever using python as well. I think you will always be trying something new but you should reduce the amount of new things to a minimum rather then having almost every single thing something new.

Reflection:

In reflection, I am quite happy of where we ended. There is usually always something you want to change and fix. For me just started learning coding 3-4 months ago, for our second game and second use of this engine I am very proud of where we ended up. We just finished our first semester of school and we did this. We had 72 hours and we put a pretty good/fun game out. Yes it has it’s quirks but we are new at this and I expected that. We learned a lot! Everything we learned will be put towards our next semester’s game project. I’m grateful for my teammates and this opportunity. Next Ludum Dare is in April the middle of my semester, so I don’t think I will be able to compete. Though I would love to do so again. It might not be the next one but for the following one I’m game. Thanks for reading. Any advice and comments are appreciated! And reading all the nice comments about our game has been really great! I’m glad people our enjoying it. I hope more people get to play with some friends rather then just the bots because it’s where the game truly shines.

Tags: postmortem

Man Behind the AI: Postmortem (TCOBON)

Game Link: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=21804

Gameplay video: http://www.youtube.com/watch?v=RRsR_DTW6JI

Postmortem of Chase Hutchens:

I’ve been following Ludum Dare for a while, I was definitely interested in entering eventually, I just didn’t expect it to be this one. I actually didn’t plan on entering this one at all initially. But then I saw posts from another group member, which enticed me to attempt to join their planned Game Jam session.

My task was to implement some sort of AI. I had prior experience with A*, so I knew with our layout that will be the best option for getting the enemies to move interestingly. The first time I implemented A* it took me some time, however, that past knowledge was able to allow me to understand the problems that needed to be solved on my end to get it working properly. A* took me a good day to implement, a long with it’s grid generator system.

Now that I had A* working, I needed to begin developing some sort of logic within the bots to provide some sort of interest. This brought forth some difficulties, due to this being the first time implementing AI behavior with A*.

What I ended up doing was creating a bunch of node objects that I placed around the maps. From there, I had to piece together various events for the bots to re-act to. I decided, from past experience using a state-machine hierarchy would be a good strategy. When a bot doesn’t have a shuriken to fetch it would travel around randomly, by selecting a random node on the map. If a shuriken is thrown in it’s direction, it would choose another random node to travel to, in hopes of dodging getting hit. From there, if it was the closest bot to the dropped shuriken it would proceed to attempt to collect the shuriken. Also, the bots would change directions after a shuriken was picked up. This was the majority of where my time lied. Attempting to create code for the bots to know when to re-act to a situation.

Some of the issues I faced during this process was, when the bot chooses to travel to the dropped shuriken, if it was out of reach and not colliding with it, it would hover at the location indefinitely. The bot had to collide with the shuriken to collect it. I had to keep track of how long that particular bot was hovering in the adjacent square. Another issue was a crash bug that would make a bot attempt to continually search for the shuriken when it somehow left the arena. That issue is still somewhat present, where the bots will try to get to a shuriken in a non-reachable location. It does however, seem to fix itself.

Overall, it was both fun and interesting to create a project with like-minded individuals. The AI isn’t great, but I’m just glad I was able to obtain more experience related to working with both AI and A*. I look forward to the Ludum Dares to come.