Wang Tiles in Python

After reading about others’ development strategies for the 2013 7DRL I stumbled upon a post by one developer who mentioned off-handedly using Wang tiles for the level generation in his game. Naturally, my interest was piqued as I have always been interested in procedural generation and never had heard of this concept before. After searching I found a rather sterile Wikipedia entry followed by this rather useful article on the topic. The core idea of Wang tiles is that as long as all the edges of each tile in a tiled surface match the edges of their neighbors the tiles will appear congruous and can be used to add complexity to a texture or game easily.

Interestingly enough, it’s also easy to generate an entire grid and fill it with Wang tiles. You can place the tiles row by row and you only need to ensure each new tiles’ connected edges match the tiles already laid down above and to the left of it (if those tiles exist.) Otherwise, you can use any tile in the set. I decided to implement my own Wang tiles system using pygame. As you can see, the implementation is straightforward and allows for easy expansion for adding more side-types (currently having two: closed or open.) I’ve added a snippet of the resulting image generated by the program below. Wang tiles are a very interesting, and simple, concept. I’m glad I discovered them as I’m sure I’ll put them to good use in the future!

Click to view full image

Day 7 Conclusion

A sample of combat in the game

Well, Day 7 has come and gone and I’m glad to say that I have something playable at least. It’s not the most fun and is mostly luck based but it’s something. I may keep working on this game anyways (especially if anyone likes the game or at least the vision behind it.) It’s a very simplistic completely text driven game. Some key features: menu system, limb simulation, detailed text based combat. My thoughts on why I wasn’t able to complete a more advanced game in the time-span are detailed in this post. I would definitely like to compete in a future 7DRL and I will likely compete in the upcoming LudumDare so I have that to look forward to! The game (which is also the source, thanks to Python) is available for download here. You need to have Python 2.5-2.7.3 (2.7.3 being the version I used to develop the game) to be able to play. I tried to get Python 3 compatibility working however Unicurses would not cooperate with me and I didn’t have enough time to try to figure out why. If anyone needs help getting the game to run feel free to post a comment to this post and I will help you as soon as possible.

Day 6 of the 7DRL

Well, Day 6 is here and nearly over now! The game is starting to come together a bit and although it’s still completely luck-based it’s at least a bit more enjoyable than before. However, I think at this point in time I can safely say I won’t be reaching my initial vision for the game (or even the second, third, or fourth visions.) Still my enjoyment of working on it is high and I’ll have something playable by the end of tomorrow. I plan to release all the source code up to the end of the 7 days once I’m done with it although I may work further on it afterwards. Seeing as I’m declaring this an early “failed” game, I decided I should write a bit of what I’ve learned from this experience.

Lessons Learned

• Developing a complex menu-driven interface is NOT easier than making a “traditional” roguelike.
• Having everything be text based means lots of time is spent making sure that details of every action are spelled out with proper grammar. This takes a lot of time and code.
• RPG mechanics are quite hard to balance! Most games I’ve made before this were either simple arcade games or platformers where I can clearly see what is happening and adjust it easily. Not so with an RPG.
• Don’t use ncurses / pdcurses. Just don’t. There are better libraries out there that will save you a ton of time and are a lot more modern.
• Don’t attempt to use a language which you are not INTIMATE with. I spent nearly half the time reading the python documentation and stack overflow for help figuring out how to do simple things.
• Don’t worry about code readability (especially if using Python.) To be fair, however, about halfway through I realized I likely wouldn’t finish the project in time so I started commenting the code much more in case I decide to take a break from working on it after the event is over.
• Don’t start playing Skyrim again “just to see if it’s still any fun.” Yeah, I lost all of Day 4 to that one.

This is actually my third “rapid development” event as I’ve competed in LudumDare twice. For both of those games I took a much smaller scope seeing as I had only 48 hours (and not 48 hours of my choosing) to create the game. Whenever I read about the 7drl I assumed I could take on something with 4x the scope of one my past entries. In reality, I probably could have completed something around 2x the scope of my past efforts. I love these types of events, however, because they really allow you to be discerning when it comes to programming ideas in terms of “how much time” something may take. I find that to be an invaluable skill.

Day 5 Summary

Well, it’s already Day 5! Things are definitely starting to come together now although I still have severe doubts that the game will be any fun to play by Day 7. Still, this has been a fun experience thus far. I’m planning to work further on the game after the competition is over as I feel there are some interesting things to learn from completing and balancing a game like this.

Today I fleshed out the combat much further. Guns need to be reloaded after expending their clips (although all gang members have infinite ammo to reload from still.) Also, whenever firing more than one round is simulated and the rounds can hit multiple body parts of the victim at once. Whenever the head of the player, both legs, both arms, or the torso is destroyed the player is dead. Currently the combat is completely autonomous although I find it is interesting having to manage your gang from a kingpin perspective rather than controlling them directly.

Tomorrow I continue to add more events and happenings and complete the equipment system. Also, I hope to be able to build a system to put gang members “on the bench” so they can heal and won’t be involved in combat. That would add a bit more strategy instead of just having them as meat puppets in combat to absorb a few bullets before being discarded. Anyways, back to work!

Ideas are starting to solidify. Finally.

I’ve settled on the idea of breaking up the game into two simple phases. Preparation and reaction. Each “turn” which will be one day starts allowing the player to buy goods and services and manage their gang and once they are ready they can start the day rolling. At this point random events including combat with the enemy gang can occur. If nothing interesting happens during a day your gang will demand drugs to keep them entertained otherwise they become angry and may leave your gang. After being in your gang for an extended period of time you’re going to need to hook them up with some hoes to keep them happy. The combat still needs a lot of work to be functional as I want to have limb simulation integrated. After all, who doesn’t want a one-legged crack head in their gang?

So much more to do!

Well, it’s two days in. I had a LAN with some friends last night so I didn’t get much done then. Things are moving slow but steadily at the moment. I’m already beginning to simplify my plans because the original idea is likely going to be a bit hard to reach given the time left.

Gangs7er

I’ve decided to participate in the 7DRL this year as I am unemployed and have no excuses not to! I’m planning to use Python with Unicurses despite my limited experience with the language and library (see my barely worked on casino game for reference.)

The Idea: Manage a gang of miscreants and take over the city by destroying the kingpin of the current top dog.

The Reality: It’s likely going to be a very simple game indeed but if I like the direction it’s going I may work on it further after the contest. No promises though because I tend to be very lazy indeed!

Redington Pass shooting areas shut down

A saguaro cactus seen during the journey

After trekking up the mountain with my brother and father we learned that the unofficial shooting ranges there were shut down earlier this year.  Apparently federal officials have shut the ranges down due to litter and noise pollution. I noticed that Wikipedia was out of date so I updated it to reflect the new state of affairs. Hopefully the ranges will reopen again someday!

Solving some common Yamaha KX88 issues

After purchasing a used Yamaha KX88 for a great price over a year ago I have run into a few issues that have caused me many a headache. While this is a great midi controller keyboard, it does suffer from degradation over time as any other piece of equipment. I thought I would document a few issues I’ve ran into and the solutions that worked for me on my blog just in case anyone else has the same problem. Hopefully this will help you to solve it faster than perusing endless forums for the answer.

First things first: download the free version of MidiOX. This allows you to read midi controller data in a raw format. Often times seeing what midi data is being sent to your computer will expedite the process of finding a solution (whether it be in software or hardware.)

First thing is first. Try resetting the keyboard to factory settings. To do this, hold down the “A” and “B” bank buttons while powering on the device. After it’s on let go of the buttons and the LED displays should both read 0.

Issue #1: Pitch bend wheel causes many notes to play or corrupt midi messages.

This issue took awhile to figure out the cause and I eventually narrowed it down to a faulty internal clock in the KX88. Luckily, Yamaha included a process to disable the internal clock. All you have to do is hold down the “MODE” button while powering on the controller and the internal clock will be disabled. This fixed the issue for me. It does, however, disable the built in arpeggiator functions however this isn’t too necessary with modern software but if you are planning to control a hardware synth this might be a deal killer for you. If you are buying the controller used it’s advisable to bring a laptop with a copy of MidiOX along with you to test that all MIDI information is being sent across in a non-faulty state.

Issue #2: Keyboard is stuck in DUAL mode or any other mode.

I tried many things but I eventually figured out that this is a pretty common issue with the keyboard. It is easily fixable however! The reason this happens is because the keyboard cannot change modes if it is processing input. Whenever I was experiencing the issue hitting MS1-MS4 would freeze the keyboard and I would have to power it down and back up to get any response from it. My solution was to use MidiOX and play every note on the keyboard by hitting it fairly hard. Eventually I found one note that was “dead.” I got a can of compressed air and depressed the note while putting the straw in between the key and the black felt and sprayed it there and then hammered the key a little more. Eventually the note started playing again and I was able to switch modes freely without experiencing any freezing.

I hope this has at least helped someone to fix their KX88 issues. It’s a great controller keyboard and I would hate to see someone replace it when it can be fixed easily.

Learning SFML for C++ Part 2.1

I’ve made some updates to the game. Terrain destroyed is now darkened instead of removed to show where terrain used to be and to give the illusion that there is more depth to the terrain. This is similar to other artillery games out there, but I feel it does add a bit to the destruction. Also, you can now control the angle and power and shoot a simple projectile from the left-side tank. Next I need to implement a turn-based system, wind that is randomized between turns, and the ability to switch between weapons.

A video showing off the new changes can be found below: