Category: development

Making a Configuration System in Game Maker, part 3: Where’s Part 3?

design, development, games, programming
Comments

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.

Product Review: Scirra Construct2

development, games, programming, reviews
Comments

Construct2 is available for download at www.scirra.com.

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.

Initial impressions

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.

Discovering Construct2 through example

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.

Cost

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.

Performance

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.

Final thoughts (for now…)

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.

Verdict: Worth checking out.

Archeology vs. Engineering: contrasting approaches to long-term maintenance of IT Systems

development, programming
Comments

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.

Getting into version control with GameMaker Studio

Best Of, development, GameMaker Tutorials, programming, Tutorials
Comments

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.

(more…)

Simple GameMaker performance throttling

Best Of, GameMaker Tutorials, programming, Tutorials
3 Comments

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.

Prior Art

development, games
Comments

Proof that I invented the idea of it first :-P

prior art

Global Game Jam 2014 postmortem

design, development, games
6 Comments

The Global Game Jam 2014 site doesn’t seem to have a blog capability this year, or if it does I’m stupid and can’t find where I can blog about my progress. So I wrote this entry as the weekend unfolded.

The theme this year was: “We don’t see things as they are, we see things as we are.”

Interesting theme! I like it. A good idea came to mind almost immediately. I thought about a world that changes as the player changes. By picking up items, the player’s attributes change, and as the player’s attributes change, the world’s attributes change as well.

Then the idea came to me to have the player change by looking into mirrors that reflect a distorted view of the player. The more the player looks at the distorted reflection, the more they come to look like the reflection, giving them new powers… but, the world changes to match.

(more…)

Global Game Jam 2014

development
Comments

This weekend is Global Game Jam 2014 weekend. I’ll be participating at the Cleveland Game Developers site.

I’m a bit anxious about this one. 2013 was a pretty poor year for me in terms of weekend jams. I got sick for GGJ2013, had computer problems that knocked me out of CGD Summer Jam, and out of the 3 Ludum Dare compos that I tried to participate in, I only managed to complete a game for one of them. Adding to my anxiety is the fact that I have no plans apart from showing up. I’m hoping that I will find a team to work with, but whether that happens or end up going solo, I think my approach will be to focus on something small and simple, rather than go for something experimental.

I’m hoping to turn things around for 2014, so I really want to make a decent game for GGJ this time. I hope that the theme inspires me and that I don’t struggle too much with it. I’ll be spending the rest of this week doing coding exercises to get my mind ready.

New GML variable scope rules will break old code

development, programming, reviews
9 Comments

[Update: Please read the comments from YoYoGames CTO Russell Kay, at the bottom of this article. As it turns out, the implications of the changes that I expressed concerns about in this article were overblown. The YoYoGames tech blog article that caused my concerns wasn’t clear enough in describing them, resulting in my misunderstanding of the severity of the changes.]

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.

(more…)

Looking forward to GameMaker Studio 1.3

development
Comments

There’s been a lot of news coming out of YoYoGames lately about the upcoming release of GameMaker Studio 1.3. They’re delivering a lot of new features that have me excited.

From the official roadmap:

Version 1.3

Debugger

Rewrite of the GameMaker debugger to include full source level debugging, break points and watch windows. Will also target cross platform support, allowing remote debugging of Mac, Android and iOS devices.

I really like that they’re delivering an improved debugger with breakpoints and watched variables. This is something that is frankly long overdue, the functionality that was provided in the current debugger would be considered barely adequate compared to what’s been offered in other IDEs for at least the last 10-15 years.

On the other hand, I credit the lack of a decent debugger in GameMaker for making me a better programmer by teaching me not to over-rely on a step-through debugger to understand my code.

Because I lacked a proper debugger, I learned to build myself a logging system. Because I lacked watch variables, I learned to draw the values of variables I wanted to read to the screen, next to the instance.

It turns out, when you have a game with a lot of objects, all of which are updated in a loop that runs at 30 iterations per second, stepping through your code to see what’s going on must be extremely slow and tedious. I am not sure how much use I’ll get out of a debugger — I’m sure there’s times where it’ll still come in handy for me, but for me, logging and drawing variable state to the screen so I can continue to run the game at realtime and see what’s going on faster will likely be more valuable to me.

One highly valuable programmer’s tool that I’d love to see added to GameMaker Studio in the future is unit testing. Programming benefits from unit testing by proving that existing functionality still works as intended when new code is added or existing code is modified. It can accelerate development by reducing the time it takes to find bugs, immediately identify when they are introduced, understand the scope of their effect, and so on. I don’t believe that unit testing can help prove whether a game design is fun, but it is very valuable to proving that code is correct. I’d rather spend my time in GameMaker playing with design experiments, not trying to figure out why something I coded doesn’t quite work like I thought it should, and if I could write unit tests for my GML code and use them, that would be a huge win.

Extensions

Windows and HTML5 already allow custom extensions, so this will add them to iOS and Android.

As I understand it from what I’ve read elsewhere, this means native code extensions. So far, I’ve done a little bit of work in creating extensions for my projects, and all of that has been done in GML, at first because that was the only thing I was comfortable writing them in, and then later because I wanted my extensions to be usable no matter what platform I was targeting. Being able to write extensions in other platforms that are native to the platform will mean substantial performance boosts, and the capability of leveraging existing code libraries, and potentially even entire engines or frameworks. This is great because it means a lot of existing functions are soon to become available to GM:S projects, and won’t require a lot of re-invention of the wheel. Instead, developers can just glue existing wheels written in other languages onto their GM:S projects.

The only downside to this is that I fear this will turn into an excuse not to implement language features in GML, when it comes to future development of the GML language and the GameMaker framework. “Why bother implementing [requested feature], it already exists in [other language], so just go install [some extension] or learn [other language] and implement the extension yourself!” may become a frequent response to feature requests and criticism of GM:S.

One of the really nice things about GameMaker was that it was a small, simple, self-contained language. As well, non-GML extensions have not historically had full access to the GameMaker runtime engine, meaning that in essence when you made a call to a native-code .dll extension, you were passing some data values out of GameMaker into the .dll, which would only know of those values, and it would do whatever it did, and return a value back to GameMaker, which you could then do something with. This scope boundary made native extensions a bit more difficult to work with, and a bit more clunky as well, and as such I tend not to use them.

As we’ve seen with the newly-added features such as source control, Box2D physics, and shaders, GM:S has for some time now been bolting on more and more stuff in order to quickly deliver features it has historically lacked, which are already familiar to experienced programmers and really don’t need to be re-invented. But this means that non-programmer game designers will have to stretch themselves increasingly further in order to gain mastery over these new features.

Much as web development in the mid-90’s was all about learning HTML, which was dead simple and easy to learn in no time, and then later along came CSS and Javascript, and SQL, and backend scripting languages like Perl, PHP, and ASP, which made things increasingly complex and difficult to learn, and then specialized Javascript libraries and frameworks like Rails, I see the same thing happening with GM:S — a tool that was once very simple to pick up and learn is growing more capable at the cost of increasing complexity, sacrificing ease of use.

True Type Fonts

The ability to add True Type Fonts to your game from an external file and support for non-roman alphabet languages.

This is a nice thing to see. It’s a little bit hard to feel truly excited about fonts, but TrueType support is another one of those things that is long overdue and will make GM:S feel no-longer antiquated in its typeface options.

Simple Flash Asset Importer

Allow importing of certain Flash assets directly, including things like vector images, and PSD files.

I never did get into Flash, so this isn’t especially important to me, but it will allow vector sprites and therefore resolution independence, which is pretty awesome.

Spine Animation Importer

Allow importing of animations created using Spine.

2D Animation runtime

Visualize in GameMaker any assets imported from Flash or Spine.

I haven’t used Spine, but it sounds a lot like the Spriter project, which I helped fund the kickstarter project for. So, hopefully this doesn’t mean that GameMaker won’t support Spriter in favor of Spine — one of the Spriter project’s stretch goals was support for GameMaker, and I still would like to see that delivered.

Push Notifications

Will permit you to use push notifications to inform the user of things on iOS and Android.

Mobage

Integration of the Mobage SDK will permit you to use their social gaming network in your games.

These last two are of special interest to developers targeting mobile platforms and social networks, which is pretty much everyone these days who wants to make money doing independent game development.

Early Access Builds

This is a very big deal for me. To date, GM:S has offered two update channels: Beta (for the latest builds), and Stable (for more well-tested builds) — but only one installation. So you had to decide whether you wanted to get the latest release and risk bugs, or the stable channel with its slower delivery of cool new features. Now, however, they’ve changed the way this works, so that the “Early Access Build” can be installed adjacent to a stable release, allowing the developer to play and experiment and learn the newest features before they’re ready for official integration, and not have to give up having a stable IDE for serious work. I’ve been burned at times by trying to use features that weren’t ready yet, and now I feel like I can safely do that without being punished by project-breaking bugs from the beta channel.