Category: development

mmap mini maps asset temporarily withdrawn from GameMaker Marketplace

Well, they SAID it’s in beta.

I’ve been struggling with updating my mmap mini maps asset pack in order to fix a bug that I discovered with it. Since I’ve been unable to do so, I’ve elected to temporarily withdraw the product, rather than continue selling a broken asset. I’ll have it back up as soon as I can get it fixed, but I don’t know how long that may take, due to problems I’m having with the tools.

First, the bug. In the mmap mini maps package, there was supposed to have been a collection of Macros (what used to be known until recently as “Constants”), which I used to assist with programming the Mmap object. When I built the Asset Package, I failed to realize that these Macros did not get included. Without the Macros defined, the project doesn’t work.

One workaround would be to add the macros manually. They are documented completely in the user manual that I wrote. I can also furnish a .txt file that can be imported, to save the data entry. If I can’t get the tools to cooperate, that may end up being the solution I go with for the short term.

It was not obvious due to the way the package builder works, and I didn’t notice it in testing because I tested it by bringing the package into the same project that I had used to build it in the first place.

Lesson learned: Build the package in one project. Import the package into a fresh project to test.

Betas gonna beta

When you build an asset package in GameMaker: Studio, you start by taking some project that you’ve been working in, and then going through the Marketplace Package Manager to build a Marketplace Asset using resources from the project. However, the interface that YoYoGames have built is still very beta. It is unstable, resulting in error messages and crashes. But the greater issue is that the design of the interface, and the workflows it supports, is also rather poor and unrefined at the moment.

When you build your Marketplace Asset Package, you are presented with a Package Builder that allows you to select resources from the project and add them to the package. But the resource selection options are not complete. You can’t select Macros. They just aren’t even there.

So how do you add Macros to a Package? By adding them to an Extension, supposedly. There’s an Extension Builder built into the GM:S IDE, as well as this new Marketplace Package builder. I’m presently unclear as to the relationship between Extension builder and Package builder, but the end result of a Package is that you get a package that is ready to be uploaded to the Marketplace as an Asset, and when you download Assets that you’ve purchased from the Marketplace, it installs itself in your Library, where you can add it to a project, where it… becomes an extension.

The Marketplace asset-extension has whatever resources you had added to the Package — sprites, scripts, objects, sound effects, fonts, included files, timelines, shaders, you name it… just no macros.

But if you build an GMEZ extension using the Extension Builder interface, things are very different. I can create an Extension, add a “placeholder” to it, where I can define Macros (one at a time, which is horrible, like each Macro is its own asset in the tree), and I can add a code file, which can be .gml, javascript, a dll, a dy-lib, or java. And I can define Functions which access the code residing in the code file, providing an interface between GM:S and the functions provided by the extension.

And the documentation shows a similar resource picker for handling both importing resources from a completed Extension into the Project, and for moving project resources into an Extension that you’re authoring. But, for some reason when I am in the Extension Builder, it’s one-way only, I can import from the Extension to the project, but not from the project to the extension.

So when I build an Extension, the only things I can put in it are Macros and Functions and Code files. And when I build a Package, the only things I can put into it are project resources other than Macros and Extensions. So I can’t add Macros to an Extension, then add the Extension to the Package. And I can’t add project resources to the Extension Builder. So there’s this impasse that I can’t figure out how to work around.

It could be the documentation is just out of sync with the version of GM:S I’m running, or it could be there’s some serious design bugs in GM:S currently, or it could be I completely misunderstand both the documentation and the user interface, and am missing something that will become apparent to me eventually.

I’m a bit frustrated now, and very tired of banging my head against a wall trying to figure out how to make it work, so I need to step away from it for a short bit.

Simple Performance Test 1.0 released to GameMaker Marketplace

Simple Performance Test is a stub project to enable GameMaker developers to quickly set up and run performance tests comparing two snippets of GML code to see which is the faster.

Ever wanted to know which way of coding your project will run faster?

Want to understand GML better?

Use Simple Performance Test to compare two blocks of GML code, and prove which is faster.

Don’t guess at which code is better optimized, test it and know!

It’s completely free!

Get Simple Performance Test at the GameMaker Marketplace

Project documentation

 

Latest Google Chrome changes break HTML5 applications built with GameMaker: Studio

Users who browse this site with Google Chrome will have noticed that the HTML5 demos and games that I have built in GameMaker no longer work in the latest version of Chrome. I became aware of this fairly recently, but until yesterday I had hoped that it was just a problem with the configuration of my primary computer, as the problem did not seem to be evident on my other computer that I do testing with. Unfortunately, after updating that computer to the latest build of Chrome, I found that the problem is more widespread.

This thread on the GMC forums explains what to do if you’re a programmer who has an HTML5 game that needs to be patched in order to fix it with the latest Chrome. I have yet to try this on my own games, but will be experimenting in the near future. Presumably, YoYoGames will be updating the GameMaker: Studio build for HTML5 to rectify the problem in an upcoming release, and once done, re-building the game will also fix the issue.

YoYoGames launches Marketplace (early access)

YoYoGames has opened its new marketplace to early adopters. Now is the best time to get a product up, as there’s not much competition right now.

It seems the going price for most things is $.99-1.99. Some things are free, and larger products cost more. It seems that the marketplace is currently geared toward selling singular assets a la carte, rather than larger bundles and collections. I’d like to see the sellers create bundles for certain types of assets, rather than try to nickel and dime their way to maximized revenue. I’m also curious to see if the marketplace will allow sellers to use a “choose your price” model a la the Humble Store.

All sorts of assets are available, from graphics, sounds, and fonts, to shaders, scripts, and extensions. Not every category offers something yet, but I expect this to blow up quickly as developers rush to market.

I have some mixed feelings about this, but overall it’s a positive development. On the positive side, it enables GameMaker developers to see their work to each other, which should encourage the aspiring professional by providing a way to make money and an incentive to produce. On the negative side, I’m not sure that the community needs such an incentive — there’s a huge amount of freely available stuff that has been openly shared in the GameMaker Community. Creating a marketplace will tend to introduce greed and cause developers to guard their secrets, or at least want to be compensated for sharing them. In the long run, this could prove more detrimental than beneficial.

Could a build farm be coming to GameMaker Studio?

Interesting.

Earlier today, I posted an idea I had to the GameMaker Community Forums Suggestions board: for YoYo Games to provide a Build Farm service to GameMaker: Studio users who would like to build their games for platforms that they do not own.

Currently, while GameMaker: Studio enables users to build to multiple platforms, certain of those platforms have fairly steep requirements in terms of a physical device to connect to in order to build, and even membership in developer programs. Maintaining all these devices and memberships is prohibitively expensive for anyone who isn’t making a living by doing it.

Providing a Software as a Service model for building to remote cloud-hosted virtual devices that are configured and maintained by YYG themselves would greatly simplify the effort required to build to non-Win32 platforms, making it far easier for GameMaker Studio users to reach all of the platforms that GM:S allows them to reach. Suddenly, it becomes feasible for a solo developer studio to release a game on all platforms without having to own a Mac, an iPad, an Android device, etc.

Further, I suggested that once the build farm was up and running, the next logical step would be to allow developers to submit their newly-built games to various App Stores for whatever target they have built to, enabling GM:S users to bring their games to market far more easily. YoYo Games could have their own store, and GM:S users who have accounts with other app stores could connect their accounts to their YYG Store account, which would enable them to submit their games to the other stores very easily.

Shortly after posting my idea, YYG CTO Russell Kay commented “Squirrel!” — which, apparently, means that I’ve suggested something that YYG has plans to do.

I’m not sure how much of the above ideas they are working on, or how closely what they are working on will resemble what I’ve outlined above, but it’s extremely exciting to think that this may be coming at some point in the indefinite future.

Anything that makes it easier and cheaper for a game developer to bring their products to market — without having to handle all the other aspects of running a business — makes it possible for small studios to compete and do business and make money without having to grow and support a full staff in order to handle these functions internally.

GameMaker Studio Standard now Free

Today YoYoGames announced that they are discontinuing the much-derided free edition of GameMaker Studio, GM:S Lite. In its place, GameMaker Studio Standard is now free. Previously, Standard was $49, but often discounted to free for special promotions. The Lite edition was not favored by users for being too limited in features and resource constraints.

This is a good move for YYG, as it serves to strengthen their position among neophyte developers who want a first tool they can use for free. GameMaker has long been a “gateway drug” for many indie game developers and programmers, and making a free version that is actually useful will continue to ensure that new users will have little reason not to give it a try.

Their official announcement is copied below:

YoYo Games Ltd.

Today, YoYo Games announces that a powerful version of GameMaker: Studio is now available to developers for FREE. We’ve taken the resource-limited “Free” version of GameMaker: Studio and replaced it with a feature-rich version of GameMaker: Studio called “Standard.” The newly launched GameMaker: Studio Standard puts the full power of GameMaker: Studio at the fingertips of games developers everywhere!

If the cost of GameMaker: Studio was holding you back before, there isn’t anything holding you back now.

For more info, visit https://www.yoyogames.com/studio.

Game on!

Interview: Daniel Linssen

Daniel Linssen is an indie game developer who lives in Sydney, Australia, who I came to know after playing his first Ludum Dare creation, Javel-ein, for LD28. After releasing the full version of Javel-ein, he was cool enough to reach out to me to let me know of its existence, since I had so enjoyed the version he had made for LD28, and since then we’ve corresponded regularly and become digital pen pals. He is also the creator of Busy Busy Beaver (which won Bacon Jam 07) and FFFFFF for Flappy Jam. His most recent game, The Sun and Moon, recently won first place in the Overall category for Ludum Dare 29.

CS: Thank you for agreeing to do this interview. Ready to begin?

DL: As ready as ever!

CS: First, do you prefer to be called Managore or Daniel? What does the name Managore mean?

DL: Daniel. In the past I liked having a unique identity while still being anonymous, but I’ve given up on that.

Fun fact: For a long time “Managore” was absolutely unique. Then a year or two ago a Bulgarian company released an online game called Managore and my uniqueness was lost. Oh well!

The name doesn’t really mean anything. Years ago I started writing a (really terrible) sci-fi novel and one of the characters, some sort of biological experiment, was named Managore. And the name stuck.

CS: How did you get started making games? How long have you been doing it?

DL: The earliest example I can think of is as a kid I designed some Sonic The Hedgehog levels on paper. I think I was around 8 at the time.

CS: That’s something I used to do as well, designing games on paper. I think I did my first game concept when I was six or seven…

DL: I’m pretty sure the levels I designed would have been terrible. I hope yours were better!

CS: Nah, the stuff I drew up wasn’t that sophisticated. I’d do a drawing of a screen shot, and then narrate the rules and the player’s goals, point values, etc. and my mom would write them down for me. I didn’t do anything so sophisticated as a full-blown design doc or anything. It was just about the enthusiasm and instinct to be creative, and wanting to do it for real someday.

DL: There’s an old DOS game called Jetpack and I spent a long time using its level editor. The idea of a level editor was pretty novel for me at the time. Over the years since then I’ve played around with RPGmaker, C++, Valve’s Hammer Editor and Flash but never made anything that I could really call finished.

CS: What game projects did you work on previous to your first LD game?

DL: Well a whole bunch of unfinished or unreleased games, unsurprisingly. Actually the only games I’ve released so far have come from game jams. My first experience participating in a game jam was three years ago, I was working with a friend of mine. The game we made was a one screen rhythm platformer for Reddit Game Jam 05 (the theme was “love”) called Give In. I worked on the player controls (which are way too slippery) and the graphics (which I still kind of like the look of).

After that I started using GameMaker and worked on some exploratory platformers which will probably never see the light of day. Then, half a year ago I took part in the Bacon Game Jam 06 (the theme was “rainbows”) and made an action platformer called Violet, which I think of as my first “proper” game, if you can call it that.

CS: How do you approach a 48 hour event like LD? How is it different from when you are working on a game without external time constraints?

DL: I try to start off well rested but that’s about it. Sometimes I have an idea of what aspects of the development process I want to focus on or improve on. Once I have an idea and I start coding, autopilot tends to kick in.

CS: OK let’s talk about The Sun and Moon. I’ve just read your post-mortem article on the making of it, so hopefully we won’t rehash too much of that. I encourage readers to check it out for themselves.

First, let me just say congratulations on another fantastic game. For the record, out of 1493 entries for the LD29 Compo, you placed 1st Overall, 1st in Theme, 2nd in Fun, and 3rd in Innovation. This was just your second LD entry! Obviously, no one expects to win a category, but how well did you think The Sun and Moon would do when you finished it?

DL: Well I went into it hoping to make a game which I could be as proud of as my previous LD game, Javel-ein, and I think I achieved that. When I finished, I was really happy with how things had gone. Everything (well, except the music, but I was too tired to realize that at the time) had pretty much falling into place and the game’s mechanic ended up being a lot of fun. I was lucky not to run into any major hurdles along the way.

My hope was to get a medal in some category but I knew there were so many utterly fantastic games to compete with, so it was always something I was hoping for but never really expecting.

CS: How does it feel to have won the Compo?

DL: It feels amazing. I couldn’t believe it. It’s a dream come true.

CS: What does the title, The Sun and Moon, mean?

DL: Good question. I have all these good answers for why I chose “Violet” and “FFFFFF” and “Busy Busy Beaver”, but I don’t really have a good answer for The Sun and Moon. I was really struggling to come up with a unique and meaningful name. I had all these ideas written down. They’re pretty bizarre so they might be entertaining to read:

A World Divided, The World Beneath, It Spoke Quietly And No One Heard, A Hollow World, The Sun and Stars Both, The Sun and The Moon.

If you’re curious about ISQANOH… I honestly have no idea. I liked the sound of it.

Anyway, because it is such an abstract game, at least as far as my games go, I wanted the name to be up to the player’s interpretation, but I did have a reason for choosing “The Sun And Moon”. As I was developing the game I realized I needed to make the player change appearance while underground, and from that point onwards the player kept reminding me of the Yin and Yang concept. The dark version which falls and the light version which rises. The air and the ground. Complimentary forces. And one representation of the Yin and Yang is the Sun and Moon, so I went with that.

CS: Yeah… what was interesting to me about the title was, there wasn’t really any literal sun or moon in the game! I wondered about that, and was interested to hear what the story was, if there’d been some plan to get them into the game but you ran out of time, or… if, like the Sun and Moon were just metaphorical somehow..

DL: I worried that people might find the name a little too… artsy? But as far as I know that hasn’t been the case.

CS: I think it’s a fine title!

CS: The core mechanic of The Sun and Moon is to traverse a series of obstacles by selectively passing through solid platforms. How did you come up with the idea? How long did it take you to refine the specific mechanics (requiring a jump/fall to pass through the floor, buoyancy within a solid platform, the acceleration/momentum upon ejecting out of a solid platform, etc.)

DL: It just sort of came to me, after a long string of bad ideas. I was thinking about a bubble in a world made of water and air, and the idea evolved from there. I had a pretty vivid image in my head early on of diving into the floor and shooting up into the air and from that point I felt like I had come up with something fun. I stuck with that mental image and built the mechanic around it.

Originally you didn’t have to jump to pass through the floor. I planned to make the player “wobble” up and down if you were standing on the surface and held down the action key. The way I happened to code it meant that when you held down the action key, since your vertical speed was zero, the “wobble” wasn’t there. This worked well enough so I just left it that way.

CS: At what point did you realize you were on the right track?

DL: When I started making the levels. I posted a gif of one of the first levels I made and the responses were really encouraging. The more levels I made, the more content I was with how my game was going.

CS: How long did it take you to build the basic engine?

DL: Surprisingly not long at all. I mentioned it in the post mortem but I made a movement and collision engine called the Beaver Engine which I used as my starting point. The Beaver Engine is a stripped down version of Busy Busy Beaver, one of my previous game jam games, which took about 12 hours to write the code for.

It took a little rewriting to add in the underground physics and make it all work properly but overall the basic engine was pretty painless.

CS: What design decisions were hardest to make?

DL: We’ve already talked about it, but the name! I was actually starting to panic a little towards the end because I couldn’t come up with a name! Oh, also the player’s trail. I went through five or six iterations before I found something I was happy with.

CS: What features/ideas did you drop from the game?

DL: I’ve started to get a pretty good idea of how much I can realistically get done in a game jam, so I kept my feature list pretty minimal. I actually had time near the end to add in a few features such as the level select screen, which I wasn’t originally planning on including.

Speaking of features I wasn’t originally planning on including, I should definitely mention how much of an absolutely huge help it was having you give the game a go a few hours before the deadline. I remember you saying you wish there was a way to know which level you were on, which led to the level number appearing at the beginning of each level, and you said it would be useful to know which level had been played last, which led to the player sitting on top of the last played level in the level select screen. These were really important features that I wouldn’t have thought of at the time.

CS: Absolutely! It was an honor to have been asked, and to be able to provide a little feedback so you could refine the finishing touches on the game that ended up taking 1st Overall. I remembered thinking right away that it was a very strong entry, and I liked it from the first couple levels. I had the idea about the level numbers because when I was giving you feedback, I didn’t have an easy way to reference which level I was talking about. So it was a fairly obvious suggestion.

DL: Fairly obvious to anyone but me! I guess it just really helps to have a fresh perspective with an eye for what’s important.

CS: True; when you’re in the final hours before deadline, your focus tends to be on the most critical elements of the game, and finding bugs. Being able to look at the game with a fresh perspective just isn’t possible, so it’s valuable to be able to get feedback from someone who hasn’t been staring at it for the last 40+ hours!

How would you compare The Sun and Moon to your other games, Javel-ein and Busy Busy Beaver?

DL: Well I knew while making BBB that it just wasn’t going to be that innovative, so I focused on making it fun and silly and pretty. For The Sun and Moon I went the opposite direction and focused on making it unique and innovative, at the expense of a story, detailed graphics and humor.

And then Javel-ein is sort of a blend of the two.

CS: This game focuses on mechanics rather than story, and, I think, stands up well on those merits. Have you thought about adding story elements to the game, or do you plan to leave it abstract?

DL: I’ve thought about it, but I honestly don’t know what direction I could take it.

CS: Your sense of level design and mechanics for 2D platformers is, if I may say so, pro quality. Can you describe your process for designing levels?

DL: In general, if I have a game mechanic to work around, I try to explore that mechanic in as much depth as possible. For The Sun And Moon, I looked at all the different types of movement that the mechanic allowed for (e.g. diving down into the floor, jumping up and through a block, falling off a tall platform and diving deep into the ground below, jumping through a thin wall, jumping into and up through a block) and came up with levels that made the player use these tricks. I wrote all my ideas down on paper first since I’d often have multiple levels ideas come to me at once.

CS: Do you have interest in making other types of games than 2D side scrolling platformers?

DL: Definitely! I think it’s just been the case that the ideas I’ve had that have worked the best have always been tough platformers. On the backlog I have a color-based puzzle game I’ve been working on as well as an idea for a top-down naval exploration game.

CS: The art style of The Sun and Moon would be best described as a minimal, GameBoy style. But it works very well, especially the “clouds” in the background. How did you come up with the idea for them?

DL: For the clouds? Early on the background was a solid color, and I realized that if you flung yourself really high into the air it was impossible to tell how fast you were going. To fix this I decided to add a parallax background in. My game, with its monochrome palette and dark-foreground-on-light-background style, already looked far too similar to Luftrausers, so I wanted something abstract and different.

When I was coming up with the idea for my naval exploration game I experimented with perlin noise and other techniques to generate a huge ocean with lots of islands and interesting coastline, so perlin noise was still fresh in my mind. Because Photoshop’s “Render Clouds” filter creates tileable perlin noise I knew I could use that to quickly make a suitable background.

CS: Interesting that it was a feature driven as much by gameplay needs (having a reference so the player could gauge their speed) as much as cosmetic needs. Visually it’s a very pleasing effect!

How much have you added to the game post-compo?

DL: I’m up to 67 levels at the moment, though I lot of the newer ones still need some work. I’ve added controller support and made the game run on mobile devices. I’ve added a timer for each level that records your best time. I have a lot of ideas for mechanics that could add variety to the gameplay and I’m currently playing around with these to see which ones work the best.

CS: Wow, sounds like you’ve been busy! What are your plans for developing the game further?

DL: Even more levels! However many I can come up with while making sure each level is still unique and fun. I’ll work on the visuals a little bit but I want to keep it looking minimalistic.

More importantly, the music is going to be completely redone.

CS: How about some technical questions?

DL: Sounds good!

CS: You use GameMaker: Studio for your games. Do you work with any other programming tools or environments? What do you like about GM:S? What do you wish was better?

DL: Not at the moment. I think what I like the most about GM:S is that I’m so familiar with it. And that it’s very easy to prototype new ideas. There are, unfortunately, a lot of things I wish GM:S did better. The built-in level editor leaves a lot to be desired, the program occasionally crashes and I lose progress, Windows builds and html5 builds can be wildly inconsistent, and a lot of other, smaller issues.

CS: How did you get into GameMaker?

DL: Two of my favourite games, An Untitled Story and Spelunky, were made in GameMaker. They inspired me to begin making games seriously so I guess I thought it was a good idea to use what they used.

CS: Are you active on the GMC forums? Are there any other good sites for game development that you frequent?

DL: Not at all. I browse /r/gamedev and /r/indiegaming on reddit, but that’s about it.

CS: You mentioned in your post-mortem that you experimented with a couple of different motion trail techniques, before settling on a line drawn out behind the player. How did you make the line taper?

DL: Okay so each frame an object is created. This object stores the players current location (x,y) and the player’s previous frame location (x_p,y_p). The object draws a line from (x,y) to (x_p,y_p) of a certain thickness, starting at 5 pixels and decreasing by half a pixel each frame. So, at any one time, the trail is made up of 10 objects, each drawing a line of varying thickness.

If the player is underground it’s a little different. It still creates objects which store the player’s current location but these objects draw a circle instead of a line, and instead of the circles shrinking their visibility is decreased each frame.

CS: Thanks to gravity acceleration, you can achieve some pretty high vertical speeds. Was it a problem to handle collisions at such speeds? Did you have to do anything special to make it work?

DL: Good question! Because every object in the game (except the collectables, come to think of it) is 16 by 16 pixels, I only needed to make sure that the player never moves more than 16 pixels each frame, so I set the terminal velocity to 14 pixels a frame, just to be safe. I think the terminal velocity is pretty hard to notice in general.

CS: Is there anything else you’d like to say?

DL: Only that participating in Ludum Dare has consistently been a fantastic experience.

CS: I have to agree. Not just making games and having other people play them, or even getting to play a lot of cool games made by other people, but getting to know a few of the people in the indie scene, both through their work and through actual correspondence. Perhaps that’s been the most rewarding part of it all. Congratulations on your accomplishments, good luck in the future, and thanks for taking the time.

DL: It was my pleasure, thank you for interviewing me!

 

GameMaker Game Programming with GML book published

Newly published today by Packt Press, GameMaker Game Programming with GML, written by Matthew DeLucas.

I contributed technical review to the manuscript, as an unpaid volunteer. Purchasing through the amazon affiliate link below is the only compensation I will receive for the work I put into the book.

Alamogordo: Post-mortem

I almost didn’t submit a game this time around. For some reason, I couldn’t get my creativity going. I thought that Beneath the Surface was such an excellent theme, too, with great potential. When they announced it, I started trying to think of a game that would happen underground, or under water. But all I could think of was the setting, not what you’d do there. My brain was being an enemy to me.

So I stayed up until about 6 AM Saturday morning, and still hadn’t thought of any good ideas. My best idea of the night came to me when the Neil Young song, “The Needle and the Damage Done” popped into my head, and I briefly considered making a game about heroin use and damaging the skin beneath the surface. If I wanted to do that right, I needed to make a chiptune cover of the song, and I still can’t do music properly. One day…

So, I put that idea aside, and then nothing else came to me. I slept in until around 11:30, and spent most of the afternoon sitting around, waiting for inspiration to hit me, but nothing happened.

I dicked around on the internet, reading stuff, and started reading all these articles about the New Mexico landfill dig, where they were trying to determine if the legends of massive amounts of unsold Atari merchandise being buried in the desert were really true.

Turns out, they were true!

I found the story fascinating, because why would people still care  that much that they’d dig around in a land fill trying to find that stuff. It’s not as though E.T. was a rare and valuable game. To me, the story wasn’t fascinating, it was people’s fascination with the story that was fascinating. It seemed to be getting a lot of coverage in the media.

I still didn’t have any ideas for what would be a good game, and by around 5 or 6, I had given up and resigned myself to not producing anything this time around, and felt pretty down about my failure to come up with any good ideas. I had a relaxing Saturday evening, went to bed, had a pretty normal Sunday, and then, around 7pm it occurred to me that the land fill dig was happening beneath the surface of New Mexico. Beneath the surface…

Beneath the surface…

Beneath the surface…

Beneath the surface…

neath the surface…

the surface…

surface…

urface…

face…

And I got this visual in my head of the pits in the E.T. video game, and connected that to the landfill, and immediately realized that there was a potential game in there.

Digging in the Alamogordo, New Mexico landfill, in a pit from the E.T. video game, searching for the secret stash of E.T. videogames. I knew exactly what I wanted it to be, not really a challenging game, just an idle time waster that paid homage to the legend and the events of the weekend. I had less than 2 hours before Compo deadline, and knew I’d never make it, but this would need to be a Jam entry anyway, as I wanted to use graphics and audio sampled from the E.T. video game.

Unfortunately I was already on my way to spend the evening with friends, and I didn’t get home until close to 11pm. By 11:30, I had just gotten started, and I worked through the night until 6:30am, and which I had most of the level laid out and working. Movement and collisions were very buggy, but the game was basically playable by this point.

I took a power nap, worked Monday, and then cranked out bugfixes until I got everything working right. All told, the game took about 10 hours to build. My fastest development time ever. Howard Scott Warshaw took 5 weeks to make E.T., his fastest development time ever.

I used that time rather well, struggling only a little bit with the bug fixes, and all I really needed to fix those bugs was to step away from the project and return to it fresh — once I did that, it was fairly easy to redesign the code that handled movement and fix the problems I’d been having in the wee hours of the morning earlier in the day. Throughout the project there was very little re-work, almost nothing thrown away, and everything that I built was done in such a way that it doesn’t feel like a mess. The project code is actually pretty decent. Almost every LD48 that I’ve done so far, I’ve struggled with some stupid error in a feature that should be very basic and easy to do, and ends up sucking a lot of my time away from the project, but this time, I worked effectively from start to end. Only, I had just about 10 hours of work put into the project over the entire weekend.

The game itself, well there’s nothing much to it, but it does feel somewhat like one of those terrible shovelware titles that caused the Great Crash of ’83.

So, there it is, an homage to terrible games. Since that’s what it is, it somewhat excuses it from itself being a fairly terrible game. At least the programming is fairly decent, …beneath the surface.

Well, play it and see what you think.

Alamogordo

Ludum Dare 29

I didn’t complete an entry for Ludum Dare 29, and am a bit disappointed in myself. Although the theme “Beneath the surface” is an excellent theme suitable to all kinds of ideas, I struggled to come up with a concept that fit well with the theme. I thought about under ground, under water, and digging a bit, and I thought about skin, and metaphorical ideas, but these didn’t inspire a core play mechanic or goal, so I never really got to a playable game concept.

I need to figure out how to get myself into a creative mind on demand.

Update

Around 7pm, inspiration struck. I made a game after all. I made it in only about 6 hours, so it is not a very good game, but the idea was a fitting one, and I knew that I would be able to build it in under a day.

Alamogordo, my entry for the LD29 Jam, is based on the legend of the buried E.T. cartridges in Alamogordo, New Mexico, that were dug up over the weekend.