Tag: GameMaker

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.

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…)

DRM signals early death knell for legacy GameMaker development

development, reviews
3 Comments

It’s generally known that GameMaker 7 and 8 use a DRM technology called SoftWrap to manage license and product activation. Today, YoYoGames released the following announcement, regarding this technology:

http://yoyogames.com/news/172

Update for GameMaker 7 and 8 Customers: Please Read

We want to inform all GameMaker 7 and 8 customers that Softwrap, our exclusive technology provider for GameMaker 7 and 8, has announced a change to its business. By August 31, it will no longer be possible for GameMaker 7 and 8 customers to install or reactivate their licenses. After August 31, if you are having issues reactivating GameMaker 7 or 8, please register a ticket that includes your Softwrap license code via the YoYo Games Support Center and our agents should be able to help you.

In reaction to this news we would like to help migrate users to GameMaker: Studio. “Studio” is the current version of GameMaker and the only version where we offer regular updates and support. We’re therefore offering customers of GameMaker 7, 8 and 8.1 an upgrade to GameMaker: Studio Standard for only $9.99., which is a $40 saving on the regular price.

To upgrade to GameMaker: Studio Standard, simply click here and enter your Softwrap license number to purchase a license for GameMaker: Studio Standard.

For more information on how to migrate games from GameMaker 7 and 8 to GameMaker: Studio Standard, please read our Wiki entry “Porting GameMaker 7 and GameMaker 8 to GameMaker: Studio.”

We apologize for this inconvenience but hope you find our offer to upgrade to GameMaker: Studio compelling enough to take advantage of it.

Thank you for your continued support of YoYo Games.

The YoYo Games Team

It’s not entirely clear from this what the help YYG plans to offer GM7 and GM8 users will consist of, or how long they’ll continue to offer this help.

A consumer friendly failsafe for the contingency of the DRM license servers going offline should be to unlock the product for all users. Not doing so can present a great inconvenience. If YYG and Softwrap goes out of business, or simply change their policy, that’s it for your GameMaker license. Short of hacking around its product activation, there’s no way you’ll ever be able to use it again.

That’s for a product that you paid for. This changes the nature of purchases into something more akin to a subscription or rental — only, your continued right to access that which you have paid for is contingent upon the continued existence and goodwill of the business entity who provided it to you.

Imagine having a tool chest filled with expensive tools that you paid for, but then finding one day that the chest has become permanently locked as a result of the manufacturer going out of business. That’s what it’s like to use DRM-encumbered tools.

Offering a discounted upgrade path to developers who haven’t yet adopted Studio is better than nothing, but it’s likely that developers who are still on these old versions have not upgraded yet not because of financial reasons, but because of legacy projects that are not easily ported to Studio due to a dependency on now-deprecated functions that are no longer supported in Studio. For any such developers, migrating their codebase from GM7 and 8 to Studio could involve substantial re-engineering.

YYG no longer use SoftWrap DRM with GM:Studio, but does continue to use a DRM solution, and YYG have stated in the past that they will likely never abandon DRM. I disagree with their stance on the matter, but I recognize that it is their decision to make. I continue to recommend that they abandon DRM in the future, and figure out a business model that allows them to do so.

I also encourage them to release a non-DRM encumbered version of GM7 and 8 for existing licensees who wish to continue supporting legacy codebases that they are unable to port to Studio. When a business elects to cease support for a product that they released, the most ethical thing to me would be to release the source code for the product, so that those who wish to continue using it can develop their own patches and updates. Failing that, at the very least they should unlock any DRM that would prevent customers from being able to use what they’ve paid for.

Radar demo update

development, games
5 Comments

I’ve made a number of really nice enhancements to my earlier Radar demo.

The improvements:

  • The original demo used collision_line() to detect when the radar sweep collided with the radar blips to refresh them. This meant that the collision detection could skip over smaller objects at great distances from the antenna, since the space between steps is not scanned. The new one uses an approach based on the angle difference between the mappable object and the sweep’s current and previous positions, and is therefore much more accurate.
  • The original radar used a classic looking monochrome green radar screen. The new one implements IFF (Identify Friend or Foe) color coding. This system is flexible in that it allows you to change the value of the color variables used in the color key, or even a unique color if desired. oMappable child objects must have two instance variables, blip_alpha and blip_color. The demo only uses color for IFF, but for colorblind players it would be helpful to modify the routine to use shape as well as color to identify the blips.
  • I’m particularly proud of how understandable and well-commented the code is, so if you’re a developer and want to modify it for your own needs, it should be quite easy to do so.

I still can’t get it to run in HTML5 builds, so a screen shot will have to do.

Radar Demo by csanyk

Download radar_example.gmz

GameMaker tutorial: Elegant instance_change() in your state machine

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

In GameMaker, a commonly used technique is to build a system made up of a several objects to represent an entity in your game, such as the player or enemy, in various states, such as idle, dead, shooting, jumping, running, climbing, and so forth. This is what is known as a Finite State Machine pattern.

When the time is right in the game, we change an instance from one state object to another by using the powerful instance_change() function. Instance_change() takes the instance and transforms it into a new type of object. Its Event behaviors will change to those defined by the new object type, but its old properties (object variables) will remain the same as before, allowing the instance to retain its variables with their current values.

The instance_change() function takes two arguments: object, the object the instance will turn into, and perform_events, a boolean which controls whether the new object’s Create event will be performed or not.

Normally, the Create event is where an object initializes its variables and initiates its default behavior. When we’re dealing with a State Machine comprised of a number of objects, this can become problematic, however. Some code in the Create Event is initialization code that we may only want to execute one time, to set up the instance when a brand new instance is created, while other code in the Create event is behavioral and we may need to execute whenever an existing instance reverts back into that state again. Thus, the perform_events argument in the instance_change() function isn’t adequate for this situation — it’s too all or nothing.

For example, let’s say I have a generic object for an enemy, oEnemy. I want some visual variety to this enemy, so I’ve created a few different sprites for it. In the Create Event, I want to randomly choose one of those sprites to be the sprite for this instance. But if the instance changes into another state object, and then reverts back, if I call the Create Event, it will randomly choose a new sprite. I don’t want this, as it ruins the illusion of continuity — I need that instance to retain its sprite. But I do need the Create Event to run, whenever it re-enters this state, because I’m using it to set the instance in motion.

So, how can I elegantly select which lines of code I want to run in the Create Event?

Conditional blocks

This is the least elegant solution, but you could use if to check whether a variable exists or has a value. For example:

if sprite_index == -1 {sprite_index = choose(sprite1, sprite2, sprite3);}

This is inelegant because it adds lots of lines of code that only need to be run one time (when a brand new instance is created) but need to be checked potentially many times (any time that instance changes back into the object state). It also only checks certain, specific things, case by case. As I continue to build the state machine, I may end up introducing more features which require initialization, which would necessitate more checks, further bloating the code. I always want to write the least amount of code needed, both for reasons of performance and maintainability.

Move one-time code to an init state object.

The more elegant solution is to recognize that initialization is its own state, and we need to separate it out from the other states in the state machine. We can create an oEnemy_init object, put our one-time initialization code into it, and then the final step in the Create Event for the init object would be to change the object into the default state.

None of the other states in the state machine should put the instance back into the init state, thereby guaranteeing that the init code only executes once. Now your code is neatly separated, your states objects in your state machine are as simple as can be.

Radar

development, games
Comments

I’ve been messing around with mini maps, and after a few different approaches, I have come up with a cool demo that simulates a radar screen. The screen even has a sweeping beam that lights up the blips, which fade over time. Only instances which inherit from an object called oMappable are drawn on the radar. The size of the blips is based on the width of the sprite of the oMappable child, so objects of differing sizes will be shown in scale relative to each other.

radar screenshot

It runs quite well, with up to 4000 simple objects (~30fps on a 2.0GHz Core2 Duo).

Demo (.zip)

Project Source (.gmz)

GameMaker: Studio Master Collection discount for Professional licensees

development
Comments

As covered by GameMakerBlog, YoYoGames has announced a special 60% discount sale for developers using GameMaker: Studio Professional only, allowing them to upgrade to Master Collection for $199. The special discount extends through 3/31/13.

This limited-time special offer is apparently in response to a situation affecting Professional licensees who had no cost-effective upgrade path to allow them to convert their existing investment to a Master Collection license. Following the recent release of the Ubuntu build target module, a paid upgrade for Professional users, there were complaints of unfair pricing affecting Professional licensees.

The big advantage for owners of a Master Collection license is that any future Game Maker build targets that happen to be released are automatically included as free updates, while GM:S Pro licensees have to pony up more cash for each piecemeal upgrade, thus making Pro a much more costly way to get all the features available in the Master Collection. As the Master Collection grows (and we don’t really know how much more, or if, it will grow), this disparity will only increase.

While this is a fine gesture on the part of YYG to respond to Pro license holders who asked for cost-effective upgrade path to the Master Collection, I still think it makes more sense for YYG to make it part of an ongoing pricing strategy, similar to the “Anytime Upgrade” option Microsoft made available to Windows 7 users, which would enable them to upgrade to higher product tiers for the difference in cost from their present tier, at any time. Hopefully YYG may yet make such a change to their licensing model — if you’d like to see that happen, I encourage you to send them feedback.

For now, this seems to be a good opportunity (and perhaps the only one) for any serious GameMaker Studio Professional users who may want to upgrade to the Master Collection.

Packt Publishing announces HTML5 Game Development With GameMaker

development, games, programming
Comments

Packt Publishing has announced an upcoming new book, HTML5 Game Development With GameMaker, by Jason Elliott, tentative publication date in late April 2013.

I provided technical review/editing of the book, and so I can say that it should be a good book if you’re looking to get into the newer features of GameMaker Studio. While the book focuses primarily on HTML5, almost all of the book is generally applicable regardless of what platform you wish to target.

Highlights include:

  • Facebook integration
  • Pathfinding and Artificial Intelligence
  • State Machine design pattern
  • The new Box2D Physics system
  • Particle effects for any game
  • File I/O and HTML5 local storage.

Leveling Up as a Game Maker Dev

Best Of, development, programming
4 Comments

Something that interests me greatly with making things is the process by which the maker transforms from a novice to a master. This is a process of learning primarily by doing and through experience. Things like reading about a subject, interacting with peers, or watching others demonstrate, or abstractly thinking about a topic all contribute to learning, but none so much as actually doing things.

To the greatest extent possible, one should endeavor to spend their time doing and making. Get outside of your head and make. Do not exhaust yourself while making and doing; give yourself opportunity to observe what, how, and why you are doing what you are doing, and take time to examine and reflect on these things. Then apply what insights you gain from this into your next doing and making.

As I have progressed in learning GameMaker, I have observed a few distinct phases in my development. I don’t know that I’m at the highest level yet, or if there is a highest level. But as a gamer I like being able to categorize things and assign levels to them :-)

I really wish that I had had something like this to guide me as I made my progress, so it makes me really happy to have written this. I think it can help a less-experienced developer have some idea of a criteria of competencies so they can figure out how to get better, things to look for that can help them get there without having to figure it all out for themselves. It can also help a mentor recognize where their protegé is at in their development and help them identify areas where they should focus in order to improve.

Here’s a summary of my progression as a GM Dev to date:

Level 0

Complete ignorance. It’s a struggle to do anything.

All you can really do is follow instructions in a tutorial, most likely doing things with drag and drop actions. And sometimes even that is frustrating.

Despite the instructions being clear and straightforward, you still have a hard time following them because you have questions that are so basic that the people who wrote the tutorials don’t even realize that you would have them.

If you’re trying to follow written instructions, you wish that instead of still images, you had an animation showing where to click and what to type. The instructions use terms for user interface widgets in the IDE that you aren’t familiar with yet, leaving you to guess until you figure out what they mean.

Six months or so later, you think to search for tutorial videos on YouTube, and find a bunch, although they’re not really much better because of amateurish production quality, and by this point you’re well beyond needing them anyway. Still, there’s a few good ones on topics you’re not yet clear on. (more…)

GameMaker Position and Motion Tutorial

Best Of, GameMaker Tutorials, games, programming, Tutorials
18 Comments

Motion is critical to just about any video game. Nearly every game has moving things in it, and how they move is a vital part of the game. Learning how to program motion and control it effectively is one of the most important parts of a successful game. There are a number of possible approaches to handling position and movement. Learning how these work will help you make better games.

This isn’t absolutely everything there is to know about motion, but it’s a great overview to start with, and covers everything I’ve learned with respect to motion in GameMaker Studio.  (more…)