Newly published today by Packt Press, GameMaker Game Programming with GML
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.
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.
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.
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.
Yesterday, in a landfill in New Mexico, copies of E.T: The Extra-Terrestrial for Atari 2600 were unearthed, apparently confirming rumors of their mass burial in 1983.
I recalled hearing this story at some point, many years ago, but I don’t recall exactly when. It’s been repeated often enough. A number of Atari employees said that it was true, but as I recall the company officially denied it, leading to speculation as to whether it was really true or not. Likely the denials were to avoid admitting that the business was in trouble.
While the find confirms that Atari product was buried in the landfill, it’s still unclear how accurate the rumors really were. Over the years, I heard many things about the burial:
A while ago, I started a series of articles that I never finished, on creating a configuration system for GameMaker games. I posted Part 2 almost 2 years ago, and had intended to follow up in just a couple weeks with Part 3, but it stalled and never came out.
A few readers have asked, so I figure an explanation is owed.
The series I had started on creating a configuration system has been on hold since the second article. As I got into designing the system, I kept running into problems with making my system platform-independent and universal.
I had intended to write a universal configuration management engine for handling things like monitor resolution switching, master volume, music volume, and sound fx volume, and a customizable set of configuration widgets for whatever your game might need (essentially, a set of generic, reusable buttons, sliders, checkboxes, and other UI controls). Ideally, I had hoped to write a set of scripts that would use GML functions to define rooms and objects that would constitute the configuration system. Ultimately, I wanted to create a GML script config_system_create() that would set up the entire system — rooms, objects, and functionality, so that you could simply import a GEX extension, call one function, and have a full-featured system generated at runtime, without having to spend any time designing and implementing all the resources yourself. But in GM:S, YYG obsoleted the functions that allowed me to define objects at runtime, execute strings as GML code, and a number of other functions relating to how Windows handles video and audio.
My goal was to enable a developer to drop in my finished configuration system as a GameMaker extension, and invoke its default implementation with a single function call, and use other function calls in the extension to build custom features, but use most of the features without modification, beyond turning features on or off, and to also have the capability of adding customized settings specific to their game. I wanted to write my system one time, and have it be re-usable so that I could save myself from having to spend a lot of time re-creating the system in each new project.
Most difficult of all, it requires that I design a system that anticipates every need a game developer might possibly have, for any type of game they might dream up. Doing it one time and never having to touch it again would be great, but it’s probably not realistic.
This was an overly-ambitious goal. I’m laughing at myself a bit, now, thinking about it.
Still, there were a lot of achievable ideas that I had for the tutorial, and a demonstration of how to implement them would be a worthwhile exercise.
It won’t be drop-in, single-function system, and it’ll be specific to the Windows build target, but the design should be adaptable to your project with a little work.
I don’t want to make a promise for when I expect to deliver this, but I will complete the series and a reference implementation before I publish the first article.
This weekend, April 10-13, 2014, will be Notacon 11. The last Notacon, apparently.
The first Notacon I attended was Notacon 2. I was less than impressed, as it seemed like the most poorly organized event that I had ever gone to. I didn’t realize it at the time, but this was because the event was not put together by professional event planners, but by a bunch of geeks who were no older than me, who didn’t see any reason why they couldn’t do something they thought would be cool. But in those first years, the execution wasn’t quite at the level of the vision yet.
There were printed schedules for when talks and presentations were to be given, but due to last minute changes no one was where they were supposed to be, when they were supposed to be. I missed talks that I had wanted to see, and saw things that I had no interest in. Speakers’ presentation slides were projected onto bed sheets that were strung up in an improvised manner. If they had a microphone, maybe it worked but as likely as not it was low on batteries or cut in and out throughout the talk. I didn’t know anyone there, and no one seemed to be friendly or inviting. I tried to chat with geeks playing with legos and soldering irons, but no one seemed very interested in getting to know me, or talking about what they were working on.
So that was my first and last Notacon, until Notacon 6. A friend I knew from the interent, named aestetix, who I’d never met IRL declared in a blog post that he needed a ride from the airport so he could deliver his talk, and he offered to get whoever helped him in for free. I’d long admired his thinking and writing, and took him up on the offer. By then, Notacon had matured into a well run conference, with interesting talk topics and personalities. Drew Curtis from Fark.com presented that year, as did Jason Scott of Textfiles.com and the BBS Documentary, Archive Team, and the Internet Archive. And Mitch Altman, of Cornfield Electronics and TV-B-Gone, and a young comic book artist named Ed Piskor, who was working on a 4-part graphic novel on hackers called Wizzywig, and would later go on to create a definitive history of hip hop and rap music, Hip Hop Family Tree. Among the attendees was Emmanuel Goldstein, whom I had read about years ago in connection with the legendary 2600. I was afraid to walk up to him and say hello, but I was impressed that he was there, and amazed that I knew people who knew him.
I went every year after that, and made friends with a lot of people there. Aestetix introduced me to Paul and Jodie Schneider, Notacon’s primary organizers, and I met many others there for the first time who would become friends, acquaintances, and professional contacts. Most significantly, for me, I met a neurohacker I met at Notacon 6 named ne0nra1n, who was very friendly and made me feel welcome as a newcomer to this space, and corresponded with me after that weekend, giving me encouragement to present a talk myself. At the time I didn’t think I had anything that I was good enough at or knowledgeable enough about to make an interesting talk, and the amount of work that I felt I’d need to prepare something even barely adequate frightened me. My first presentation proposal, a talk on intellectual property and copyright reform, wasn’t accepted for Notacon 7. I felt secretly relieved.
But ne0nra1n’s encouragement changed my life. As a result of Notacon, I started this web site, not yet knowing what it would be. I participated in the founding of the Makers’ Alliance hackerspace in Cleveland, and through my involvement there, first encountered the Cleveland Game Devs, and became heavily involved with them in 2010. This helped me to rediscover my enthusiasm for programming and game development, which I’d put aside for many years.
I delivered my first presentation at Notacon 8, “How I (FINALLY) Made My First Videogame”. I put a lot of work into it, which was only possible because I’d just lost my job two weeks before, and that allowed me to pour 14-18 hours/day into working on finishing that first game, and to preparations more directly related to the talk itself.
I worked on the game and the talk I would give about how I had made it, right up until the last minute, and while I knew my topic and what I wanted to say, I hadn’t had time to rehearse, and no real idea if I’d fill the hour slot I had, or go over. But my prepared material fit the hour almost perfectly, and I received many compliments from attendees — this completely exceeded my expectations.
Presenting was a great experience. I was transformed that day. When I went to bed that night, it all hit me at once: I had done it. I had grown up to be the person who I had dreamed of being since I was little: a videogame designer. It was something I’d given up on when I became an adult, and I had tried to forget about for years, but I never had found anything to replace the passion I’d had for that dream, and life felt unfulfilling as a result. But, because of that chance interaction with ne0nra1n at Notacon 6, in two years I had become the person who I had always wanted to be.
Talking about that journey in front of a room full of people, had made it real in a way that it hadn’t been before. I felt, at last, like I had arrived, and I had a place where I belonged.
I’ve known about Construct2 for a few years now, and had downloaded it quite some time ago, intending to compare it with GameMaker in order to see which I liked better. I kept getting deeper and deeper into GameMaker, though, and since I was enjoying that, I wanted to stick with one thing until I knew it very well, rather than dabble in a lot of things that I knew only passingly.
One of my Cleveland Game Developers friends, Jarryd, likes Construct2 and I’ve seen him give a few talks about it, and so I’ve had a general impression of what it’s about for a while now. This weekend, I finally sat down with it and started to give it a serious look.
So far, it feels very different from what I’m used to with GameMaker: Studio and other development environments that I’ve used… but I think there’s a lot of potential for getting stuff up and working faster than with GameMaker.
Two of Construct2’s areas of strength are the built-in project templates and object behaviors. They take a lot of the tedium out of developing your own engine and having to program everything from scratch, which means you’re freed up to focus in design and gameplay more. Creating a new project from a template sets up a lot of “boilerplate” that is common to every game of that type, saving you a ton of work and problem solving. And adding a behavior to an object does in one or two clicks what many programming numerous events and scripts consisting of innumerable lines of code would accomplish in a GameMaker project. And it all works and doesn’t need debugging, although there’ll still be a lot of customization yet to do, and that customization will require plenty of problem solving and debugging. But it still gets you into the juicier parts of game development quicker, and allows you to build on a more featureful foundation than GameMaker does.
On the other hand, what I like about GameMaker is that by leaving these low hanging fruits un-plucked, it gives a newbie programmer some relatively easy things to develop, which affords many learning opportunities. Learning how to attack a problem and break it up into simple, manageable steps that you can solve is an important skill to have in programming, and GM provides such opportunities.
The C2 documentation is very well written, and there are a ton of example projects that come with the IDE, so you can learn by playing around with a project.
It feels different from traditional programming in that there’s no traditional text editor, and not much syntax to learn, for about 90% of it, from what I see so far. If *feeling* like a “real” programmer is important to you, Construct2 may not satisfy, but if you don’t care about coding as much as the ability to quickly make working games, it might be just the trick. I feel like “real” programming is more like designing shapes of pieces to make a jigsaw puzzle, and then assembling the puzzle, and using Construct2 is more like taking a bunch of ready-made jigsaw puzzle pieces out of a bin and putting them together *just so* in order to make a picture that you have in your head. But I don’t consider criticisms that amount to bias toward text editing and syntax as the only true programming to have much legitimacy to them. Surely, if you never understand the circuits of the machine, you’ll never be able to call yourself a Real Programmer, and most modern programming languages abstract the machine entirely. So too, with programming environments that replace linguistic syntax with visual paradigms. Still, learning Construct2 may not be as good a good first step if you’re interested in getting into other types of programming, the vast majority of which do involve coding in a programming language.
One of the first things I did with C2 was to play the Asteroids example project. Labeled as an “Intermediate” project, I quickly noted that while the Player wrapped around at the edges of the screen, the Bullets did not. This bothered me, so without really knowing what I was doing, I looked at the Player’s behaviors, and saw how to modify the Bullets. It took almost no time at all.
But now, the bullets just traveled around the room forever, so in short order I figured out how to add a timer to them so that they would be destroyed after a short time. This took a bit longer, but in maybe 10 minutes I had it figured out. Next, I created a new Sprite (which seems semi-analogous to what GameMaker calls an Object) and added it to the game, defined some behaviors and before too long I had asteroids floating about, that destroyed the ship when they collide with it, are destroyed by bullets, and wrap around the room. I even figured out how to create two smaller asteroids when destroying the large ones.
That’s when I discovered that, if you don’t add an object to the Layout, even if it won’t exist in the initial state of the game, the game won’t run properly. I noticed a previously overlooked bullet sitting in the Layout window, outside the game view, and, thinking I’d somehow accidentally placed it there by mistake, deleted it, only to find that the game no longer worked properly. And then I got an error message about the smaller asteroids not being defined. So then I figured out that in order to have these types of objects available to the game at runtime, they needed to be placed in the Layout, but outside of the visible area, what in GameMaker would be considered “inside the Room”. This confused me, because coming from GameMaker, I expected that objects placed outside of the rooms boundaries are instantiated and run in the game. But in C2, apparently they are just available to the game, to be created when called upon by the program. It’s a bit strange, and I wonder how C2 handles objects that walk “offstage” or need to begin life offstage.
Construct2 is one of the cheapest options out there right now for fledgling developers. Comparing Construct2 to GameMaker, at $119 C2 is cheaper for a license than GameMaker: Studio is, if you want anything more out of GM:S than the base “Professional” package. The free edition of C2 also has fewer limitations than the free edition of GM:S. There’s also a $400 “business” license, which is for professionals and businesses that have made $5000 or more from game development, but doesn’t seem to give the user any additional new features. I suppose the idea there is that businesses that make that much money from game development can afford to subsidize development for the rest of the customer base.
I haven’t benchmarked the two side by side, but I understand that C2 builds everything as an HTML5 app and (if you’re not targeting a web browser) wraps it in a native application for whatever platform it builds to. By contrast, GM:S has the option to build native code, depending on how you build it and what platform you’re targeting, so may potentially have performance advantages over Construct2. I don’t want to speculate, and for now it’s merely a hypothesis that I have not myself tested, but it seems plausible that GM:S would the equivalent game as well or better than C2 on most platforms.
On the other hand, C2 is probably more consistent across platform, since on every platform it is essentially running the same code, unlike GameMaker:Studio, which currently has numerous problems with supporting features and getting to work exactly the same, regardless of build target.
I still haven’t gotten very deep into Construct2, and have just barely begun to grasp what it is capable of, but so far I like it quite a bit. Whether I like it as well as GameMaker: Studio, or less, or better, I can’t say yet, but I like the fact that it exists,and and it provides another option for an easy to use tool for game development. I still am much more versed and comfortable with what I know in GameMaker, but I’m impressed with how quickly I was able to pick up Construct2 and do something useful with it.
Thinking about programming and maintaining a system in a team environment, where the system has a long life and the team supporting it experiences turnover.
When I program I know exactly wtf I mean by . I understand its purpose and design, and this makes me fairly confident that I know what is and what it does or is supposed to do. My ability to solve problems when I code from scratch is limited by my ability to understand the problem and to conceive of a solution. Often what I can come up with is inferior to what the greatest minds can come up with, but for many problems I can come up with something acceptable, and code it in such a way that it is very easy to understand the code, because I like to write code that is written in a way that lends itself to understanding.
When I look at someone else’s , I don’t know wtf they meant when they coded . I have all kinds of questions about what was in the programmer’s mind, how they understood the problem, what they handled in and what they elected not to handle in it, and so on. It helps immensely if I know the language and any frameworks or libraries well, but often when you’re inexperienced that’s not the case. And, especially with larger, older things that have been built up over time, that becomes a very steep learning curve. Until I’ve had enough exposure and experience to , I feel very uncomfortable, uncertain, and unconfident that I understand any part of . And, if is sufficiently large, I never get over this, and it ends up limiting and paralyzing me in my efforts to become a better programmer.
If I built it, then I know why, and I can be in a position to know better later when I’ve learned more and maybe decide to change my mind based on some revelation.
But if someone else coded it, unless they coded it in such a way that the code clearly expresses its intent, and/or they’ve commented it extensively, or documented it somewhere, explaining their rationale in detail, I can only speculate, and depending on whether I feel like I am smarter and more knowledgeable than they are, I might or might not feel comfortable making a change. I would at the very least feel uncomfortable making a change that I could not roll back quickly/easily if something broke, ideally in a test environment where there would not be serious consequences. But I might not feel confident that a change would be instantly and obviously noticeable; often things break in very subtle ways. Having a suite of unit tests is very useful here, but it’s often the case that there are no tests written.
Even when a system has extensive documentation, there’s no guarantee that it is up to date, or accurate, or correct. Other people often have very different ideas about what and how to document, and how much detail to include, and where to put what information. All systems of documentation seem to involve significant tradeoffs, and there is no silver bullet solution to documenting adequately.
I call such situations IT Archeology, rather than IT Engineering. It’s very much like discovering a lost culture’s artifacts and trying to figure out how their civilization must have been structured and how daily life must have been lived, and then trying to adopt those ways and live by them yourself in order to understand them better. By contrast, IT Engineering is what you do when you have a solid foundation of understanding of the problem domain that provides the context that it works within, and knowledge of the system and the technology stack that it is built upon.
At the moment, I am wrestling with how one moves from an Archeology paradigm to an Engineering paradigm. But it’s an observation I’ve noted many times in my experience, and it seems quite common. I am interested in advice from developers who have to deal with this sort of thing about what approaches actually work.
TL;DR: A fun, quick puzzle platformer, Busy Busy Beaver isn’t as difficult as Linssen’s previous game, the amazing Javel-ein, and is perhaps just a bit less engaging, but it’s charming sense of humor makes up for it. If you’re up for an hour’s worth of platform puzzles, try it out. Built in just 40 hours of marathon game jamming over a weekend, it’s remarkably polished for a game produced so quickly.
You’re a beaver. You need wood to build up your house. Collect the wood, until you have enough, but make sure you don’t touch spikes or eat so much wood that you have no platforms left to get back home.
Simple, yes? The challenge is mild to moderate until the last few levels, but it’s a relaxing kind of intellectual challenge, where you don’t have to think too much, but just enough to make the game interesting without being frustrating.
I got stuck on the very first level, until I learned this tip: Press Down+Z to eat wood that you’re standing on. (I actually tried this early on, and couldn’t get it to work, which left me confused as to how to beat the first level, until I learned the secret: To eat down, you have to be in the center of a grid block. The level is laid out over an invisible grid, and if you’re standing on a grid line, you won’t be able to eat down, even if you’re standing on a grid line between two blocks of wood. As a player, I would have expected to eat both blocks when straddling a boundary, rather than neither.)
Version control makes sense whether you are working alone or with a team. It should be a mandatory practice. But you won’t be able to enjoy the benefits of version control unless you know how to do it right. If you’re working with a team, it’s essential that you all know how to do it right. This article will help you get started.