next »

[SolarLune]

++++++++

So the game is done, after a couple of years of work, haha.





You can grab it on itch, and Steam. People who buy it on itch have access to a free Steam key. Here's the links:

https://solarlune.itch.io/gearend
http://store.steampowered.com/app/574500/Gearend/

The OST is also available on Bandcamp:

https://solarlune.bandcamp.com/album/gearend-official-ost

___

If you do buy it and have feedback or bugs to report, please don't post here - post on the game's forums, of course.

Thanks a ton for your help and feedback, everybody.

Original first post below:

++++++++






Hey, there. So, I'm back at it from where I started.

Pictures?









And here's some buttery smooth GFYCat streams!

What is Gearend?

Gearend is a 2D Metroid-like where you control a robot named Epsilon-98, or "Eps", for short. As a helper-purpose robot, its job is to assist humans and aid in household chores. To facilitate this, it has a special body-type that allows it to swap out its parts to deal with the different jobs it might face. It would appear, however, that the Epsilon line was never fully completed. Time passes, and Eps now suddenly awakens, unsure of the year. It now seeks the truth about humanity, facing the traversal of a long-forgotten and out-of-control robotics facility.

What was Gearend?

Gearend was this. It was a lot of things; too dark is one of them, haha. Now, it's been toned up, and I'm mostly redrawing everything from scratch. Some of the music from the original project is either being used or updated, and I'm also mixing in some other songs that I didn't make for Gearend, but that would work well.

When Will It Be Done?

Hoping for the end of July, 2016. Yep, just a few months; I think I should be able to do it. I'm planning stuff out a ton more than last time, that's for sure.

What else?

I'm making it with BDX, a light 3D LibGDX-based game engine that's integrated with Blender. I'm also a developer for the engine, so that increases my comfort with using it, and encourages me to fix whatever issues I come upon while making the game.

Here's some devlog videos, and I've made a lot of progress since then. The goal was to show development from the ground up, though the longer that I wait between devlog videos, the less this is true, so I really need to keep 'em up. The last video was from about a month ago, so I failed on making one per week, haha. Oh well!





Currently, I'm trying to get to use Linux more. I always do this every so often, but Windows' recent "install Windows 10 on your device when you're not looking" tactics are a bit scary. So even though I actually like 10 well enough, I'm gonna try to move over to developing on Linux a bit more.

Lesgo!

[fingerman]

I need pictures!

[SolarLune]

OK!



Here's a pic of Eps talking to an NPC, which is just a cutout. The general idea behind this is that the game takes place in an abandoned robotics facility, so the cutouts were meant to be points at which a human touring the facility could interact with the AI and ask about the area, or just get access to an AI for assistance. The AI is linked to each cutout wirelessly, so it's the same character in all of the places, despite the fact that the cutouts themselves never move. There will be, of course, other kinds of NPCs; this is just one of them.



Like in the original Gearend, the hero robot Eps can wield two weapons at any given time; in this case, it's a melee weapon and a ranged weapon. I still have to get the weapon attacking animations in there, as the weapons are at the "debug" level at the moment, but the mechanics are there.

In addition, today I spent time refactoring the code a bit and got the walking animation in there and animated. I'm now using a hashmap of animation frames to positions that indicates where the arm and core parts should be offset when the legs are moving. This means that when the robot walks, for example, the arms and legs can bob up and down (through code). Otherwise, I'd have to make bobbing animations for those parts, which is a bit unnecessary. Also, when you jump or walk, the arms rise and fall slightly out of sync with the body and legs to make the entire robot feel "heavier".

Recently, I got the grass waving through a vertex shader; attacking near the grass disturbs it, making it flutter. It feels a bit "cheap" right now, but it's a cool effect, nonetheless.

I've been doing lots of enemy design, which is pretty key for a Metroid-like; I have around 11 designed so far, which is a pretty good amount for a Metroid-like, I think. Most of them are new, but a couple are pulled from the original Gearend in one way or another. It's been fun just coming up with some random enemies, but I probably should work on specific, themed enemies (i.e. fire-themed, lightning-themed, whatever). The idea is that each unique zone'll use a couple of the "common" enemies I have so far, and a couple of hazards, enemies, or interactables that are unique to each zone. Hopefully I'll be able to get enemies created and implemented in-game rather quickly!

Anyway, video soon. Thanks for reading!

[fingerman]

Hi Solar, I did some reading up on BDX. Seems to be pretty nice. Cool that you have a planning video, ideal bedtime viewing

[Cristiano Vitorino]

Glad to see you continue this project!

What made you unhappy with your first iteration of the game? What made you restart? Besides the light system. The change in the engine? Not compatible with your previous assets?

I feel ya about Windows 10... I've been wanting to move my dev workspace to Linux for a long time. Next time I upgrade my hardware, I'll see if I can finally move on. With modern CPUs/GPUs and VMs hardware passthroughs, there is no Windows apps that can hold you back anymore haha, no more excuses.

[SolarLune]

Yo, thanks, guys!

I decided to stop development initially because I thought it was too big for me. I spent over a year making it originally, similarly to another project in the past, Valchion. Now, though, I feel like I just needed to plan more (but not too much). I'm not sure what changed between then and now exactly, but I feel more determined to finish it; maybe because I know I can (I've made small games in a small amount of time; I can do bigger games in more time).

Also, the longer I wait to work on it, the longer it'll be before it's done. Nobody'll make this but me.

The engine change also has something to do with it. I made the original Gearend in the BGE, which, while quick enough to use, wasn't quite as performant as it could've been (in my case, anyway). The codebase was also huge. While BDX, on the other hand, doesn't have as many features as the BGE did, it can do more to optimize game projects, runs on Java (which should be faster than Python, usually), and is much more cross-platform-friendly. As a developer for BDX, I also understand it far better than the BGE, and the codebase is tiny, which makes bugfixing fairly simple. And it's pretty easy to use, to boot!
__________

So I've made a lot more progress since the last post!

Here's some of the highlights (so far)!



The shoulder parts moving back and forth in time with the walk cycle. Done in code, of course, so that it'll transfer to other part setups.



I animated the first two arm parts recently; when you use melee attacks, you can strafe backwards. Not sure if I want to give the player this option at all times or not (maybe through a button they can hold down or toggle...?).



The world as it stands currently (incomplete, of course; still gotta make more graphics and stuff).

_____

I've planned out a lot of enemies (which are really a lot of the meat of Metroid-likes) - not really any NPCs yet, but that'll change soon enough!

Something that's not shown in these GIFs is that you can communicate with NPCs, and when you do, the camera zooms in to focus on you both. When you're done, it zooms back out.

Speaking of camera changes, the camera is now locked to specific zones, each at least a screen size large. This'll allow me to do single-room views easily, as well as get a good idea of how the game world is laid out. It should also enable me to actually have a map system that works halfway decently.

[SolarLune]

Here's another development log video post showing some of the stuff that I've changed / improved!





Here's a text dump in case you don't wanna watch!

_________

Apart from new art, cameras now lock to room objects I place in Blender, enabling me to position camera views where I want. Now I can, for example, lock the view to a single area in the game. When the player moves to another location, that room becomes active, and the camera now is fixed to that room. Each room object is exactly the size of the camera view, and if a room object is scaled, then the camera will slide around to the boundaries of the room object.

This room system will be integral to any maps I put in the game, since I can just plot squares and rectangles on a grid in the same setup as I place objects in Blender to represent the game world. Easy-peasy!

I also zoomed in the view a bit to make it easier to design the game world (since you see less, I don't have to create as much) and to just make it simply easier to see the game.

I implemented the animations for the weapons, and added a new rocket launcher weapon. Before I added the launcher, I thought a handheld bomb would be cool, but it didn't really feel fun, so I changed it to a rocket launcher. I really like this a lot more, as there's more I as a developer can do with it. I implemented this same weapon for the first Gearend, too. No reason to mess with success, I guess!

Anyway, sorry for the choppy footage; my HD Game Caster's kinda weirdin' out, so I used OBS for this.

And yeah, I see the small graphical errors here and there (small one-pixel large gaps between tiles, for example); I'll fix them up later.

[SolarLune]

Yo! Here's a quick devlog video showing how I'm approaching AI for Gearend.





The idea is to base everything around tracks that you can turn on or off, and that control which behaviors are being executed at any given time. It's basically lines of Finite State Machines strung together.

Each Track will have only one active Behavior at a time, though you can have as many Tracks as necessary. Each track also will have its own mode (Normal, Choice, etc) and its own controls (for reversing, toggling, clearing, copying, etc). The general idea is to make reusable behaviors simple and easy to use across the different games I make.

[SolarLune]

Yo! Since the last post, I've made a couple of videos!

Here's one on a couple of enemies:





Here's one on a new music track, "A Lost Kingdom":





And here's the latest one on more enemies, the spawning system, and the cinematic / dialogue systems!

https://www.youtube.com/watch?v=J_t7hX5PLwQ

EDIT: Hmm... That last one's just showing up as a link... Oh, well.

[swipefaststudios]

I like the atmosphere of the game and the main character design!
Can't wait to see more!

[SolarLune]

Hey, thanks!

Here's another YouTube devlog video; in the past couple of days since the previous devlog, I've added a GUI for health and energy, and a new leg part for boosting.





Here's a couple of GFYCats if you don't want to load up the video and watch me talk about it.

https://gfycat.com/WiltedMeaslyKilldeer

https://gfycat.com/AcceptableCaringBeauceron

[KaiTheSpy]

You going back and working on Gearend has really got me motivated to make games again. I can't believe how good this looks

[SolarLune]

Hey, thanks a lot! I'm glad that you like how it's shaping up so far.

____

Today and yesterday, I think, I did some work on saving and loading. Saving is accomplished using LibGDX's Preferences system, mainly because there's not really any need to wrap LibGDX's saving processes for BDX - they're already pretty solid and fine for the job. So, we just left 'em alone and point people to use Preferences (or whatever other system), basically.

Any time you get the Preferences instance, LibGDX will create a file for it if it doesn't exist already. So, to check whether data is saved or not, I store an "exists" variable in the preferences file to keep track of if the game data exists. Alternatively, I could check to see if the file itself exists, but I'm a bit too lazy to write that code, and it'd have to change based on which OS the game is running on (as the preferences file is located in different places depending on the OS)... It's just easier to check for an internal variable. If it exists, the game data exists, if it doesn't, then the data doesn't, regardless of what variables are written inside.

Anyway, here's another GFYCat for you! The Save Station Attendant's kind of... Disinterested, is the word? He's not really that, uh, well, attentive, to you. But, well, he gets the job done, so GJ, I guess.

Thanks for reading!

[darkhog]

Nice work! Looks great and protagonist is so cute! Also maybe you could come to my devlog (link in my sig) and share your thoughts?

I hope you will succeed with doing it, it's a really short notice, but I believe you can do it! Also July 27th is my birthday, this game would be a perfect gift .

[SolarLune]

Hey, thanks! I'll check out your devlog.

______

Annnnnd here's a vid!





______

So it's been awhile, but I made a ton of progress between the previous video and this one right above. Here's some notes basically shamelessly copy-pasted from the devlog video description:

- Got a new enemy in, Rainman, who moves back and forth and rains acid down around him. You can only attack him from the back, essentially (explosives might damage on a large enough radius to hit him despite its hit location; not sure).

- Got a quick-select menu up and running. You can use the quick-select menu to quickly select your loadout, adjusting your equipment on the fly.

- Implemented saving and loading and added a saving NPC.

- Starting creating the actual in-game world, as I wanted to actually create the game, making different rooms with different challenges.

- Got a new part in, the Deterrant. As a plasma shield, it blocks against projectile attacks (not explosives, I think). It's not an end-all-be-all against attacks, but should prove useful to help you out.

- Added maximum HP and EP upgrades.

- Up-sized the GUI a bit to be more visible.

- Optimized the game a bit to run a lot better, and fixed a small bug in BDX that was causing seconds-long freezes when transitioning between rooms.

++++

Currently I'm standing at 4/6 arm parts, 1/5 core parts, and 2/5 leg parts (counting Epsilon's defaults).

I plan to be done with somewhere around 1 of the 3 zones by the end of this month. Same thing with the second and third month, though ideally, I'd basically be completely finished by the end of that third month.

We'll see about that, I guess.

Since this last devlog video, I've added another core part. I'm not certain what role it'll play, but I think it'll be a passive defense item, like "Reflects every third projectile hit", or something like that. I've also discovered a bug with the screen shader system I wrote for BDX, and since fixed it.

Progress continues!

[SolarLune]

Hey, so here's a quickie little update. I'm adding gates that you pass through from place to place. They can be locked sometimes if a switch in the same room is triggered, or if enemies are left unbeaten (I'll probably make a variant of this gate for that purpose). This is the default gate, though, which simply opens when you're close enough.



I noticed I don't really have any screenshots for the game here, so I'll try fixing that. Pictured is also a new tile (that's a bit ugly, but suitably "Megaman-like", so whatever).

Also, I've implemented a map system. The current system is pretty basic - everywhere the camera can move in-game is indicated in-engine by Room objects. These objects are sized to a multiple of the screen's size, so a room that has a width of 2.0 means it's two screens wide. Anyway, the map system creates little squares in the GUI scene for each Room object. Each map square is scaled to the size of the corresponding room, and is placed in relation to where the Room objects are in the game scene. Fairly simple, hard to see, kinda crappy, but it works!



Looking at this now, I probably should make the map stand out more by darkening the rest of the screen. I probably should also blur the background layer, similarly to the game layer, but.... Well.

Here's a GFYCat of a new chest part and cloth physics I added because I could. I'm not 100% on what the chest part will do, but I have a general idea.
___

I'm currently working on designing some NPCs for the hub town where you'll get your first melee weapon and the instructions of where to go next.

Anyway, that's all for now!

[ag radley]

looking good. i've been following your vids on youtube for a couple years now haha.

just out of curiosity, how did you approach your vertex shader grass? i tried doing vertex grass for the first time a couple weeks ago and it went okay, but i've been looking around to see how other people do it. it seems like it's actually easier and more straightforward for me to just do it outside the shader with game maker's vertex/polygon drawing functions rather than do it in a shader.

[Codimal]

This game sure looks good! I've been following your videos for quite a while and I can't wait to play this game. Keep it up!

[SolarLune]

Ah, I don't like to answer before I have updates to post, but it's probably for the best that I answer when I get questions, haha. 

@gabev - Thanks a ton!

The vertex shader grass just slides the top row of vertices back and forth using a sine wave. It's done in the vertex shader, which is, with BDX, mapped to the grass material (so all objects that have that same material get drawn with this shader, and have the grass waving effect). If I wanted to draw other vertical objects with the same effect, I could do it by just mapping some other material to a shader using the same "GrassWave.vert" vertex shader file. Fairly simple!

Doing it just using GM's polygon / vertex drawing functions would work fine, too, just like adjusting the mesh vertices manually in a 3D engine. However, doing it this way moves the load from the GPU (applying the effect when rendering the mesh) to the CPU (moving the vertices before rendering the mesh). In both of our cases, we're working with such a small number of objects and vertices that it probably wouldn't really matter either way, but it's something to keep in mind for the future.

@Codimal - Thanks! Hope it'll be awesome!

[SolarLune]

Hey, there! Here's a little devlog talking about the scarf physics, because someone asked about it elsewhere.

____________

The scarf's a port of my old BGE trail code, now working in Java and with BDX. It's done by adjusting the vertices of the scarf to align with a "handle" object. Every frame it adds the rotation and position of the handle object to a list, and after so many frames, it bumps the oldest entry out of the list (so it maintains a list of a maximum of, say, 15 entries). That number is influenced by how long it takes for motion to travel down the trail (which is customize-able). The position of the handle object only matters if the trail stretches (like a Tron Lightcycle trail or something).

Anyway, it steps through each vertex and moves it according to that list, updating the vertex's position based on the location and orientation stored. I guess you could just break it down into two pieces - altering the vertex's position based on the position and orientation of the handle object, and then storing that transformation to apply it later, giving a "late, wave" kind of effect.

If you were to use it, it's available in my BDXHelper module here, on GitHub. You'd put the bdxhelper.jar file in your core/libs folder, next to bdx.jar. Then, you'd create the Trail component and put it on the trail object itself, like so:

Code:

components.add(new Trail(scarf, scarfHandle, "z"));

The first argument is the trail object, in this case, my Scarf object from Blender. The second is the handle object, which is parented to the body part object (and so is parented to the player as well, but the Scarf object itself isn't parented to anything). The last argument is the axis on which the trail vertices are found. My scarf is a plane that heads down (because that's the resting position):



... So the vertices are found on the Z axis, heading out from the center of the object, with the Z value representing vertices on the same "level" (so the two vertices at the top of the scarf object use the most recent listing of the handle object's position and orientation).

After that, I just rotate the handle to face the direction I want (i.e. left when you're heading right, or right when you're heading left), and the scarf automatically updates, smoothly waving in that direction. I also apply a slight random flutter to the handle to simulate wind.

There's different variables in the Trail component that influences the trail's behavior, like whether the trail's movement should be reversed, whether the trail should update only when moving, whether it stretches, etc. There's stuff that it doesn't support (working on multiple materials, for example), but they wouldn't be too hard to add in, if or when I need it.

This is one of those things that I made where I have no idea how I actually managed to do it, since I don't really have a good grasp of matrix math, haha. I just messed around with some stuff until it finally worked. :1

The next devlog video'll talk about this a bit with visuals, I guess. Anyway, thanks!