I've updated another of my old GameMaker examples to be compatible with GameMaker: Studio! This time, however, I've completely re-imagined the old example, and replaced it with something that demonstrates the same principles, but in a totally different way.
The new example is a 3D Starfield simulation, and it replaces the old 3D Night Sky file.
This new example uses the same technique as the old one, creating a model and using primitives to add points to it which draw as our "stars", but this new example also adds some linelists to the mix, as well as some infinite motion. I think it's a much more fun way to see this technique demonstrated, and it wont feel quite as redundant when I get around to updating the day/night cycle example as well.
I've updated my old 3D animated water examples to be compatible with GameMaker: Studio today, combining the two former examples into one superior example.
The previous examples used two methods for creating the water effect. The first used layers of scrolling, textured 3D planes drawn with an additive blend mode to make a detailed, if not always pretty, body of water. The second used a pre-animated texture, created in PhotoShop, to create a similar effect. A skybox was also employed, to make for better background scenery.
This new example combines methods from both of these files to create, in my opinion, a superior effect. With this updated example, the layers of scrolling texture have been relegated to a surface, which gets updated each step. This surface is then drawn over a base color plane for the water, all over a skybox with pre-baked reflections built in.
The effect could probably be more detailed, or could benefit from shader support for true reflections, but for what it is, I think it's a notable improvement.
I spent some time experimenting with my Blender addon and GameMaker's 3D the other night, and I realized that the models it was creating were not entirely how they should be. It seemed that if you used the option to flip the object's Y axis on export, which is often necessary because GameMaker and Blender's world axes are different, then the model's normals would be flipped.
This wasn't immediately obvious to me, since the correct orientation of GameMaker's built-in models has always been kind of ambiguous, in my opinion. After following the code in the manual to make some of the primitive shapes however, I compared the results to what my Blender addon was creating, and came to the conclusion that the output from my addon was not quite correct.
So after a lot of tinkering (Python and Blender API are not my strong suits) I believe I've finally got the addon updated to export models that are oriented correctly and which should always have correct normals. Additionally, I added a feature which a friend of mine had built into his own version of the addon, which will let you output the model script in an alternative way, to more easily allow you to add it to an existing model in your game.
You can download the updated version of my Blender addon at the original page, which I've changed to include the newly updated addon. That will always be the place to go for the most recent version.
I've updated my 3D cylindrical world example to work with GameMaker: Studio. This new version looks a lot better and has a few extra features, such as fog and a sun. I re-created all of the textures used in the old example, and cleaned up the GML a bit.
You can find this updated example file, along with all my other GameMaker examples, at my Examples & Tutorials page.
A little late for the 4th of July holiday, but nevertheless, I'd like to present a new GameMaker: Studio example - particle fireworks!
This is a pretty simple example which procedurally generates everything you see, using GameMaker: Studio's built-in functions. Most of the effects, such as the fireworks, smoke, and stars, all use the particle system. The sky is made with colored shapes and the land is a primitive.
Even though I started this from scratch, I consider it the spiritual successor to one of my really old game demos, which was also a fireworks simulation. I created that one to test out the particle effects in GameMaker, back when they were somewhat new. Here's what it looked like, in case you want to see how far things have evolved:
I think it's safe to say that both GameMaker and I have gotten a lot better at particles over the years!
Before I say anything else, let me state that I always have a little apprehension about posting stuff like this. It can come off as "sour grapes", and that's not how I intend it to be at all. What I want to discuss here is the divide that often occurs between designers and their clients, and why I think it happens - at least, in part.
Recently, a website called petRockBlock ran a logo design contest for RetroPie, a Raspberry Pi-based gaming project they host. RetroPie is a collection of scripts and software that helps you easily set up your Raspberry Pi to use as a retro gaming console. It's a neat project, and if you're looking for something fun and relatively simple to do with your Pi, I'd recommend it.
Though I didn't win the contest, I submitted a handful of entries. I created three versions of the logo and presented four variations of each. That might seem excessive, but my intention was to try to show that the logos were flexible, and that I would be willing to make alterations if they liked any of the base designs. With this being a contest, there was also no opportunity for the typical client/designer communication that would take place under normal circumstances.
As with any design contest, there were stipulations for the design. Here they are, copied from the official contest announcement page, and edited to remove obvious rules that aren't relevant here:
Musts
Something that looks good small as well as in larger formats.
Something that we could also use on merchandise, stationary and in publicity materials.
Flexibility is important in colour as well as style.
The logo should look good in b/w as well as in colour.
No words should be incorporated other than the words “Retro Pie” with or without a space.
Be generic enough to not favour or promote any one system or game.
Ideal
We’re after something that will be recognisable.
It should capture retro gaming as a whole.
Avoid clichés or the obvious.
The fewer colours you can use the better.
Most of these requirements were easy to meet, but a handful of them serve to box in what petRockBlock was after; namely, a versatile logo which isn't generic, doesn't associate too closely with any one retro system in particular, and which is unique and not too obvious.
Based on all of this, here's a sample of what I made:
All are very simple, use an interesting color scheme, and weave in some form of retro gaming via the gamepad, the d-pad/buttons, or the blocks/pixels. I took care to make sure that the type was bold, and that there wouldn't be any small details that might get in the way of reproducing the logo at different sizes or on merchandise. If I broke any rules, it was that I used 3-4 colors in each, but that is a minor problem and I wanted to express each logo in its best possible form.
One other thing I did was avoid using any sort of pie, cake, or pastry imagery, as I felt that that was explicitly being rejected by the stipulations above.
Here's the logo that won the contest (by Garry Marshall):
By now you probably saw where I was going and expected this - this logo seems to break a number of the stipulations set forth in petRockBlock's suggestions.
As a designer, I can appreciate that to an extent. When I have a good idea I will try it out, even if the client doesn't initially want it. That's really just part of the process; if everyone could pinpoint what designs worked and what didn't without the designer's help, they wouldn't need one in the first place.
I also think the joystick imagery is smart. If there's anything more about retro games than a gamepad, it's a joystick. Building it into the pie is somewhat clever, but there we've broken the rules again. Or maybe when petRockBlock stated that they wanted designers to avoid the obvious, they meant with game imagery and not pies? I don't know.
But this is often the case with design work - the client doesn't really know what s/he wants initially, or doesn't have the words to articulate it properly. It's like when you have to take your car to the mechanic and explain the noise the engine is making - you're not an expert, so you're trying to communicate with someone who is in the best way you can. There's nothing wrong with that.
Miscommunication like this is a little more frustrating when it comes to design contests, since you don't have a second chance to iterate on the work you've done. But that's just how it goes. So while perhaps it initially appears that Garry ignored the guidelines and just created something he liked, I suspect that it was instead a simple lack of clarification that resulted in unclear rules that many others who entered the content chose to follow. I have other problems with this logo that I won't get into here, but I can't get mad at it for not following the guidelines.
If you happen to be someone who might ask a designer for help in the future, do spend some time thinking about how you communicate your wishes with anyone who might work for you. Make noises, draw a picture, find images of things you like and share them - do whatever you need to. Some designers may not agree with me in this, but in my opinion, it all helps.
To continue my string of updated GameMaker projects, last night I uploaded a new version of my old Mandelbrot Fractal Explorer project, finally making it compatible with GameMaker: Studio.
The previous version was built in GameMaker 6, and relied on old functions like screen_refresh(), which have since been removed from the program. Surfaces are much more robust these days, so I've employed them instead of the old tech. I've made a handful of improvements to the functionality of the program as well, including making the zoom center on the view (this had always bothered me before), adding a timer to the render process, and moving the fractal drawing code out of a script (which basically froze the program for input on every update/render) and into the step event where the fractal surface is updated progressively, and the user can easily interrupt it at any time.
Render times remain an issue of course, but this was originally just an attempt to see if I could build something that would render fractals at all, so I still consider it a success.
The full source for this project is now available on my GameMaker Examples & Tutorials page, so if you'd like to tear it apart, make it better, or just see how it works, go right ahead!
I've managed to get my 3D rain example for GameMaker updated for GameMaker: Studio. I'm accomplishing updates at a pace that I can't sustain, woohoo!
This new version is near-fully commented and includes an updated rain effect that uses very simple models instead of textured walls. It also introduces water splash ripples and has a much better skybox than before.
I'm continuing to pick through my old GameMaker examples and update them for GameMaker: Studio, and the most recent example I've fixed now is the Faux Mode 7 example, which recreates the look of the original Mario Kart in GameMaker.
The example doesn't emulate true Mode 7 (it uses GameMaker's native 3D functions), but it uses a combination of techniques to create a retro 3D look.
It seems like I come back to my old GameMaker examples and update one of them about once a year. I try to do better than that, and probably do, but that's how it feels sometimes!
Anyway, today I updated my example of a textured vertex path in GameMaker: Studio. I've spent some time removing a lot of the code that didn't need to be there, renaming some variables and assets so that they make a little more sense, and adding comments all around.
