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.
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.
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.
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.
Here’s a quick tip for performance throttling in GameMaker.
Say you’ve got some code that you need to execute frequently, but if the game starts slowing down too much, you can live without executing this block of code.
Like, for example, say you want to spawn a new instance of some object very frequently, such as in the Step event, but if performance starts to lag you can skip it. You could try to test out how many instances the game can handle without frame rate dropping to an unacceptable level, and cap the number to something somewhat below the maximum. The problem is that this number will vary depending on the hardware. Someone running your game on an older, slower machine will not be able to sustain the same performance that someone with a brand new, high end machine. There really isn’t a true, one-size-fits-all number that works for every situation.
What you really want to do is base the cap on the current performance of the game as it’s running right now. To do that, wrap it up in an if statement like this:
if room_speed < fps
{
//keep doing the thing that will eventually cause performance issues
}
The way this code works, as soon as fps drops below room_speed, it will stop doing the thing that contributes to the performance problem. This technique does not guarantee that fps will never drop below room_speed, but it will cause performance to stop degrading by not contributing to the problem once performance has degraded to the point that the conditional check takes the “false” branch.
If you don’t want ANY noticeable performance degradation, you may want to make the conditional check be something more like
if (room_speed + 10) < fps
instead; this will give you a little buffer to keep the fps enough above room_speed that you should not see any noticeable performance problems. Or, substitute the calculation room_speed + n with the literal value that you don’t want fps to drop below. Use this to ensure a safer margin of acceptable GameMaker performance.
Today’s YoYoGames tech blog deals with GML variable scope rules. I was dismayed to read that they are changing the scoping rules, which will result in old code breaking.
I’m normally very supportive of the decisions YYG has made with the development of GameMaker, particularly in the GM:S era, but this is probably the single worst thing that I’ve read about the development of GameMaker since I started using it in 2010.
I have a lot to say about this. First, I’d like to address the specific changes. Then I’ll talk a bit on the philosophy of how I would like YYG to treat me as a developer who relies on their tools.
I even liked the theme this time: You Only Get One. I came up with an idea pretty quickly: a platformer in which you are given the choice of several power-ups, but you only get to have one. Once you made your choice, you have to get through the level using that ability.
Alas, I did not get very far and did not complete the game. I started out trying to build a platforming engine from scratch, ran into bugs, and a few hours later concluded that without declaring a pre-existing base code for a working, tested platform engine, I just wasn’t going to have any hope of completing a game in 48 hrs.
I really needed to do this in order to free me up to do things like come up with the various power up items, and devise level designs that would be solvable with each of them, just in some different, uniquely challenging way. That’s a rather tall order, really — level design in platformers takes a lot of talent and testing.
Once I realized that I wasn’t going to be able to finish that project idea, I could have scrapped it and started something else, but I opted not to — mainly because I was very frustrated by that point by a couple of technical problems.
This culminates a year of mostly failed projects for me: I was sick the weekend of Global Game Jam 2013 and didn’t partake, then the wheels fell off my computer just in time for our local Cleveland Game Developers Summer Jam event, when a dying hard drive put me out of commission for the weekend as I struggled (mightily, and successfully) to move my OS to a SSD. I blew off LD26 because I hated the theme “Minimalism”, and then skipped LD27 entirely because I hated the theme “10 Seconds”.
Of course on the plus side, I helped put out a book on GameMaker, and am currently working on another, but in terms of releasing finished products, this has been a bust year. Nothing to do about it but pick myself up and get back into it, though.
Since I went and registered this domain name in 2010, I’ve been hosting on a server that a friend of mine generously provided me some space on for free. At first I had no idea what I was going to do with my domain, at all — I just wanted a web server of my own to play with in my spare time, and learn from. I dabbled briefly with trying to build a native HTML website before realizing how not-fun that really is, and switched to using WordPress, and have been blogging with it ever since.
This year, the server started having issues with downtime. I’ve been in contact with the server administrator, who at various points has explained that the outages have been caused by all sorts of things: database server disk storage full, upgrades, DDoS attacks, aging hardware, you name it. It seems the problems have gotten worse over time rather than better, and so a few weeks ago I began shopping around for a new hosting service. I’ve got one now, and am in the process of migrating the site over to the new server. I’m hopeful that I’ll be through doing that sometime this week, and then I can cut over the DNS registration to point to the new server, and all will be well again. This weekend there was another bad outage, and the site was down for about 24 hours. Dealing with that had me distracted, anxious, and frustrated, and not at all in the right frame of mind to be focused on my LD48 project.
Despite the ease of setting up WordPress initially, I’ve found it fairly difficult to migrate the site over to the new host, mainly due to differences between the hosts, but also due to my relative lack of experience in doing this sort of thing. So I’d like to say I’m learning a lot from this, but really at the moment I’m just learning that it sucks to do something when you don’t really know how, and the documentation and tools that you have available to you are not all pertinent to what you want to do, and it’s up to you to figure it out. I’m muddling through, and perhaps by the time I’m done I’ll understand how stuff works a lot more than I did before I started, but I haven’t seen that payoff just yet. I haven’t yet resorted to the tech support at the new host, but I plan to this week when I can get to it. Getting the current host to be up at the same time when I have a large block of time to throw at migrating seems to be an issue, and I don’t want to waste my time talking to tech support when the old host is down and something that I may need to pull off of there isn’t accessible.
So that sucks.
On top of that, I also had a bit of frustration with GameMaker Studio this weekend while I was still trying to work on my LD48 project.
Any #Ld48 #gamemaker studio users having this autosuggest problem in 1.2.1224? pic.twitter.com/Qiel418srG
— Chris Sanyk (@csanyk) December 14, 2013
Somehow or other, the auto-suggest feature in the GML code editor went glitch on me, drawing a super-tall suggestions box that drew off the top of the screen, and wouldn’t allow me to scroll up to see any of the suggestions.
Tl;dr: it turns out that the autosuggest box is resizable by dragging the edge with the mouse, making this quite easy to fix. However, I did not know that at the time, as there’s no UI widget that hints at this functionality, and I expected that it was like a regular “Tool Tip” widget in Windows, which are not normally resizable. I tried exiting/relaunching, and even removing/reinstalling GM:S to no avail, before resorting to tweeting my SOS. I also submitted a bug report with YYG.
Within an hour or so of my SOS tweet, xot of GMLscripts.com had offered me some suggestions which fixed my problem. I really appreciated him taking the time to do it. I don’t know who xot is in real life — if he’s connected in any way to YYG, a former employee, or just a long time GameMaker developer, but I’ve gotten a lot of use out of gmlscripts.com over the last couple years, and so I donated $25 to him for providing such a valuable resource to the community, and since then he’s been quite friendly and generous with his time — he also contributed quite a bit to the draw_text_rtf() script that I posted about earlier this year. So, three cheers for xot, wherever you are — you’re a great guy.
This morning, I woke up to find an email from YYG Support in my inbox:
Hi there,
Reading through the twitter feed you linked it looks like you managed to solve the issue.
Is this correct?Thanks
Peter
YoYo Games Customer Support Technician
Since the bug report tool doesn’t let you upload files, I had pasted the url of the twit pic, and Peter had apparently followed up, reading the conversation, and, seeing that I’d apparently sorted things out on my own, checked in with me to make sure I was doing OK. Awesome!
I wrote back to him:
I don’t know what caused it to happen in the first place, though, so you still may want to investigate that end of it, in order to prevent a recurrence of the issue. It seems to me that while it makes sense for the height of the auto-complete suggestion box to size itself dynamically, it ought to have some “sanity checks” to make sure it’s not sizing itself larger than the display resolution, and more specifically to size itself to no larger than needed to display the suggestions.
To which, he replied:
I’ll let our coding team know about this issue so they can add some checks to prevent this sort of thing happening again.
I’m extremely pleased with this exchange.
A year or so ago, back when YYG’s Mantis bugtracker was still open to anyone to submit bugs, it often took a long time for anyone to respond to a bug report, and often that response was unsatisfying — you felt like you’d annoyed someone with a concern or question that they felt was stupid, or that you were guilty of misusing the bug reporting system to ask for help merely using the tool rather than reporting a genuine bug, bug reports would often be closed prematurely, before allowing you to engage their developers who were working on it to communicate about the issue, and if the issue did merit a fix, it could be months before someone got around to it, because there’s a zillion bugs and they have to be properly prioritized, planned, and implemented.
By contrast, this experience left me feeling that they cared about my problem, not just the bug report, that they were interested in taking care of it the right way, and that it was their pleasure to do so. Submitting issues is also simplified compared to what it used to be in the Mantis system, which is also appreciated.
I really, really can’t say enough good things about how it feels to be using GameMaker these days.
Yeah, I know. Last article, I said in this article we’d cover parsing and validation and converting the password into gamestate data. We’ll get there eventually. But I want to take a detour and show you how to build an on-screen keyboard.
In the first article in this series, I handled the user input simply, by using the get_string_async() function. This is good enough to be functional, but has two main problems:
First, because we’re allowing input directly from the keyboard, the player can enter any characters at all, which means that we’d need to handle characters that are not part of our password’s alphabet. This means extra programming. Not necessarily a bad thing, if that’s what’s right for the user, but it is more work to write up validation scripts that properly handle our Base64 password alphabet.
Second, the user experience of typing a password into a textbox is fine, as far as it goes, but it isn’t at all like an authentic old school keyboard system. This is a somewhat debatable point — old school consoles used on-screen keyboards not because they were better than keyboard entry, but because there was no keyboard. Entering passwords this way is slower and more tedious. But, if we are going to re-create the experience authentically, we need to heed the conventions of the time.
Every onscreen keyboard in the old days was a custom implementation. No two were exactly the same, although there were a lot of commonalities, and most of the differences were cosmetic. The most common implementation was a grid of characters, which the player selected one at a time using the D-pad, pressing a button to enter the character, and another button to go back. When the entire password was entered, typically the player submitted it by pressing the Start button, or sometimes there was an on-screen button that the player would select with the D-pad. We’ll build something like that in this tutorial, although we’ll use the keyboard rather than a gamepad control. Implementing the gamepad controller input capability isn’t too difficult, though, so I’ll probably come back and add that eventually.
One of the problems people have with writing down (and later reading) passwords is that certain characters look very similar (such as 0, o O, l, l, 5, S, 9, g, etc.) You can’t help the player’s handwriting, but at least when the game is displaying the characters on the screen, you should be sure to pick a font that makes these characters unambiguous. These symbols are merely labels which stand for a number value, so it doesn’t really matter what they are.
It’s not a bad idea to omit the similar looking characters, although for this tutorial I’m going to stick with the full alphabet. We’ll at least want a font that has very distinct characters to aid the player in recognizing them correctly. Google for “programmer” or “console” fonts, for suggestions on good ones to use, and pick something out that looks right for the style of game that you’re making. Make sure the capital “I” has serifs and the zero has a slash or dot in it, and so on.
alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!?";
font = fConsole;
var k = 1;
for (var i = 0; i < 8; i++){
for (var j = 0; j < 8; j++){
keyboard[i,j] = string_copy(alphabet,k,1);
k++;
}
}
row_selected = 0;
column_selected = 0;
instructions_text = "Press A to select letter. Press B to erase letter. Press Enter to submit password.";
input_string = "";
max_input_string_length = 4;
draw_set_font(font);
draw_set_halign(fa_left);
draw_set_valign(fa_top);
draw_text(10,10, "PASSWORD: " + input_string);
draw_set_halign(fa_center);
draw_set_valign(fa_middle);
for (var i = 0; i < 8; i++){
for (var j = 0; j < 8; j++){
draw_text(x+(32*i), y+(32*j), keyboard[j,i]);
}
}
draw_rectangle((column_selected * 32) - 16 + x,
(row_selected * 32) - 16 + y,
(column_selected * 32) + 16 + x,
(row_selected * 32) + 16 + y,
true);
(Pick whatever keyboard key you want for this.)
if string_length(input_string) < max_input_string_length {
input_string += string_copy(alphabet, (row_selected*8) + column_selected + 1, 1);
}else{
audio_play_sound(snBadPassword,1,false);
}
(Again pick whatever keyboard key you want for this.)
input_string = string_copy(input_string,1,string_length(input_string)-1);
if validate_password(input_string){
apply_password(input_string);
room_goto(rmGameStart);
} else {
bad_password();
}
row_selected = (row_selected + 7) mod 8;
row_selected = (row_selected + 1) mod 8;
column_selected = (column_selected + 7) mod 8;
column_selected = (column_selected + 1) mod 8;
That's it for the Events, but we need to write three scripts for the Press Enter event. These passwords are where most of the implementation-specific code is going to go.
The details of these scripts will vary from project to project, but this is where we'll handle the validation, parsing, and conversion to gamestate data -- what I thought we'd be covering in this article. We'll cover our example versions of them in the next article.