csanyk.com

video games, programming, the internet, and stuff

Category: games

Mega Maker

Mega Maker is to Mega Man what Mario Maker is to Mario.  Except, it’s not an officially licensed Capcom product, and it’s free. Built by fans using GameMaker, it’s probably the best thing I’ve ever seen built out of GameMaker.

It’s awesome.

It’s very easy to use, and a lot of fun. Not that you really need it, but there’s a tutorial that explains everything in the editor with great style.  Actually, the tutorial is very well done and I recommend using it to understand some of the finer points.  But most of the point and click interface is intuitive to anyone who’s used a mouse-driven interface and knows a thing or two about Mega Man.

Mega Maker

I had my first level built and running in about ten minutes.

Unfortunately it only includes a small sample of the Mega Man resources from the first six games on the NES, but even so there’s a lot that you can do with the designer. There doesn’t seem to be any provision for designing your own enemies, bosses, or adding your own sprites or music.  On the other hand, there’s zero coding needed, and it’s easy enough to use that an average grade schooler could get up and running designing levels in no time.

There’s an online community for uploading your level designs and downloading and playing the designs of other players.

So much work has gone into this, and it holds so much promise. I hope that Capcom sees fit to muzzle their legal team.  If you’ve ever enjoyed a classic MM game, you really need to download this and give it a try.

“Atari” releases new images of upcoming, mysterious AtariBox console

As soon as I found out about it, I signed up for announcements about the AtariBox.  Today, the company currently owning the rights to call itself Atari released some new images of what the console will look like. I think they look quite nice, for what it’s worth. It’s tough to say, but I’m not convinced that these are photographs — they could very well be 3D models from the mock-up phase, that have been approved for production.

AtariBox AtariBox AtariBox AtariBox

From the announcement:

Our objective is to create a new product that stays true to our heritage while appealing to both old and new fans of Atari.

Inspired by classic Atari design elements (such as the iconic use of wood, ribbed lines, and raised back); we are creating a smooth design, with ribs that flow seamlessly all around the body of the product, a front panel that can be either wood or glass, a front facing logo, indicator lights that glow through the material, and an array of new ports (HDMI, 4xUSB, SD). We intend to release two editions: a wood edition, and a black/red edition.

We know you are hungry for more details; on specs, games, features, pricing, timing etc. We’re not teasing you intentionally; we want to get this right, so we’ve opted to share things step by step as we bring Ataribox to life, and to listen closely to Atari community feedback as we do so. There are a lot of milestones, challenges and decision points in front of us in the months ahead. We’ll be giving you lots more information and status updates as we progress, and we are thrilled to have you along for the ride!

The HDMI is not a surprise, but it’s good to see that the AtariBox will use standard USB ports and an SD slot. Proprietary ports are all too common on game consoles, in order to lock consumers in to buying officially licensed peripherals at considerable markup.

What the console looks like isn’t all that important, but from what I see so far, this isn’t bad.

We still don’t know what the consoles hardware capabilities will be… but what the console’s specs are isn’t all that important, even.

What matters is what games it’ll play, and if they’re any good.

How can Atari create a unique platform for games that is simultaneously contemporary yet pays good homage to the past? It remains unknown.

Super Greedy Ghost Grab – A Cleveland Game Developers Summer Jam

This weekend, I took part in Cleveland Game Developers Summer Game Jam 2017. This year, I worked with a team consisting of Wally Pease, Bobby Lauer, and Colin Wolfe.

Our project, Super Greedy Ghost Grab, turned out really well. I really enjoyed working with our team, and I think everyone executed on our project extremely well.  The deadline build isn’t perfect (and no game jam project ever is, so that’s not a knock on what we did). I’m very happy with what we were able to do in 48 hours.

Super Greedy Ghost Grab

The theme for the jam was announced: Identity. I didn’t have any good ideas at first, but eventually our team decided to make a game about a ghost who can “possess” things, becoming them, and assuming their identity.

At first we were going to have the ghost possessing people, but we quickly realized that the scope of such a project would be unmanageable for the time and resource constraints we would face, so we decided instead for the ghost to possess objects.  To give the game a story, we decided to put the ghost in an art museum, and made the ghost an art thief, who must avoid detection by a security guard.

I came to the jam intending to work with Wally, but Bobby and Colin joined us and were very productive members of our team.  We had two full-time artists (Bobby and Colin) and two programmers (Wally and me).  Wally also recorded sounds and did some of the art as well. Between the two of us, he even did the bulk of the programming, laying out the main engine, player, and “possessable” art object, while I provided the “googly eye” effect for the possessed art objects, and implemented the guard, and also lent a hand with debugging, polishing, and general play testing.  In addition to providing some of the art for the project, which included the Ghost and Statue sprites, and floor tiles,  Bobby also did our level design. Colin contributed the guard sprite, the diamond, the vase, the paintings, and the pillars, and also touched up and organized the wall tiles. Their artwork was excellent, and they were able to produce exactly what the project needed.  Everyone’s art worked well together, too, which I’m not sure how that happened, but it’s impressive that three different people working on art could come up with a consistent and seamless style.

This was my first game jam where I got to work with another programmer and shared programming duties. I found that things went very well overall. We had a few hitches when merging code, but nothing terrible. We didn’t use a formal version control system, which was part of the problem. At first we relied on Google Drive to share files between team members, but when it comes to uploading revised versions of files to Google Drive, some very strange things started to happen. Apparently when a user “deletes” a shared file on Google Drive, it remains available to the other users who have access to the shared item.  Replacing the file with a newly uploaded copy doesn’t replace the original copy, and instead results in multiple versions of the same file.  This created a lot of confusion at first, until I realized what was going on.  At that point, we switched to using Dropbox, and handled code merging using BeyondCompare to handle comparing and moving the code files in the project .gmx.  Wally and I sat side by side, which made it a reasonable way to handle merges. This worked passably well, BeyondCompare made it very easy to merge our changes. But I believe that a true version control system would have been even better.

We also were able to communicate with each other as needed, and be a second pair of eyes for each other whenever we had a “wtf?” moment. I’m really excited about working with Wally more in the future, and would be happy to have more chances to work with either Bobby or Colin again as well.

AtariBox hype, speculation

I’ve been around long enough to know how the Hype Machine works with videogame launches.

First, there’s a teaser announcement. It doesn’t tell you anything, but it’s designed to make you very curious, excited, and speculate about what it could be. The AtariBox website currently has a simple video showing the famous Atari Fuji logo, and the suggestion that a new game console is coming soon.

Next, there’s a bit more information leaked to the right media outlets; Joystiq, Kotaku, Polygon, etc. A few more bare details are leaked, but mostly as unconfirmed rumors. This creates a lot of buzz among the most dedicated followers of games. Gamers are incredibly demanding and fickle, or else ultra-apologist fanboys who will eat up (and forgive) anything. Everyone starts talking about what they hope the new product will be.

Gradually, more mainstream media starts to pick up on the story, and reporting on it. We’re at that point now.

I read the Forbes opinion. The author’s take on it is that gaming consoles have become indistinguishable from each other, there’s too much sameness between Xbox and PlayStation, so (he thinks) maybe Atari can make room for itself in the market by differentiating itself… somehow.

And it’s true. In the old days, there was a lot more variety in game consoles. The hardware developed by various big players and also-rans (alsos-ran?) was widely divergent in its engineering and capabilities, especially in terms of how they handled graphics and sound. Most systems were built around one of two chips: the MOS 6502 or the Zilog Z80, but had vastly different approaches to generating sound and drawing pixels to the TV screen, resulting in characteristics that could not be replicated by any other game console, meaning that each system necessarily had to take a unique approach to implementing a port of a given game design, resulting in vastly different experiences for the same title on various systems (when a title was even released on multiple systems, which wasn’t always a given).

But as engineers iterate, designs gradually converge on what works best. And in 2017 with the launch of the Nintendo Switch, we’re currently at the 9th generation of game consoles.

The thing is, the old consoles were different because their hardware was very different, AND because games were coded in ASM so that they could get every last bit of the very limited hardware’s capability. Neither of those is true now, nor will it ever be again. Computer hardware is extremely expensive to R&D, so open, commodity architectures that are well known to developers will be favored, leading to a convergence in hardware. Games are programmed in high-level languages so that the same code runs on multiple platforms. The result is uniformity.

No new modern console will support some non-standard resolution or unique color palette that will give their games a look uniquely its own. It’ll be 32-bit RGB color, 1080p or 4K, 60Hz or better. Controllers may vary, slightly, but the fact is if a game cant sell on multiple platforms, it won’t get developed (except by Nintendo). So having a unique controller only means you’ll secure a small segment of the market for yourself, while conceding the bulk of the market to games developed to more common/standard controllers. That’s what Nintendo’s approach has been since the Wii. And while NIntendo was successful with the Wii, they stumbled with its follow-up Wii U, and most people believe that Nintendo are only able to continue to be successful on the strength of their first-party IP that they keep exclusive to their platform.

What does that leave Atari? If they think they can go toe to toe against MS and Sony, they’re dreaming. Atari’s R&D and innovation more or less stopped in 1983, despite the last gasps the Lynx handheld and Jaguar console represented. Atari does have some strong IP in their arcade classic titles, but these have been re-released and re-hashed probably on the order of a dozen or more times already, mostly as nostalgia bundles that have been put out for every next-gen console since the SNES, occasionally as “reboots” or “sequels” that never seem to recapture the original magic.

The Ataribox *could* be a cool console, if it embraces retro. I have no interest in a 9th-Gen game system just because it happens to have the Atari name on it. What I *am* excited about is the possibility of a “what if” console, where imaginative game developers do a kind of speculative retro-future take on where 8-bit style games that Atari were known for in the 70s and 80s could have gone — a bit like what steampunk is to science fiction, the Ataribox could be to modern-retro gaming. Think an graphics processor constrained to 8-bit index color graphics, driven by a modern 3+GHz CPU with gigabytes of RAM instead of a few kilobytes, and beautiful (but limited-palette, low-fi) graphics without the sort of severe limitations such as sprites per line, etc.

That’s kind of what I hope it turns out to be. I have no idea, but that would be cool and truly different. Not just another Xbox/PS with a Fuji logo, please.

A Pitfall III that looks and feels like Pitfall I and II, but has all kinds of cool new challenges would be kind of awesome. (Of course, we already have Spelunky… but that’s just it, there’s a ton of retro-inspired modern indie games that could feel right at home on a modern retro console. A few years ago, I had high hopes that the Ouya would be that console. I still think the concept has merit, but whether it can survive and thrive in the market is largely in doubt.)

The thing is, there’s no reason to design special hardware constraints into such a system; a designer can voluntarily impose any such constraints on themselves to produce “retro style” games. That’s what we do now, when we want to.

I’m interested in seeing what the AtariBox is, but my enthusiasm is held in reserve. Why? Simply because at this point we know nothing about it, and because everything about the history of the videogame industry strongly suggests that it’s unlikely to succeed at a level needed to support a large company, and small companies tend to fail.

AtariBox, RetroN 77 teasers 

In the past few days, I’ve become aware of chatter about two potentially exciting new bits of hardware for Atari 2600 fans: Atari’s AtariBox, and Hyperkin’s RetroN 77.

Atari (well, the company who now owns Atari’s trademarks) has scant information about the AtariBox. Beyond the name, we know basically nothing about it so far.

RetroN 77 is a new console from Hyperkin, which is designed to play real Atari 2600 carts, apparently through emulation via the excellent open source Stella emulator, with real controllers, using the same ports as the original, so compatible with 3rd party Atari controllers, and outputting 1080p over HDMI.

Since I know nothing about the AtariBox yet, my early excitement is for the RetroN 77, but that could easily change. Hopefully Hyperkin will do the venerable VCS justice for the HDTV Age.

My hope for the AtariBox is that it will be a retro-inspired platform that caters to indie developers who want to make games in an old school style, that look like they could have been at home in the late 70’s/early80’s, albeit not strictly constrained by the hardware limits of that time. Think what Shovel Knight was to the NES; I’d love it if AtariBox were a platform for the equivalent of such games for the Atari 2600/5200/7800/400/800/Intellivision/Colecovision era of home videogames.

SMW persistent jailbreak hack the best of all time?

I think in terms of impressiveness, this amazing glitch exploit that allows you to permanently reprogram mods into the save data of a Super Mario World cartridge using only in-game input is right up there, neck and neck with the Apollo Moonshot missions.

I can’t even fathom how they figured this out, it’s beyond anything anyone could reasonably come up with. Impressive doesn’t begin to describe it.

 

E.T. was not the worst game of all time.

I’ve talked about this before, but today NPR covered it again.

This is a well known story in the lore of videogame history… There’s a certain amount of misconception about it.

Howard Scott Warshaw likes to talk about how E.T. has the reputation of being the worst game ever, and how between it and the highly regarded Yar’s Revenge, it gives him the greatest range of any game developer. But even he doesn’t think E.T was really the worst of all time. As he carefully states, E.T. is “the game that is widely held to be the worst video game of all time.” That’s a bit distanced from accepting that it is the worst.

It makes for a good story, and he likes to tell the story, and he’s a good storyteller, and he likes to set the record straight when he tells the story, because telling the story takes away the power of the failure to hurt him. He’s a really good sport about it, and a good guy, and was a good game developer when that’s what he was doing. He has a great attitude about failure, and it’s served him well in life. So more power to him.

Howard Scott Warshaw’s game was actually pretty good. I owned E.T. and liked it. It was ambitious, and it definitely had its share of flaws, but it was a much more complicated game than the arcade style action games that Atari was known for, and that was a problem for a lot of gamers who weren’t ready for a deeper game design and complex puzzle solving. The game was difficult, and solving the puzzles was a bit arcane, and the pits that you fall into frequently were rather annoying, but it was not the “worst game of all time” that it has been labeled as.

What it was, it was a huge commercial failure — mainly because Atari overpaid Steven Spielberg $26 million for the license rights to make an exclusive ET videogame. It was one of the better selling games for the Atari, moving 1.5 million units. Unfortunately, Atari had produced 5 million copies, vastly overestimating the market. And reviews of the game were mostly bad, in spite of the high sales. The sales came through more through name recognition and the success of the film, but once people played the game, many of them felt like it wasn’t good enough. And it was rushed. But it’s a very impressive achievement to create something as big and complex as E.T. with the tools that Warshaw had at the time, in as little time as he was given.

Atari were counting on ET to drive more console sales, and it didn’t happen. By 1983, the VCS was a 7 year old dinosaur, and badly needed a replacement. But Atari had a hard time leading the launch of the next generation of hardware, because doing so would have obsoleted their market-dominating 2600 model. They tried with the 5200, but it had several design problems, and this combined with lack of backward compatibility (they did release an adapter later) and expense made it unpopular.

At the time, there wasn’t really a precedent for the idea of computer equipment becoming obsolete in just a few years time, and so many consumers of the day felt like buying a new console every few years, particularly if their old games wouldn’t play on it, was a ripoff. They viewed electronics like a radio or television or record player, which could last for decades if cared for, and newer models could continue to play old media. And old game consoles may still work four decades on, but they are obviously obsolete and can’t play newer games, and newer machines don’t play old Atari games (other than through emulation.)

Meanwhile, Atari corporate had alienated some of their best developers, by refusing to credit them for their work on the cover of the box, or pay royalties, They left to found Activision, which opened the door to any third party releasing games for the 2600, including many fly by night operators who could barely program for the 2600, who put out horrid garbage games that glutted store shelves and gave the Atari a poorer reputation than it deserved, and resulted in the Great Crash.

It’s popular to blame ET for being the cause of the great crash of ’83, but it wasn’t.

 

LD38 results for TARJECTORIES

I think this may have been my best showing to date. I’ve ranked higher in individual categories before (Bad Puppy: #70 in Humor, Alamogordo: #71 in Humor) but I think this is the best that I’ve ranked in Overall and in Fun, which are perhaps the two most important categories. I’m very happy with how the game was received by the LDJam community this time around.

Thanks to everyone who played TARJECTORIES!

ld38 results

 

Great Plays from Ludum Dare 38

Planet Desumaton – siegfriedcroes

Planet Desumation

The gif speaks for itself… Control a small small planet, picking up Asteroids into orbit, and smash them into a large “boss” planet.

Path of the Rabbit – Managore

Path of the Rabbit

A turn based tile strategy game similar to Pipe Dreams. Managore’s games are always top notch, and this is no exception.

Sticky Keys – thevaber

Sticky Keys

A really well polished typing game, with a twist. The keys keep popping off, due to some nasty creepy crawly insects that have infested the keyboard. You have to interrupt yourself and pop the key caps back on in order to keep typing.

Monolith – samlo and david-carney

A rail shooter bullet hell game where you have to lock on to your target by holding still, leaving you vulnerable to enemy fire. It’s high speed and frenetic. The art style is b/w, with what looks to be a procedurally generated fractal landscape, and a monolith that looms over the horizon, and seems to never get any closer.

TARJECTORIES – csanyk

Tarjectories by csanyk for LD48-38: A Small World

Yes that’s right! My own game, this time I think is good enough to qualify as a recommended play. It’s a casual target shooting game played on tiny planetoids that rotate, with procedurally generated levels for added replayability. Patience and accuracy are the keys to doing well. Learn to estimate the gravity and rotation speed of the planet so you can aim your shots correctly. I plan to develop this one a bit further, so stay tuned.

Antivirus – kappaixAntivirus

A nicely designed 2D top down shooter, reminiscent of classics like Gauntlet, 2D Wolfenstein, Berzerk, and Frenzy. When you die you get a fake BSOD game over screen, which adds to the fun. Battle through an area and the size scale changes, making for an interesting and novel transition mechanic.

Plutus – jason-varnell, nathan-hicks, and Apostate Games

Plutus

Hilariously written backstory makes this charming katamari-like feel special. Control the jealous planet (let’s not quibble) Pluto on a quest for revenge and ever greater mass.

Space Mailman – kepons

Space Mailman

Gorgeous but bare-bones wireframe graphics and hard core difficulty make this game tough to play. Deliver mail between planets to make money.

Flight of Claude – lyxil and colm-eccles

Flight of Claude

A beautiful, touching visual story about a baby bird and his nest mates.

Aphosis – urban-logic-games

Aphosis

Divert a doomsday rock on a collision course with Earth by attaching thrusters to stabilize its spin, then attaching a main thruster to push it away. Beautiful graphics, a fantastic musical backing, and extremely challenging game play make this one to try.

That Tiny Pea – thendash

That Tiny Pea

A fairly realistic update of the classic Lunar Lander. Land safely and you are rewarded by being able to step outside and take in the view. It’s hard!

The Life Amoebic – baby-dino-herd

The Life Amoebic

A convincing simulation of an amoeba. Control your amoeba by extending pseudopods with the mouse, and try to grab food to survive, grow, and divide. It’s pretty challenging.

Vixa – spav

Vixa

Spin the world around to dump balls into the green-lit sections and away from the red-lit sections. Green multiplies your balls, red destroys them. Lose all your balls and you’re done. Great graphics and sound, and solid game play make this one a trip to play.

Tiny World Defense – ianmorrison

Tiny World Defense

Fly your spaceship over the surface of the planet, defending it from enemies who want to shrink the planet into nothingness. There were a number of other entries in LD38 with a similar look and feel, a 3D orb-based shooter, where your shots skim over the surface of the planet. Almost like it were a newly-invented genre or something. But out of them all I think this one is probably my favorite of them.

Super Kaiju Dunk City – radmars, emarcotte, steakzzz, ninjavitis

Super Kaiju Dunk City

This is an amazing entry in the Jam category. Super polished, it’s a cross between an infinite runner and a rhythm game, where you control a basketball-dribbling Godzilla-like Kaiju creature, as you relentlessly smash through level after level of targets. I had a blast playing this, and would love to see it as a full-fledged title. There’s not much more to ask for, except maybe an epic boss battle against another Kaiju or super robot, and some kind of breath attack.


That’s all for now… I still have a lot more games left to play. As I find more “great plays” I’ll be adding them here. If you have played something that you think deserves a larger audience, post a comment below.

Until next time!

Debugging TARJECTORIES: a Ludum Dare 38 postmortem epilogue

If you haven’t played TARJECTORIES yet, I encourage you to download and give it a try first.

Next, I encourage you to read the project postmortem article I wrote about the experience I had creating TARJECTORIES over a 48 hour period.

Back? OK.

In the wee hours of Sunday morning, in the midst of my debugging hell hours, I posted this on Facebook:

Debugging a program sometimes is like converting one system of thinking into an equivalent system of thinking, only one that works where the other one fails.

Since you can do this only one keystroke at a time, it’s pretty rough when you’re looking at transitional code and are looking for signposts to remind you of where you are. It’s common when you get distracted briefly to come back to looking at your code, desperate for these signposts.

This can end up making you very confused and waste a lot of time.

How to avoid this?

To put it in more familiar terms, pretend you’re writing a novel, and you want to change some of your characters around, so you need to update the text so that everything Smith says is now said by Roberts. Halfway into this, you’ve forgotten who’s who anymore, and there’s nothing in the manuscript that can help you tell what’s been changed already and what still needs to be changed.

If you keep versions of files, you can run a diff of the current manuscript against the most recently checked in version. If you check in versions at the right time, when things are self-consistent, not in a transitional state, this can be very useful.

If you don’t have, or don’t make use of, these tools, you’re putting a massive cognitive burden on yourself that prevents you from higher order thinking about the problem you’re trying to solve. If you get distracted in the midst of your transitional revision work, it’s like a juggler dropping their balls. One hiccup in the routine and the entire thing falls apart, and the only thing left to do is try to pick it all back up and start over.

The hardest thing is when you keep having ideas and thoughts about what else you’re going to need to do next. Often times a change will have a cascade of changes. Not necessarily code changes, but feature changes, or new features. Each one of these is like someone throwing another ball at the juggler. Even the best juggler can only handle so many things before they slip up and have to drop it. And while a person is juggling, there’s very little else they can do.

If you want to get real work done, don’t be a juggler. They spend most of their time repeating a cycle of familiar tasks that just maintain a status quo, and hardly have time to make any progress with anything else. It looks impressive, but it’s monumentally wasteful.

Learning not to juggle is even harder than learning to juggle, though.

The thing is, when you’re doing game development, design and development are tightly interwoven. It’s not even iterative, it’s sub-iterative. You’re figuring out what’s possible, what’s fun, what you can make work, and figuring out how to make it work, making it, and then seeing what else it needs — all at the same time. It’s inevitable that you will have ideas at every step in that process. And each idea is a ball to juggle. I found it works best to leave myself “TODO” comments throughout the code whenever I have an idea come to me while I’m still in the middle of working on something else, and keeping a notepad handy for things that I observe at runtime. Otherwise, you need to be able to split your conscience like a fractal if you want to have any hope of being able to do all the things that occur to you while you’re in the middle of development.

Holy s—. I’ve been at it since 10pm, and I think I finally just fixed a bug that I’ve been puzzled by for several hours. I can’t even begin to explain all the stupid details that I’d need to in order to convey what I just did.

But here goes anyway.

In my project, I have a planet which has a player on it. I had this working just fine with a single planet.

I wanted to create mutli-planet levels, but when I added a second planet to the game all kinds of things started going wrong because of all these hidden assumptions my code was making about there always only ever being one planet.

So I started disentangling the planet, which was really doing a lot of extra stuff that it didn’t really have any business doing. This stuff was managing other game state, and when you had multiple planets, they ended up screwing with each other as they both were updating the game state. Sort of like a race condition, I guess.

It caused some REALLY bizarre bugs, though.

The level counter went up smoothly until it hit 11, and then it started repeating itself a few times, then skipping a head several numbers, like 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 11, 11, 14, 16.

It also had a strange tendency sometimes to not spawn any player at all, on the second level 11.

I fiiiinally got the problem solved, without realizing that was what I was doing. I just started to give up and work on other problems, when I decided that the planet object should not create its own player. I’d done that early on because it made sense when there is only one planet. With two planets, each would create its own player instance, and then I’d have to go back after and delete one of them at random. This SEEMED to work, but somehow became responsible for the weird level number glitch, and the missing player object on the second level 11.

I STILL don’t get how that exactly worked. It still doesn’t make any sense to me. But when I decided to de-couple the player-spawning duties from the planet object, and instead of two planets each creating a player on it, and then randomly selecting one of those two to delete, I re-did the code to spawn two planets, then randomly choose one of the planets to spawn a single player on.

That fixed it. Like, whoa.

Update: A day later, it finally occured to me what happened, and why. This may not interest many, but for posterity, here’s what was going on:

When I made the game, I started out with a 1-planet room. I had this working so well that I didn’t want to screw it up, so when I was ready to start work on a 2-planet room, I created a new room so I could mess around in it. I had my level counter set up in such a way that after level 8, it would switch rooms to the 2-planet room for planet 9.

I had some code in the LevelUp object that handles this. But the thing about the Level Up object is, it doesn’t do those things when the game room loads. So on the transition into the 2-planet room, there were certain things that weren’t happening. To compensate, I (this was a bad move on my part) copied some code out of the LevelUp object and put it into the Creation code for the 2-planet room, and then failed to maintain this code adequately as I continued to make further changes on the LevelUp object.

So what happened was, when Level 8 is cleared, the LevelUp object does its end=of-level thing, and increments the global level variable, and creates new planets for the next level. It then checks to see if the level is 9, and since it is, it moves to the 2-planet room. The 2-planet room starts, and there’s 2 planets there from the room editor, not from the LevelUp object resetting the level. So nothing weird happens until after Level 9 is cleared, because that’s the first time the LevelUp object levels up in a 2-planet room.

I’m still unclear why the level incrementer goes from 9 to 11 — it seems obvious that it has something to do with there being two planets, but I didn’t have the level incrementer tied in any way to the number of planets. And it’s more mysterious to me still that it gets stuck on level 11, and so displays level 9, 11, 11, 11, 14. If GameMaker Studio had a better debugger, I might have bothered to trace through the script and watch the variables change to understand what’s going on, but I figured out enough to fix the problem without completely understanding it (well let’s hope so).

As to why there was no player at all on level 12, I do understand that. The planet’s Create event creates a player instance, and stores its ID in an instance variable, so it can update the player’s x,y position as the planet rotates. In the two-planet world, of course, I ended up with a player instance on each world. I didn’t need or want both of them, so I figured I’d just randomly destroy one of them, rather than fix it so that there would only be one. So I used a for loop and iterated over an array that should have been as long as the number of planets (2), and picked 1 array index to keep, and destroy all others. I figured I might want to make a 3-planet room at some point, and was trying to make the code work for N-planet rooms, rather than solve the 2-planet problem and leave a 3+ planet problem still unresolved. But sometimes the random chooser picked an array index that was out of bounds for the “keeper”, and so the for loop would go through and destroy all of the player instances. This happened to happen on level 12. It happened consistently on level 12 because the RNG seed value was always the same, and the same number of calls to random() always happen between the start of the game and getting to level 12.

I fixed the code by removing the player create from the Planet object, and put it after the planets are created, using choose() to select which planet if there’s more than 1.

The code works and appears to be bug free, but from a design standpoint it’s still messy. When I get around to doing it over, I will clean things up by removing the 2-planet room, which was only ever supposed to be an experimental room, and re-writing the code so that rather than move to that room when the level incrementer hits 9, it will spawn two planets, instead. This will enable move to remove the duplicate code by getting rid of the now-obsolete experiment room entirely. In retrospect that’s what I should have done in the first place, but because I was so concerned about not screwing up my working 1-planet room, I didn’t want to risk it. But really, all I needed to do was check-in to source control and create a fork to experiment in.

As easy and fast as the progress I made Friday night was, Saturday night was an absolute nightmare of a debugging session, just to figure this thing out and get it working. It’s SO weird how it was sortof almost working. Sometimes it’s a lot better to have something completely not working and obviously wrong. Those kind of bugs are much easier to fix.

The good news, though, is that I kept my Friday momentum through Saturday until I took my long break. I implemented a lot of features and had the game 95% complete, or so I thought. Just that last little bit of debugging took about 7 hours, and now the game is basically done.

So I made excellent progress Friday, and most of Saturday, although I unwittingly introduced this nasty puzzling bug during that progress, which stalled me for the entire night. But I still got so much done so quickly that I’m basically done now.

I have until 9pm Sunday to work on it, but I think it’s pretty good right now.

csanyk.com © 2016
%d bloggers like this: