Ludum Dare 35

Ludum Dare 35 happened a weekend ago, and although I published a postmortem on my LD48 blog, I haven’t posted here about it.

The theme for this one was Shapeshift. The first idea I had was to do a game that played like the arcade classic Asteroids, but where your ship’s shape would shift according to its state. I did a quick proof of concept Friday night, where the ship stretched under acceleration, and while it was a pretty cool effect, it wasn’t really something that made the game better or more interesting than the original. By late Friday I was convinced I was on the wrong track, and should start over with something else, but wasn’t sure what.

Saturday morning, I woke up and briefly considered just giving up my efforts for the weekend, and working on other stuff with my weekend time. In the afternoon I attended a Cleveland Game Developers “Excuse to Create” event, and started over with a new project. In the morning, I’d thought about another arcade classic, Robotron 2084, and I started getting interested in making a twin-stick arena shooter. In part I was spurred by the discovery that the keyboard for my new Lenovo ThinkPad P50 laptop has poor rollover characteristics, which make playing games on it all but impossible. I started building it at Excuse to Create and by the end of the 3 hour session I knew that I was on the right track. What I ended up with was much closer to a Geometry Wars clone than I had originally wanted, but it plays pretty well and I had fun making it.

I would have preferred to come up with a more original concept than that, but oh well. It’s not an attempt at a straight up clone of Geometry Wars, but more of a knock-off. The shape-shift theme comes into play with the target shapes, which “lose a side” when shot and shift into the (N-1)th sided polygon. This gives the larger shapes a kind of “hit points” which makes them take several hits to completely destroy. I thought that would be a novel enough twist, but in practice it plays feels about the same as the original Geometry Wars.

Along the way I learned a few things, all of which are game design rather than programming lessons.

  1. At one point in my development, I had the power-up items be vulnerable to the player’s shots, and also if the player shot a power-up item, they would lose one level of that power-up. This would have made the game a lot different from Geometry Wars, where it’s safe to shoot indiscriminately because your shot has no bad effects in that game. I had hoped that this change would make my game more about aiming and looking where you are shooting, and being careful. But in testing, it just made the game too difficult. As the difficulty of the game ramps up, it becomes a frenetic twitch game where you mostly dodge and run away from a swarm of shapes that are following you, and there’s not really any opportunity to be selective about when you’re shooting or where you’re aiming, and if you do lose a level of power-up, it’s pretty much instantly lethal.
  2. Spawn location matters. I knew that I needed to spawn enemies far enough away from the player that they would not be prone to crashing into a newly spawned instance that appeared directly in their path, leading to unfair death. But I also learned that spawning near the edge of the view makes the game seem more active, and puts more instances in view especially in the opening seconds of the game, when there are few objects and the pace of the game is slow. The compo release has enemies spawning randomly anywhere in the room, and as a result feels much more sparse and too slow during the opening.
  3. Code mistakes can be fun! My original code for spawning a swarm of enemies accidentally placed them all in the exact same location. Since the movement of the enemies is purely deterministic, this resulted in a “stack” of enemies all piled up on top of each other, looking like a single instance. When shot, instead of destroying the entire stack, the bullet would only destroy the first instance in the stack, and the rest of the stack would continue to advance, looking to the player as though a early-invincible “super shape” that took a great many shots to destroy was inexorably running the player down, and the player’s shots merely chipped off lesser shapes, which then joined in the attack. I liked the effect so much that after fixing the swarm spawn code in the compo release, re-added a toned-down version of this to the post-compo branch.

In looking back over my Ludum Dare games, I’ve come to realize that I’ve felt overly negative about my performance in LD48. I do have high standards for what I think makes a good game, and so naturally I feel disappointed if my efforts fall short of that mark. In my first few events, I was happy just to have proven to myself that I could build something playable in under 48 hours. In later events, I became disappointed that my abilities didn’t improve as fast as I wished they would. And, really, unless I take game development as a full-time occupation, it’d be hard to improve as fast as I would like. But perhaps an even greater sense of frustration has come from my inability to come up with a good idea for a game — or rather, a good idea that I could complete with my abilities in 48 hours that fit the announced theme. Particularly after the submission deadline, when I’d see so many good games produced by others. But if I focus on the 8 games that I did complete, rather than the 6 LD48 events I didn’t submit for, I’m able to view my work more positively. In the immediate aftermath of the event, I would always feel a certain amount of frustration and disappointment in some aspect of the game I’d made — some feature I struggled too much with implementing, some stupid bug that I got stuck on that took too much time to fix, some feature I had to drop for lack of time, something that was missing, but I couldn’t figure out what it was that the game needed, or something that just wasn’t quite right. But looking at what I have produced, there are some good ideas in six of the projects, and I’m happy about that.

>>> Play Shape Struggle <<<

GMC forums upgrade

YoYoGames recently decided to overhaul the GameMaker Community Forums. Formerly run on IPBoard, they are moving to a new solution.

YYG did the right thing, by asking the community for feedback on how they’d like to preserve the historic threads in the old forum system. The old forum will be retained, frozen in read-only mode, with no sign-in allowed. I’m a bit concerned about not being able to log in any more, since it was easier to find content that I had posted or replied to that way. It would be nice if the forums could be read-only but still allow existing users to log in. But, as I understand it, the IPBoard has had many security problems, and so disabling login probably helps mitigate privilege escalation attacks.

When the new forum goes live, users will need to re-register their username. I had suggested that YYG reserve the user IDs of all existing users and send an invite email to them, to claim their old username. I don’t believe that this suggestion was adopted, however. It would have been a good thing, though, as there’s been concern that pranksters might claim famous user names from the old forums and impersonate users. Hopefully this will not be a big problem, but a way to either carry over the old user accounts or else reserve the account names and send invites to users to claim their old username would have been a great way to avoid the problem altogether.

Currently the old boards are down while the upgrade is happening. The migration is taking several days, during which the boards will continue to remain down. I don’t understand why it should take such a long time and having the boards unavailable for an extended time is disappointing; I would think that YYG could have the new forum software staged in a testing environment that could be moved to the live server with a simple press of a button to trigger an elevate script. Likewise, I would think that putting the old forums into read-only mode could be achieved without taking the forums offline at all. Why this wasn’t possible, or wasn’t the best way to take on the migration, I don’t know. There was a very active thread discussing this, but… it was on the old forums, which are currently down.

Based on what I read, it’s unclear at this time whether the url of the old forums will continue to be gmc.yoyogames.com, and the new boards take a new domain name, or if the old forums will be moving to a redirected url. My hope is that the old URL will be preserved, so deep links to old threads will not be disrupted, and the new forums will have a new domain name. However, my guess is that the new forums will use the existing gmc.yoyogames.com domain, and the old forums will probably be redirected, or simply moved.

It will be interesting to see the new forums, how they are organized and curated. Hopefully YYG have learned from the years they maintained the old forums, and will have many improvements. The biggest item on my wish list is to allow file uploads and hosting, so that project files no longer have to be hosted on external services, which tend to fall victim to link rot over time.

The developer community surrounding GameMaker has long been a valuable asset to YYG. In a lot of ways, it’s probably their best asset — the community has always been very helpful for helping new users solve problems and turn into seasoned, experienced programmers. Hopefully the new forums will continue this tradition for many years to come.

Hands On Introduction to Agile: reflections

So last night after work I went to the Cleveland Agile meetup, where we did a “Hands on Introduction to Agile” workshop. It was really fun. Even though I’m reasonably well acquainted with Agile concepts, I got a lot out of the experience.

We didn’t use computers or programming in the workshop, which made the event accessible to non-technical people who didn’t have specialized skills.

The workshop was split into two exercises.

For the first exercise, we split into four groups of about 6 people. We were sitting at tables, and each table had a pile of Lego pieces. We were instructed to split the pile into halves, and then spend 60 seconds sorting one of the halves, according to whatever sorting method we felt like using. We quickly sorted our pile by color.

Then, the facilitator re-assigned my team to work on the project on the table next to us, and told that team to work on our project.

The other team who’s work we inherited had barely done any sorting. All they had managed to do was take the pieces that had wheels and separate them from the rest.

Our project was to build a structure using each type of Lego piece only once. No duplicate pieces were allowed. We weren’t told what to build, just to connect bricks together. Our team split into two groups, one for each pile of Lego, and each built a structure. We quickly re-sorted our badly-sorted pile, and then did a second-order sorting to weed out all the duplicate pieces, then assembled the rest into a disorganized hodgepodge structure that had no architecture or form. We barely had enough time to do this. The other half of our team took the unorganized pile from the first sort, and did their own structure.

We were asked which half of the Lego piles was easier to work with, and obviously the sorted piles were better to work with. It was much easier to pick out the duplicate parts from the sorted piles, so construction from the sorted piles went faster and smoother.

I was expecting we’d do another iteration, and that it would involve changing the structure in some way, and so I was worried that the haphazard, planless structure we had built would be unsuitable for modification, and that this would teach us another lesson about the value of planning architecture, or refactoring, or maintainability. But we actually stopped with the legos at that point.

I asked the facilitator what we might have done had we been asked to do another iteration, and he said maybe it’d be a project to combine the two structures that the two halves of the team had built, with a requirement that we keep to having no duplicate pieces. I thought that would have been pretty interesting.

It’s too bad that I didn’t think to take pictures of the stages we went through, as it would have made this article a bit more fun to read, and easier to understand, I think.

For the second half of the workshop, we split the participants into two groups, counting off by twos. Ones were asked to find a Two to partner with on a project. It happened that we had an odd number of people, and I was the odd man out, so I was joined to a group, creating a group of three. This turned out to make the experience more interesting for me.

Once we had our pairs established (and my triad), we separated, the ones stayed put, and the twos went to another room, where we talked for about 10 minutes about why we were interested in Agile, who among us were actually “developers” in real life, etc. It was just conversation to pass the time. After ten minutes, we went back to meet with our partners. They were the project’s business requirements stakeholders, and had written up instructions for us, the project developers. They handed off the instructions, and before we were allowed to read them or ask any questions, they all left the room. We developers were given ten minutes to figure out the instructions and follow them.

The instructions were to draw a figure. The instructions were difficult to understand. We didn’t know *what* we were drawing, only a description of the various aspects of the drawing. The instructions specified the color of the lines, and described shapes that the drawing included, but it was hard to visualize from the written description. We muddled through it and did our best to figure it out, but we were not very confident in what we produced.

It turned out that our drawing was reasonably close to what was asked for, but the lesson we took from this was that the process was more difficult and less certain than it would have been had the “business requirements” person stayed with us and been available to answer questions and provide feedback to us as we were working.

After reviewing our drawings and discussing how we felt about the experience, we switched roles. The Twos took on the role of the business requirements analysts, and the Ones departed to allow us to work on instructions for how to draw a new drawing. This time, though, the business analysts were allowed to stay with the developers while they worked, and the developers were allowed to ask us questions. We business analysts weren’t allowed to interfere by volunteering feedback, but if the developer had a question we were allowed to answer it.

Since this was the second time we were doing this, and we both had a little bit of experience with it, and had seen the previous finished product, it was a bit easier. But being available to answer questions made an even bigger difference. We could eliminate the uncertainty in the developer’s mind about what they were trying to draw, and give them confidence that enabled them to move forward with each step successfully completed. The finished drawing was extremely close to the model this time; only if we’d been able to provide detailed measurements of line segment lengths and angles would it have been able to be improved.

For me, working as a pair team, this experience was more interesting. I not only had to deal with the written instructions, but I also had to figure out how to work effectively with the other developer on the team. I don’t often get to do real pairing, and working with other programmers has always been somewhat mystifying to me. So this was a good opportunity to try to figure out ways to work effectively.

For our first project, I tried to decipher the instructions step by step. It seemed that some of the steps were very complicated and difficult to understand, while others were relatively simple and straightforward. It occurred to me that we might run out of time trying to figure out the very complicated steps, and not get to the simpler steps. So I volunteered the idea that we should try to draw out the parts from each step separately, then figure out how to combine them. Tackling the project in a modular way seemed like a smart idea, but since we didn’t have the means to cut and paste the drawing elements, it meant a bit of re-work as had to we re-draw the bits from each step that we’d created during what essentially had turned into tiny sub-iterations for the “release version” of the drawing. While this did take some extra time, I think the final drawing ended up being better for it.

The instructions were not very well organized, either. When I got down to Step 7, I found that it referred back to Step 2, providing some additional clarification, but in a way that would have made us have to throw out the work we’d already done on Step 2, if we’d done Step 2 without first reading the entire set of instructions. We ended up drawing the different parts from each step separately, then puzzling out how to fit them together — the instructions were probably the least clear on this. They specified that lines should not overlap and that the different parts of the drawing should all connect, with no un-attached line segments, but it was unclear how exactly this was to be accomplished. What we ended up with was pretty close to correct, but we really had no idea how close we were until we saw the “prototype” drawing that the instructions described. But I did find it helpful to have a partner who I could discuss with while puzzling through the instructions together.

When it came to writing up the work instructions for the second iteration, partnering wasn’t easy either. We ended up just writing up our own instructions separately, then comparing what we’d come up with, and picking the superior of the two, which happened to be mine. Mine was clearer, simpler, and more complete. But again, having a second pair of eyes helped, and my partner made some suggestions to improve a few minor points that needed additional clarification. When our developer came back and worked on the instructions, he only had two or three questions as he followed the instructions, one of which was a matter of not being able to read my handwriting, the others being about specific angles, which I’d been somewhat vague about. But his drawing was very, very close to the shapes and lines we were describing, correct in all the major details, and only off in terms of specific lengths and exact angles, which we didn’t have time to measure or describe in the time we had to create the instructions.

Figuring out how to work effectively with someone on a project is always a challenge for me, especially with people who I have not worked with previously. But it seemed to go very smoothly with these exercises. In part I think this was because they were especially simple, and it didn’t seem like there was a need to do a lot of discussing about who should do what, or how to do it. We just sort of dove right in, and did it, and we didn’t seem to get in each other’s way all that much, if at all. With more complex, more serious work, this doesn’t seem to work as well, and I have yet to work on a real project with a pair programming approach. I would really like to have this sort of experience sometime.

I won a contest

Last month, a youtube channel I follow called The No-Swear Gamer had a contest to win a knitted Space Invaders hat made by SETXNerdery. I went over to NSG’s facebook page, entered the contest, and to my surprise, I won!

The hat arrived in my mail on Friday, and I have to say, I really like it. Even if I don’t especially like winter.

31ca2261-8dac-4a8d-8522-3416e880b3cb

The acrylic yarn is soft and the hat is warm and fits on my head pretty well. SEXTNerdery has some other hat designs that are fun if you’re a retro gamer, so give them a look.

No Swear Gamer does a nice job of reviewing classic games for the Atari and other retro consoles, and provides a lot of detailed information, including some secret information like easter eggs. He has a good knowledge of his subject and doesn’t rely on stunts or gimmicks to attract viewers (aside from the occasional hat contest) — just solid information and opinion.

Cleveland Game Developers Level Up 2/20/16 workshop

LEVEL UP: Jumpstart Unity Game Design with Playmaker with Bill Whetsel

Saturday, Feb 20, 2016, 1:00 PM

Lakewood Public Library Main Branch
15425 Detroit Avenue Lakewood, OH

2 Video Game Developers Attending

About LEVEL UPLEVEL UP is an ongoing series of workshops that focus on honing one specific skill or technique that has application in game development.The 2/20/16 presentation will cover the core concepts of using Playmaker, a visual scripting environment for Unity. We’ll explore concepts and basic mechanics for a simple Side-scroller or Endless …

Check out this Meetup →

Global Game Jam 2016: Pug Pug’s Bathtime Ritual

Global Game Jam 2016 has concluded. I completed my project this year, and I’m pretty pleased with it.

pug_pug's_bathtime_ritual_alpha5

The theme for Global Game this year was “ritual”. I didn’t have an immediate idea what to do for my game, but after about 20 minutes I decided to do a game about a Pug’s bath time, which I called Pug-pug’s Bathtime Ritual. It is pretty common knowledge that I like pugs, which made this project especially fun.

Taking inspiration from this video:

I decided to make a simple minigame about knocking down bottles. I had some ideas for other minigames that I could link together, but there wasn’t time to do more than one. I worked at a relaxed pace, didn’t stress or overwork myself over the weekend, and completed the project about an hour before the 3pm submission deadline. It’s not terribly challenging, but it’s cute.

There’s a playable HTML5 build and a Windows build, along with full source, as well.

#ilikepugs

Global Game Jam 2016

Once again, this Friday I’ll be joining with my fellow Cleveland Game Developers friends to participate in the 2016 Global Game Jam. I’m looking forward to hearing what the theme will be this year, and seeing all the games the different groups at the Shaker Heights location will create. Special thanks to Launch House for hosting us again this year!