About unpronounceable

Entries

 
Ludum Dare 36
 
Ludum Dare 35
 
Ludum Dare 34
 
Ludum Dare 33
 
Ludum Dare 32
 
Ludum Dare 31
 
Ludum Dare 30
 
Ludum Dare 28
 
Ludum Dare 26
 
Ludum Dare 25

unpronounceable's Trophies

unpronounceable's Archive

And Now For Something Completely Different

Posted by
Sunday, April 17th, 2016 12:48 pm

I tried something new for me this Ludum Dare. I made a game that is not a video game. It’s allowed by the rules but if I’ve encountered any of them before I haven’t played them. What follows is a post-mortem of the design process.

The rules for the game are available here: Doppleganger. (And I just realized I’ve spelling that wrong this entire time. Oh well.)

The primary thing to worry about when coming up with the rules and how to play was to make sure it was something that was easy to set up and play. To do this I made it so it should require something most people should have somewhere, a normal deck of playing cards.

Originally the idea was for a video game where you’d have to steal people’s shapes to move farther into a secured area. Certain areas would only be available to certain shapes so you’d have to puzzle your way through, scouting out areas you could, finding the appropriate people, then killing them and taking their place to continue. Out of all the ideas I had this was the only one that seemed worthwhile to pursue.

While thinking about how to make everything the idea of making this a physical game occurred to me. Having dabbled in table top RPG and card game design that idea didn’t seem too daunting. I also knew it was allowed, but also knew there would be hurdles to getting people to play it. Any sort of board or custom card game would probably be tossed aside as the time investment of actually getting the pieces ready would be off-putting. So if it used something that everybody would have easy access to that barrier could be lowered. Settled on a deck of cards as it’s a good randomizer, gives clear differentiation between cards allowing easy comparison and ranking, and the physical position of the cards can be used in place of a board. Also most everybody has a deck of cards somewhere in their home.

Having settled on the initial idea and the physical objects to use I started research and designing. Read the rules for quite a few patience/solitaire style card games. While doing this also came up with the idea to make it multiplayer if possible. The idea of changing which card represents you seemed the best way to keep the theme in the game while fitting in with my original idea.

The first design involved setting out a large grid of face down cards and moving through them. You’d be able to take a card that was flipped face side up or flip a face down card over following certain rules. The first few iterations of the game were far too easy, you could reveal any card next to one that was already revealed so the player wouldn’t need to change their shape card too much. It was also too short and not satisfying at all. You could also do this to any card on the edge of the board to begin with, making the field you had to actively explore very small. On a purely physical level the grid was too big, I’m short for the table I was using so I had to do lots of reaching and it was a little uncomfortable.

The main source of not changing was the fact that the reveal rules were to lenient, you could reveal any card of a matching or opposing color as long as you had the right value on your shape card. Tried making the rules more restrictive until I found a good one, the suit had to match. Since every card has about a 1 in 4 chance of being a particular suit (ignoring information gained through play about what cards have been already been revealed or eliminated) this means you have to change fairly often.

This change helped make the game longer, but the board layout was still causing issues. Started with having only the cards in the row closest to you revealed, but scouting through the board was still to easy. So the primary issue was how many you could reveal at once. Made it so you could only reveal cards next to ones that were already near an empty spot and it was still to easy. Solved this and the physical play field size issue by making it so the cards are stacked in columns, similar to other card games of this ilk, and you can only proceed up. Had to keep some sort of ability to scout out to the adjacent columns of cards as sometimes you’d end up in a situation where a column would be locked as there were no cards at the bottom of it that were revealed.

The rules for shifting which card is your current shape have stayed pretty consistent throughout the game. Only changing a bit with the scouting rules to account for the new play field layout.

The actual size of the play field also changed a lot during development. For the final set of rules I found a narrower setup (fewer but deeper columns) was more challenging as this restricted the set of moves the player could take, being more likely so that they were unable to scout or replace any card (in order to deal when this happens there’s a reserve of cards you can call upon, similar to the draw pile in Klondike Solitaire).

One small change I made near the end was making it so the player has to lock up one of the columns at the start of the game when choosing their initial shape. Originally you’d have a small number of cards you could choose from. Any not chosen would be discarded. Removing this allowed me to make the play field slightly bigger and adds some tension to the beginning of the game.

I was able to make a multiplayer version of the game, although it’s limited to only two players as that was the maximum number of players I had available for testing. My favorite part of it is the way the game proceeds. The two players have to start out cooperating to scout through the stronghold while also trying to keep some edge over their opponent (usually making sure they’re the one doing the scouting instead of you). When the target is revealed it suddenly becomes a cutthroat strategy game. You’re trying to get your opponent to act in such a way that they free up the target for taking while trying not to take similar actions yourself.

For each iteration of the rules I’d play it between one and four times depending on how large the change in the rule was. Did around eight or ten iterations of the game. Also made sure to only change one rule at a time to be sure of the differences caused by that one change. Having my wife play the game a couple times and watching how quickly she learned the rules and the heuristics was extremely helpful. More play testing is always better of course but I was limited in time and the number of people quickly available to me. In all the process from idea to final design took me from Friday night to early Saturday evening. The rest of the time was spent writing out the rules, making diagrams, rewriting the rules, then rewriting them again. It was also quite interesting working with a deck of cards. In some ways it’s very limiting as you only have a finite set of objects you can work with and you also have to make sure the rules are easy for people to process (meat computers are good at simple fuzzy rules and not so good at complicated and strict, electronic computers are the opposite). But those same restrictions were also somewhat freeing. Since you only have a limited set of objects it sets a hard limit on what you can do. The search space for possible game designs is much smaller than when writing a computer game. The forced simplicity of the rules mixed with the limited number of objects also makes it easier to see what possible changes could do.

I hope everybody that gets a chance to play it will have fun, and give feedback on areas that may need more clarification. If there is time available before the contest ends I’ll try to port it to the computer. Also very interested to see how a more traditional card game will do in Ludum Dare.

The Halls of Oszmot – Post-Compo Version

Posted by
Sunday, August 30th, 2015 4:43 pm

oszmot_pcss

Went through and made some improvements based on comments, as well as some other things I thought of after the weekend was over. There’s a link at the bottom of the page where you can download it.

– All new art.
– Fire can no longer miss.
– New descriptions for attacks.
– Now able to pick up something you’re standing on.
– Added new action. Leaping will you let you move around fast, but also makes you prone for a short while.
– Corpses no longer block movement and can no longer shoved.
– General bug fixes.

Get it here.

In Again

Posted by
Wednesday, August 19th, 2015 5:51 pm

This will hopefully be my 7th LD game.

Will be using some base code I’ve been refining over the last few competitions (and in my spare time), it’s available here.

Code: C using SDL2 and OpenGL, Visual Studio 2013 for IDE and compiler.
Art: Paint.net mostly, maybe Spine and TexturePacker
Sound: BFXR, Audacity, and autotracker.py

In For Another Go

Posted by
Wednesday, April 15th, 2015 9:26 pm

Will be joining the compo and using the base code I’ve been refining the last few Ludum Dares. It’s available here.

Code: C using Visual Studio 2013
Art: Paint.net
Sound: Bfxr and Audacity.
Music: autotracker.py, unless I can find an easy to use tracker in the next couple days.

Best of luck to everyone.

In Again

Posted by
Wednesday, December 3rd, 2014 7:27 pm

Eye Tools: Paint.net, maybe Spine.

Ear Tools: BFXR, Audacity, and autotracker.py.

Brain Tools: Visual Studio 2013, C, SDL2, OpenGL, and caffeine.

Base Code: Here

Affinity Post-Mortem

Posted by
Friday, September 12th, 2014 4:42 am

affinity

What Went Right
1. Spending time writing some library code before the contest
Is it the fastest? No. Does it have the most features? No. Is it well written? Probably not. But I knew every bit of it. If any problems came up it was obvious where. If anything needed to be changed there was no problem ripping things out or quickly throwing them in as I knew what problems could happen.
Knowing everything that was possible with it, and knowing how it was built also made it much easier to choose a design. My previous entries were made using existing ActionScript libraries and often I would spend a good portion of time trying to see if something was possible or attempting to fix some small problems I would run into that required code changes in the library.

2. Minimal art
Being primarily a coder making any sort of sprites or recognizable characters is time consuming for me. However I can put together decent particle effects, which ended up being on of the main graphical effects used. The only other part, aside from the menu buttons, were the connections. These are generated at run time and are the visible aspect that took the most time to get right.
I’m not too happy with the colors though. Was going for something that would be color blind friendly since it is a big part of this game. Since there’s supposed to be four identifiable colors this constrained my choices.

3. Healthy living
A good nights sleep and non-junk food do wondrous things for productivity. In previous LDs I would sometimes get caught up in making stuff and stay up too late on Friday night which meant I was exhausted the rest of the weekend.

What Went Wrong
1. Game is too confusing
Lots of people mentioned it in the comments and I knew it was going to be a problem. It’s hard to tell how close you are to actually beating a level, and I also feel like the goal isn’t entirely clear. Going for a minimalist art approach with no hud hurt me here as it would have been very easy to put some sort of meter or bar that let the player have this information.
It’s one of those things that could have been fixed with more time. But that’s part of the fun of Ludum Dare, sometimes you just have to go with what you have and see how far you can push it.

2. Level design and difficulty tuning
While I have gotten better at it I still lack an intuitive grasp of how difficult things will be. The levels are built with a series of lessons in mind going from the least to most difficult. From the comments it seems people were either too confused about what they had to do, or found the levels too easy.

3. Not enough play testing
The above two could have most likely been solved if there had been more eyes on it. As it is the only other person who played it before it was released was my wife, but she was privy to the entire development process so already knew what to expect.

Parting Thoughts
Thanks to those who read this far. But I have a question for you. Should I continue development on this? I always feel a little guilty letting my projects just sit on my hard drive.

Play Here

In Again

Posted by
Friday, August 22nd, 2014 2:06 pm

This will be the sixth Ludum Dare I’ll attempt.

Will be using Visual Studio 2010, SDL, Paint.Net, Audacity, bfxr, and whatever I can find to make music for me.

Last time I tried doing the entire thing using C and SDL. It was a failure because I spent most of my time writing code for basic graphics and audio handling, so I’ve prepared some basic stuff ahead this time. It can be accessed here: https://sites.google.com/site/unpronounceablegames/LD30%20Base%20Code.rar

Good luck to everyone!

[cache: storing page]