I am really hitting the planet building mechanic hard, because I haven't found a game that actually does this the way I do it in Rocket Boy. It's really fun and I'm having a lot of positive results on what can be created with it so far. I'm proud to say that planet building is Rocket Boy's main game mechanic, and I'd like to talk on that for a bit.
In Game Maker you have something similar to a 2d array called a ds_grid. This is a data structure in GM with many built in features a programmer can use to access and manipulate data in the array quickly and easily! So whenever I say "grid" or "ds_grid" you know what I'm referring to.
Planet matter blocks can be moved in Rocket Boy. Only two objects in the game track planet matter; the planet core and the inventory object. There are only a few times when a block can be moved. The most used way a block is moved is from inventory to a planet core. During this process the inventory system calls it's specific block_transfer script. This script scans the grid of the destination planet core looking for empty cells (value of 0) with occupied cells (value greater than 0) adjacent to them. These empty cells are then marked with a different negative value depending on what direction the occupied adjacent cell lays. If the cursor moves to one of these cells with a negative value the planet matter block to be placed is drawn there and if the mouse left button is released the block is physically placed in that spot. Then the core grid is updated with the new values.
The issue started when updating the core grid. I easily worked out drawing the grid on screen for the player to place his blocks, but Rocket Boy has view_angle shifting and so I have to find out how to draw the planet grid shifted with the view so that it still all matches (see screenshot below).
Normally I would handle this sort of issue with my tried and true method of balling up in a corner and crying until the answer came to me, but I just don't have the time for that right now. Instead I decided to use my trusty old friend Google and sure enough the answer I did find in another game dev blog post for the game Heat Signature. You might have heard of Heat Signature, a game in development by Tom Francis @Pentadact.
When the view_angle is shifted the center of the room stays at the same real world x and y values as well as the same GUI x and y values, so using the distance to object functions and length_dir functions built into GM:S I can easily rotate the GUI with the view-angle while drawing over real world x and y values.
Well that's all for now. Short and sweet! Time to get back at it! I've got a Summer Sale going on over at itch.io, and a new version of Rocket Boy being released next month for Windows, OS X and Linux, so my work is cut out for me! Thanks everyone for the continued support and happy gaming!
Big news people! Thanks to Itch.io's new Refinery tools I have decided to setup an Early Access package for Rocket Boy.
Early Access gets you access to the game at all levels of development starting with alpha, direct input to what will go into the official launch version of the game, a shout out to you in the end credits of the official release, VIP access to content that will only be available to Early Access members, and of course a copy of the official game upon release!
I've desperately been seeking player feedback and I feel that Early Access release using Itch.io's Refinery tools is exactly what was needed! I am really excited to work directly with players on a weekly basis to make Rocket Boy as fun as possible when it is released!
This means I need to get right back to work, so I'll be cutting this one short, but keep an eye out for lots more to come! And feel free to jump in any time at https://dyingwolfwood.itch.io/rocket-boy
Hello to everyone following along! Sorry that it's been so long between posts, but I've been working really hard and haven't had much time for anything else. Progress is most definitely being made.
A lot of what I've been doing these last few weeks is cleaning up all of my existing features. Things like unique weather and seasons, and creatures for each of my four existing planet types. Began adding to some simple AI and how the game interacts with itself as well as with the player.
I've also continued working on gravity, atmosphere, and planet building. I am starting to get really excited about the planet building mechanics! Each planet block contains the code for it's planet atmosphere and weather, so mixing and matching blocks from different planets is starting to look really cool! I think there's a lot of fun to be had there, and I can't wait to explore and expand the mechanics further. Despite the crude state of the graphics at this stage in development I'll include a screenshot of that so you can get a basic idea of what I'm going for.
One issue that I've been struggling with since the creation of Rocket Boy is memory management. Every time I get it under control in one place I see it sprout up in another. The latest instance of that fresh hell was found while building planets. Planet building thus far has been an automated process at the start of the game, so managing active instances was easy to control. I've had to build subtle limits into the planet building logic to keep memory consumption at an optimal level. Enter the core block! The core block is the first block placed. Every planet must have one and the player cannot build a planet without starting with a core block to build off of. The core block manages the data for all of the other planet block objects while they're out of memory, and also decides when they are in or out of memory based on distance to the player. All planet block data is dumped into the core block when taken out of memory, and then injected back in when the planet block is added back into memory. The core block's data is dumped into a file upon saving the game to exit or when the player reaches a certain distance away from the core, and pulled back later as needed.
Another issue I had started to wrestle with was how to keep track of changes to a planet as the player takes blocks from one and moves them to others. How does one planet core know when a planet block no longer belongs to it? How does a planet core know when it has a new planet block? First I outlined the exact scope of the block moving mechanic. I found that planet block objects can only belong to, or be contained by core objects or the player's inventory. I began tracking block data in 2d arrays for both the core and inventory. These arrays are updated by the block instance itself anytime the block is placed or destroyed. Placing a block in inventory or on a planet updates both the blocks old container and the new one of the change.
After I finish working all of this out I'm gearing up for what is coming next. In the not so distant future I'll be implementing the network functions and multiplayer game features. I've been thinking a lot about that and considering my knowledge and existing experience in the technology industry I've decided that I'll be adding hosted Rocket Boy servers as well as the ability for players to host their own. I am still working out exactly how I'll host and what that will mean, but I do know that I will definitely be hosting servers.
Along with the networking functions I'll be implementing a feature that I honestly have wanted to see in a game, but really haven't found. I'm talking about game sync between all supported platforms. Hearthstone does it actually now that I am thinking about it, but nothing else that I've played. The idea of playing Rocket Boy on an iPad on the train ride home from work and then picking it back up right where I left off on my desktop at home is something I want to see happen. Since I'm using GameMaker Studio this is actually something I can do easily enough. As of now I know I'll be releasing for iOS, Android, PC, Mac, and Ubuntu. The Xbox and Playstation ports are definitely on the list as well, but I'm still working out the extra steps needed to develop for those platforms.
Also thinking about media. I have some youtube videos in the works as well as a few really nice screenshots I'll be saving for a big media push in the coming months. I'll be putting some effort into getting together a nice media package that showcases Rocket Boy's features and mechanics.
I've noticed that I'm getting a lot of reads, but no comments yet. I want you to feel free to chime in any time. I'll start working on posts that involve reader input, but I'd like readers to know that they are welcomed to get involved anytime!
Here are a few screenshots I just snapped real quick. Nothing special, but want to get more content out there. The graphics are starting to get better, but I have some nice ideas for them that I'll get out in the next post.
I did include one shot of Rocket Boy character design. That's still REALLY new, but I think it's going to end up really cool... More on that later as well.
Now that I know where I currently sit with Rocket Boy and where I'd like to go it feels like it is time to move forward. Time to roll up my sleeves and get my hands dirty! But where to begin? I could dive in and start adding new code. I've got mountains of missing or half finished features to attend to and it is exactly those unfinished features that lead to bugs. Mountains of bugs in my code already piling up to the ceiling. It's time to fix the bugs!
Bug hunting is always sort of fun for me. I mean there are the obvious bugs from just playing through the game, but aside from that I definitely enjoy the play-it-to-break-it mentality of finding bugs that might not be so obvious. I was never taught how to fix bugs. I just sort of picked it up as I went along, so if anyone has suggestions feel free to let me know. My current process involves play testing with the specific intent of finding bugs. When a bug is found it is rated on a severity scale of Major, Minor, and Glitch. A bug that gets a Major severity is a game breaking bug, a Minor severity is a bug that stops a mechanic in the game from working, but doesn't actually crash the game, and glitches are just small tweaks needed to some feature or mechanic that just isn't working exactly right.
After some troubleshooting I ended up with a list of 12 bugs as follows; 1 Major bug, 2 Minor bugs, and 9 Glitches. That is not so bad, and shouldn't take too long to get through. The game is actually in a really solid place. It looks like I'll be ready to start adding new features in no time at all. Yaaay!!!
But before moving forward I want to fix these bugs. Let's start with the one major bug. That one is actually a very ease fix. One of my leaf objects has a variable in it's draw event that is not defined. Easy fix. The rest of the bugs took another hour or so to get through, but I won't bug you with the details of this. I fixed them and all is right with the world.
Now I'm feeling back on track and it's time to start thinking about what features to add next. I obviously want to get my playable demo updated as quickly as possible, because it's pretty old and full of glitches itself. Taking that into consideration I'd love to complete four types of planets to randomize from and get the planet building mechanic all fleshed out as well. Then I'll be ready to share what I have with the world once more.
I'll get back here for another post in a day or two when I have something cool to show you! Until then thanks for reading and get out and do something cool today outdoors! The graphics are great out there! :)
It's been a while since I last worked on Rocket Boy. About a year actually. Rocket Boy originally started as a small project to explore GameMaker: Studio's physics engine. A short time later I found myself interested in procedural generation. A few other cool ideas came to mind here and there and before I knew it Rocket Boy had become a very large idea made up of so many very simple concepts. I decided that a project with a scope that large would need to be set aside for a later date, when I had more time, and perhaps was a bit more experienced. It has been a very busy year for me, and I felt that a refresher of the current state of the game was in order.
After a quick compile and play through I see that what I currently have is an infinitely scalable, proc-gen universe. Basically Rocket Boy can fly aimlessly in any direction and get all the planets his heart desires. As it stands I only have one model of planet, and plenty of bugs and glitches to go around, but each planet is unique and different from the rest. I'll start compiling a list of bugs in a bit, but next I need to get a clear picture of what Rocket Boy needs to become to be ready to ship.
Originally Rocket Boy was a 2d physics puzzle solving game, from there it became a planet explorer, then an example of what procedural generation can accomplish, and eventually I began adding the ability to build/grow your own planet by deconstructing other planets. Some of these concepts are just examples that need a lot of work, and some are completely fleshed out requiring very little revisiting. I've had plenty of play testing done on these concepts, and based on that I know that I'd also like multiplayer functionality and some sort of AI interaction to be added as well.
I'd like to settle on one general description of Rocket Boy that attempts to tie all of it's previous versions, concepts, and ideas together. After that if/when needed I can add and expand as my heart desires.
After a few tries I wound up with this: "Rocket Boy is a 2d space exploration adventure, and multiplayer planet building game." That is as far as I am willing go to define it at this point in development. That one sentence alone is enough to give me a good starting point and direction to go in without limiting or restricting myself from adding or taking a way later. It will help keep me agile.
Any indie developer who has ever completed a game from start to finish is probably getting some red flags by now, because that person knows that the larger the scope of a project is the more likely you are to never complete it. Fortunately I am not just a dreamer starting from scratch, planning a project with a scope that can never be reached for a game that will never be finished.
The scope of Rocket Boy might seem daunting at first, but I have a few things going for me. The first, and most important thing is that I have done everything I will be doing here before. I can use the code from other projects of mine to make Rocket Boy's development move along quickly and smoothly. Second, I use GameMaker: Studio. GM:S is designed for rapid game development and I will be taking advantage of it's designed purpose.
I have also been doing some thinking on what Rocket Boy should look like and if he should have other modes of transportation. Here are a few quick concept sketches of a direction I'd like to try to go in... Also thinking that Rocket Boy should have some sort of a logo, but I am no artist, and have no ideas of what it should be...
And that I end my second post. Please feel free to leave me a comment and let me know what you think. Thanks for reading and see you next time!
Congratulations to the lucky few who get to read this... Not only have you stumbled upon the first post in what will surely be a very long line of posts describing the process that goes behind creating a video game, but you have also the delight, nay, the honor of reading my first ever blog post in history... Yaaay....
To learn more about Rocket Boy the game, and even play the demo you can visit http://www.seacreaturesandwich.com/rocket-boy.html
The Rocket Boy Dev Blog is where you will find plans for future updates, the processes taken to make those updates a reality, the inevitable problems and pitfalls along the way, and how I go about resolving them to continue moving forward.
That's all for now! It's time to binge watch some guilty pleasure TV with the wife. Until next time you stay classy, The Internet.
EARLY ACCESS WITH ITCH.IO REFINERY
Now available at Itch.io Refinery Early Access!!!