Game Developer. Artist. Nerd. Currently working on http://bunkerpunks.tumblr.com/
Don't wanna be here? Send us removal request.
Text
Pedro’s tutorial about swords! ⚔️
More stuff on his Patreon page
2K notes
·
View notes
Photo
Dance anywhere, anytime! Dance on the walls! I don’t care!!!!!!!
79 notes
·
View notes
Video
youtube
Bunker Punks is coming out in less than 2 weeks, but you get to see the launch trailer today!
4 notes
·
View notes
Photo
Bunker Punks has been updated to ver. 0.9.6, adding more variety to the level generator and balance improvements. We’re almost ready for ver. 1.0!
https://store.steampowered.com/app/446120/Bunker_Punks/
6 notes
·
View notes
Photo
In the final stretch now. I’m really happy with how the game is coming together.
Bunker Punks has been updated to 0.9.5. Tons of polish and balance improvements, especially to the mid-game.
https://store.steampowered.com/app/446120/Bunker_Punks/
6 notes
·
View notes
Photo
What a great way to start the week.
So hot recently! Here is another summer Dinosports!! Please enjoy dino diving~
58K notes
·
View notes
Video
One of the most beautiful animated shorts I’ve seen in years.
vimeo
And here comes “Tides”, a visual poem co-directed with the one and only @simon-duong. It was supposed to be a CG exercice at school, but we decided to do something else. We put so much love and work into this… I truly hope you will like it. Put your headphones on, press play and enjoy! Don’t forget the subtitles if you don’t understand French.
Loosing himself between memories and fantasies from his childhood, a sailor remembered his encounter, friendship and love with the sea.
“I first saw them from the top of the cliff Some days I watched them sliding on the sand Coming and leaving as the days went by The wind carrying their scent on my face We were good friends back then I observed them in silence Behind the barrier of sand One of them pulled me into her run She was fiery and fast The other, peaceful Unveiled her treasures in the sunrise You never stopped calling my name Carrying my body on your swell, pulling me away from the shores I’m sailing today come hell or high water on this sea with two faces”
462 notes
·
View notes
Video
instagram
New video up of this Galactic Girl.🌌 Link to the full video in my profile and here ⭐️ youtu.be/gqa8OmP2chY ⭐️ - Prints of her and three others will be available on my shop by the end of today. Check back for the coupon code 🎉 - Thank you so for watching ❤️💚 - #watercolor #archeswatercolorpaper #liquidfrisket #danielsmithwatercolor #winsorandnewton #cotmanbrushes #smallworks #worksonpaper #painting #paintanyway #traditionalart #traditionalpainting #ooak #originalart #baopham #baotpham #baophamart @danielsmithproducts #nightdreams #dreamgirl #nebula #galaxy #wip #galaxygirl #cosmic veil #galacticdreams #workinprogress #nebulousdream #starrynight #star #timelapse #timelapsepainting
291 notes
·
View notes
Text
Put a lot of work into this one. It involved rebuilding a lot of systems, but the game is much better for it.
Bunker Punks Ver. 0.4 is Live
Bunker Punks has just been updated! Take more loot back to your bunker, sell the loot and use the money to heal punks. All that and a whole bunch more in one of our largest updates yet.
http://store.steampowered.com/app/446120/Bunker_Punks/
5 notes
·
View notes
Text
How Cutscenes Work in Wandersong
Wandersong’s a musical adventure game about a bard, where you use singing to solve the world’s problems. It’s made in GameMaker Studio. And it has a big emphasis on story, with a lot of characters and unique scenes. People often ask me how I implement all that behind the scenes, so I figured I’d share my tools a bit.
(Above: a typical conversation, and some of the code that drives the scene)
The basics are pretty straightforward. There’s a cutscene manager objects who hangs out invisibly in every screen of the game. When one of the special cutscene scripts is called, it passes instructions to the cutscene manager, who always keeps a list of instructions running. And whenever the cutscene instruction list has anything in it, the cutscene manager broadcasts that a cutscene is happening, and processes the instructions in its list one by one, until they’re done.
The most important detail of this implementation, I think, is that it lets me write cutscenes inline with the rest of the game logic, and it’s all very natural and fluid, so I can focus on being creative and making it as I go. Other games will often separate the writing and scene stuff into separate files or systems, like an XML data file or a LUA interpreter or something, so that it’s easy to collaborate with a writer without them having to deal with programming, and it can be exchanged later with translated versions. But since I’m also doing all the programming and animation anyway, it’s easier for me to put it together all at once. I’m pretty far along on a solution for translations, too, but that’s for another time…
I’ll share some nitty-gritty on how I make it work specifically in game maker below.
Here’s a typical cutscene script, marked up a bit. All of them follow this structure, which, right out of the gate, is pretty hacky, heh heh. There’s actually two completely different uses for each script, one for when it’s used by the scene manager (red), and one for when it’s used by anything else (blue). The blue part is the one that happens first, so I’ll start there.
The blue part is basically identical in every cutscene script, actually, and I always make a new scene script by duplicating an old one because of this. First, it adds the name of the current script to the objSceneManager’s “scene” list. In Game Maker the name of resources like scripts, sprites, sounds etc. are automatically special words that let you point to them (for example, when you want to play a sound file, typically you’ll tell it the name of the sound so it knows which one to play). So the script basically adds itself to a list somewhere.
Second, it makes a new list that contains all of the “arguments” passed to it. This script is for setting the position of an object during a cutscene, and I give it the name of an object, an x position and a y position… so all those values are stored into a list, and then it adds that list to objSceneManager’s “scene_args” list. Lists of lists might sound kind of silly, but this game is full of them behind the scenes, and they also excite me in ways I don’t fully understand.
This little pile of code is the key that makes the rest of it run, basically. The line underlined in red is the big one. The scene manager tracks where it is in the cutscene with a variable called “scene_moment,” and every frame it looks at that spot in the scene and scene_args lists and runs all the instructions left there. The arguments we passed to the scene initially are stored in lists, and we pass those lists back to the script when we run it from the scene manager. Scene scripts when run from the scene manager always return a true or false, to let it know if they finished their job or not. The scene manager runs them from a “while” loop, which goes forever until it gets a “false” from one of these or runs out of them. The blue section shows what happens when it runs dry… basically it just clears and resets everything.
Back to here, now, looking at the red section… this is how it runs from the scene manager. Instead of looking at arguments, we look at the list passed to us in argument[0], and evaluate the contents of that list like arguments instead. Then we do a little code and return true. Actions that take time or need input, like a textbox or a “Wait for x amount of time” command, will return false until their conditions are all met, at which point they return true. This way I can have many actions parsed in the same frame, like a camera movement and a sound being played, and other times I can create timings by adding in pauses and stuff.
Ta-da! That’s it. I hope it wasn’t too hard to follow. I’ve done a number of games with lots of text and scenes before, but this basic system was a new idea for this game and it’s been by far the most useful and flexible system I’ve been able to work with. Feel free to lift the structure wholesale and make sweet cutscene-filled games with it. And also, feel free to send me questions if I wasn’t clear enough about something.
170 notes
·
View notes
Photo
Hello and welcome!
Happy new year! That last year was kind of a doozy. It’s not that year anymore, it’s an entirely new year ready to be filled with games and art.
Among all the things that happened in 2016 there is something I’m so grateful for. I reached out to the universe and said hey, I like strange games. I had no idea you all were out there liking them too.
Thanks for reading this little book :)
<3 AD
Mentioned in this issue:
Buried, Tara Copplestone, Luke Botham
blind to siberia, calico reverie and alxalxalx
It Whispers, You Listen, Aleks Samoylov
Fermi Pasteladox, William Anderson
Does Canned Rice Dream Of A Napkin Heap?, Caelyn Sandel, Carolyn VanEseltine, Danielle Church, & Jamie Sandel
Underground Hangovers, Deconstructeam
Feel Face, Samuel Boucher
w1tchkr4ft, Maurice Grela, Ivy Edwards Wilson
HUGE thanks to Samuel Boucher, Maurice Grela and Ivy Edwards Wilson.
PDF
Layout for printing diy style
8 notes
·
View notes
Text
How Save/Data Management Works In Wandersong
Wandersong is a musical adventure game about a bard, and it has a lot of characters and cutscenes and conversations! As a result of this, there are a LOT of very small bits of information the game needs to keep track of… The most common being, “how many times have I talked to this character?” It seems like a pointlessly small thing to write about, but it comes up a lot and I have a solution for it that I very much like, so I figured I’d share.
A typical conversation
In short: all data is stored into a giant dictionary. At the start of a new game it’s completely empty, and entries are added as the player interacts with things. If an entry doesn’t exist in the dictionary yet, it’s treated as being set to 0.
Sounds stupid simple, right? OK, it is. But it’s powerful! What follows is an explanation of how it’s implemented in GameMaker Studio.
Instead of “dictionaries,” GameMaker has a data structure called a map. For the uninitiated: a dictionary/map contains data stored in pairs, a “key” and a “value.” The “key” is kind of like an entry name or label, and the “value” tells you what it’s set to right now. At the start of the game, I make a blank map like this:
And then I have but two scripts that deal with this data.
data_set
Which takes two arguments, an entry name and a value. It either adds a new entry to the dictionary, or updates it if it already exists… and for good measure, it autosaves the game too, because why not. (Actually I forgot it did that until now, but I guess it happens so fast I never noticed, so…?)
and data_get
You give it an entry name, and it tells you what’s stored there. Or 0 if it doesn’t exist yet. (This is important!)
And here is how it typically would get used, in the interact-with-a-character event:
So for this event, I used an entry called “talking_to_bob”. I check what’s stored there, give you a different piece of dialog depending on what it is, and then set it to something new for next time. Typically in Wandersong, an NPC conversation tree follows the logic (conversation 1) - > (conversation 2) -> (conversation 3) -> (conversation 2) -> (conversation 3) -> etc. But you can do whatever you want with this.
There are a couple big advantages here. When I save the game, I just save the contents of the game_data dictionary–which is just a couple lines of code to do–but that’s flexible enough to include any amount of data, forever. So I can add new conversations, new conversation branches, or track anything I want anytime while I’m in the middle of writing a scene, and I don’t have to worry about bookkeeping anywhere else. It lets me be flexible and loose and have weird ideas as I’m going, and it makes it very easy to add new responsive content. It’s considered bad practice to save data under a string name as I do here, since I could easily typo “talking_to_bob” and there would be no easy way to track errors that stem from that (unlike a variable name, where a typo would just make game crash). But that “talking_to_bob” entry name is not written out ANYWHERE ELSE IN THE CODE except right here, so it’s easy to correct errors.
The other advantage is the synergy this has with my cutscene system. Or really, the way it deals with my system’s biggest weakness. This is going to be a little abstract. The weakness is this: I send instructions for an entire cutscene all at once to the scene manager, and then sit and wait for the entire scene to play out over time. This is mostly great, but what if I want the cutscene to change depending on data that gets altered after it already started… like in this one, where you enter your name and it’s read back to you?
To make this work, when the cutscene instructions are sent off, instead of supplying the player name, I supply a dictionary entry to look at for the player name… this way, as the cutscene is running,the text can update as the dictionary entry updates. In GameMaker, crucially, you can’t use a regular old variable this way…
And that… covers it! It’s not as glamorous as my last how-to, but I think the usefulness is actually much broader. With all my tools and systems, I’m always looking to get the most power and flexibility with the minimal amount of typing and actual organization/management. If you’re going to make an entire game by yourself, especially one that’s overfilled with content, you have to think this way or you’ll never be done! Anyways. I hope this is useful to you. Feel free to send me questions if I left something unclear!
144 notes
·
View notes
Photo
I made a little Bishop for Pixel Dailies.
1 note
·
View note
Photo
A sci-fi desk for today’s Pixel Dailies.
2 notes
·
View notes
Text
How Cutscenes Work in Wandersong
Wandersong’s a musical adventure game about a bard, where you use singing to solve the world’s problems. It’s made in GameMaker Studio. And it has a big emphasis on story, with a lot of characters and unique scenes. People often ask me how I implement all that behind the scenes, so I figured I’d share my tools a bit.
(Above: a typical conversation, and some of the code that drives the scene)
The basics are pretty straightforward. There’s a cutscene manager objects who hangs out invisibly in every screen of the game. When one of the special cutscene scripts is called, it passes instructions to the cutscene manager, who always keeps a list of instructions running. And whenever the cutscene instruction list has anything in it, the cutscene manager broadcasts that a cutscene is happening, and processes the instructions in its list one by one, until they’re done.
The most important detail of this implementation, I think, is that it lets me write cutscenes inline with the rest of the game logic, and it’s all very natural and fluid, so I can focus on being creative and making it as I go. Other games will often separate the writing and scene stuff into separate files or systems, like an XML data file or a LUA interpreter or something, so that it’s easy to collaborate with a writer without them having to deal with programming, and it can be exchanged later with translated versions. But since I’m also doing all the programming and animation anyway, it’s easier for me to put it together all at once. I’m pretty far along on a solution for translations, too, but that’s for another time…
I’ll share some nitty-gritty on how I make it work specifically in game maker below.
Here’s a typical cutscene script, marked up a bit. All of them follow this structure, which, right out of the gate, is pretty hacky, heh heh. There’s actually two completely different uses for each script, one for when it’s used by the scene manager (red), and one for when it’s used by anything else (blue). The blue part is the one that happens first, so I’ll start there.
The blue part is basically identical in every cutscene script, actually, and I always make a new scene script by duplicating an old one because of this. First, it adds the name of the current script to the objSceneManager’s “scene” list. In Game Maker the name of resources like scripts, sprites, sounds etc. are automatically special words that let you point to them (for example, when you want to play a sound file, typically you’ll tell it the name of the sound so it knows which one to play). So the script basically adds itself to a list somewhere.
Second, it makes a new list that contains all of the “arguments” passed to it. This script is for setting the position of an object during a cutscene, and I give it the name of an object, an x position and a y position… so all those values are stored into a list, and then it adds that list to objSceneManager’s “scene_args” list. Lists of lists might sound kind of silly, but this game is full of them behind the scenes, and they also excite me in ways I don’t fully understand.
This little pile of code is the key that makes the rest of it run, basically. The line underlined in red is the big one. The scene manager tracks where it is in the cutscene with a variable called “scene_moment,” and every frame it looks at that spot in the scene and scene_args lists and runs all the instructions left there. The arguments we passed to the scene initially are stored in lists, and we pass those lists back to the script when we run it from the scene manager. Scene scripts when run from the scene manager always return a true or false, to let it know if they finished their job or not. The scene manager runs them from a “while” loop, which goes forever until it gets a “false” from one of these or runs out of them. The blue section shows what happens when it runs dry… basically it just clears and resets everything.
Back to here, now, looking at the red section… this is how it runs from the scene manager. Instead of looking at arguments, we look at the list passed to us in argument[0], and evaluate the contents of that list like arguments instead. Then we do a little code and return true. Actions that take time or need input, like a textbox or a “Wait for x amount of time” command, will return false until their conditions are all met, at which point they return true. This way I can have many actions parsed in the same frame, like a camera movement and a sound being played, and other times I can create timings by adding in pauses and stuff.
Ta-da! That’s it. I hope it wasn’t too hard to follow. I’ve done a number of games with lots of text and scenes before, but this basic system was a new idea for this game and it’s been by far the most useful and flexible system I’ve been able to work with. Feel free to lift the structure wholesale and make sweet cutscene-filled games with it. And also, feel free to send me questions if I wasn’t clear enough about something.
170 notes
·
View notes