Support NeoGAF

[IupBundle]

@kingPenguin
You did a really great job on the sound in Super Soccer. I know that doesn't show up in the GIFs, but I thought you nailed it. It's such a simple thing, but the audio is really tight. Great job, and good luck!

I wish I had the pixel art skills of Zotty, those backgrounds are killer.

For any text-based strategy fans, I've been working on a game called Zombie Safe Zone.
In ZSZ you will lead your small team through a crumbling city as you try to save what's left of the city's population. Along the way you will have to manage resources, create safe zones, and complete mission objectives. Devlog is here for anyone who's interested.

• The genre is strategy/tactical/simulation (think Rebuild)
• You control a military squad, or Unit, that moves from building to building within the city(think Urban Dead)
• There are a few basic resources, including supplies, weapons, and survivors (think, the Last Stand)
• The story of the game is progressed mostly through text (Dwarf Fortress)
• Each city is randomly generated with a variety of "zones", each with unique purposes (Sim City)
• It is inevitable that the city will die, you just have to survive long enough to reach your goal (maybe Fallout)
• Each game plays quickly and perma-death is real (of course, Rogue)

 

[Rubikant]

This is why I ignored my co-workers that were all big on vector/surface-based collision systems for 2D games back in my industry days - I understand why its necessary for 3D, but you don't need it for 2D so I avoid it if I have any choice in the matter. I just continued using the old-fashioned tile-based collision systems from the games of yesteryear, where the actors are just pushed out of 'solid' tiles (basically every frame the actors move to wherever they want, then are shoved right back out again of any collision they ended up in, but actor-to-actor collision and of course rendering all happens after the shoving out phase so you can't tell that's what's happening behind the scenes).

That way, worst case scenario, if you do somehow end up inside of collision through a bug, you'll just get shoved right back out again (but possibly end up in a different place than you started at). Its not just the edges of the solid area that are checked like in your typical modern BG collision system, its the entire solid area that's filled with solid tiles, so there's no way to be embedded in collision without the engine knowing about it. Better than being stuck inside the collision boundaries forever though, I say. Only big downside IMHO is that if you want to make some really fancy collision shapes beyond just flat surfaces and tile-even slopes (1/1, 2/1, 3/1 etc) you have to make a bunch of special-case collision tiles in your collision tile set to handle it.

Problem is, these days you probably can't find a tile-based 2D BG collision system for your typical canned game engine, you'd probably have to roll your own (I don't know if this is actually true, maybe there is some engines that still use the older method, but I assume most of them use the vector-based style so that it can be used for both 2D and 3D in the same engine, and to allow complete freedom to make whatever weird-shaped collision you want).

Right. I gave Box2D a shot when GameMaker first implemented it. It seems great for physics-based games like Angry Birds or LittleBigPlanet, but for my own game I'm rolling my own physics and collision handling.

Now that's what I'm talkin' about! (but I understand for many people that may not be an option)

 

[Five]

This is why I ignored my co-workers that were all big on vector/surface-based collision systems for 2D games back in my industry days - I understand why its necessary for 3D, but you don't need it for 2D so I avoid it if I have any choice in the matter. I just continued using the old-fashioned tile-based collision systems from the games of yesteryear, where the actors are just pushed out of 'solid' tiles (basically every frame the actors move to wherever they want, then are shoved right back out again of any collision they ended up in, but actor-to-actor collision and of course rendering all happens after the shoving out phase so you can't tell that's what's happening behind the scenes).

That way, worst case scenario, if you do somehow end up inside of collision through a bug, you'll just get shoved right back out again (but possibly end up in a different place than you started at). Its not just the edges of the solid area that are checked like in your typical modern BG collision system, its the entire solid area that's filled with solid tiles, so there's no way to be embedded in collision without the engine knowing about it. Better than being stuck inside the collision boundaries forever though, I say. Only big downside IMHO is that if you want to make some really fancy collision shapes beyond just flat surfaces and tile-even slopes (1/1, 2/1, 3/1 etc) you have to make a bunch of special-case collision tiles in your collision tile set to handle it.

Problem is, these days you probably can't find a tile-based 2D BG collision system for your typical canned game engine, you'd probably have to roll your own (I don't know if this is actually true, maybe there is some engines that still use the older method, but I assume most of them use the vector-based style so that it can be used for both 2D and 3D in the same engine, and to allow complete freedom to make whatever weird-shaped collision you want).

That's pretty close to what I'm doing, except the collision tiles are technically actors also and I stretch them to fill up as large of a rectilinear region as I can so there are fewer boundary checks.

How would a tile-based system account for moving platforms? For example, I'm imaging this kind of thing hard to accomplish with just tiles, but maybe that's just my naivety on display:

 

[Feep]

How should I handle saving graphical options? There are four save slots...each has save slot specific stuff (like difficulty or controls or aliases or whatever), but graphical options generally remain constant? If I save graphical options per save slot, which do I load on the title screen, before any slot has been chosen? If you set graphical options and then switch to a new, unused save slot, should they reset to default or carry over the other save slot's stuff?

Annoying... = P

Quick I need Durante

 

[Blizzard]

How should I handle saving graphical options? There are four save slots...each has save slot specific stuff (like difficulty or controls or aliases or whatever), but graphical options generally remain constant? If I save graphical options per save slot, which do I load on the title screen, before any slot has been chosen? If you set graphical options and then switch to a new, unused save slot, should they reset to default or carry over the other save slot's stuff?

Annoying... = P

Quick I need Durante

I'm not sure I've ever seen a game with per-save-slot graphical options, but maybe I'm just forgetting some.

 

[Five]

How should I handle saving graphical options? There are four save slots...each has save slot specific stuff (like difficulty or controls or aliases or whatever), but graphical options generally remain constant? If I save graphical options per save slot, which do I load on the title screen, before any slot has been chosen? If you set graphical options and then switch to a new, unused save slot, should they reset to default or carry over the other save slot's stuff?

Annoying... = P

Quick I need Durante

I've not seen this in practice, but I'd assume just load the last-used options a la continue game buttons.

 

[Rubikant]

That's pretty close to what I'm doing, except the collision tiles are technically actors also and I stretch them to fill up as large of a rectilinear region as I can so there are fewer boundary checks.

How would a tile-based system account for moving platforms? For example, I'm imaging this kind of thing hard to accomplish with just tiles, but maybe that's just my naivety on display:

Tiles are only used for static BGs, for moving platforms a different system is used. In the case of our CrazyEngine code, we can flag actors as "solid" and have them "push away" from each other with various options, as well as have a "motion parent" system used in the specific case of moving platforms so that a character on a moving platform sets it as their parent while standing on it and has its motion added to their own. We use this system not only for moving platforms but for things like two characters overlapping each other and pushing each other out to the sides to separate themselves (though that last example was not used in Volgarr) and to have some solid actors be truly "solid" like a breakable block while others, like Volgarr's spear platforms, are "one-way" solid actors (can land on them but also jump up through the bottom of them).

The downside is that solid actors are limited to the collision shapes we allow for actors (usually just rectangles) whereas the static tiles can be pretty much any shape I want to add to the collision tileset (ramps, curves, etc) and the tile collision system is more heavily optimized than the actor push-away system.

Also the tile-based system pushes actors away after the solid actor system is done, which means tiles always take precedence, so even if a solid actor pushes a character directly into a tile wall with its push-away code, the wall would "win" and the character would end up overlapping the pushing object rather than ending up inside the wall (and of course at that point the overlap has to be resolved somehow, depending on what object is doing the pushing, but I find that easier to deal with than characters inside solid walls).

If you want to see how this all works out, try playing Volgarr the Viking, throw a spear into a green skeleton's shield on World 3, jump and stand on the spear, and let the skeleton walk into a wall with you on the spear (and note the inclusion of slopes in this scenario as well).


I suppose one advantage to a vector-based system though (and your technique I'm guessing), would be using the same code for both your static and moving solid collision, for the sake of consistency and because having one system instead of two is probably "safer". I still don't trust vector-based though.

EDIT: I should specify tiles aren't 100% static though, we can do real-time "tile swaps" to turn some collision on and off if we wanted to, we just don't have the tiles actually move. For example, if we did a Super Mario Bros game we'd just blank out any collision tile that represented a brick tile that Mario jumped up and destroyed from below.

 

[Jobbs]

Ghost Song uses the box 2d suite included in stencyl, and while the full advnatages of a real physics system aren't often visible in the game's gameplay, they are occasionally used with things rolling/bouncing around, which has been pretty convenient, with more plans to do a few more physics things.

 

[Five]

Tiles are only used for static BGs, for moving platforms a different system is used. In the case of our CrazyEngine code, we can flag actors as "solid" and have them "push away" from each other with various options, as well as have a "motion parent" system used in the specific case of moving platforms so that a character on a moving platform sets it as their parent while standing on it and has its motion added to their own. We use this system not only for moving platforms but for things like two characters overlapping each other and pushing each other out to the sides to separate themselves (though that last example was not used in Volgarr) and to have some solid actors be truly "solid" like a breakable block while others, like Volgarr's spear platforms, are "one-way" solid actors (can land on them but also jump up through the bottom of them).

The downside is that solid actors are limited to the collision shapes we allow for actors (usually just rectangles) whereas the static tiles can be pretty much any shape I want to add to the collision tileset (ramps, curves, etc) and the tile collision system is more heavily optimized than the actor push-away system.

Also the tile-based system pushes actors away after the solid actor system is done, which means tiles always take precedence, so even if a solid actor pushes a character directly into a tile wall with its push-away code, the wall would "win" and the character would end up overlapping the pushing object rather than ending up inside the wall (and of course at that point the overlap has to be resolved somehow, depending on what object is doing the pushing, but I find that easier to deal with than characters inside solid walls).

If you want to see how this all works out, try playing Volgarr the Viking, throw a spear into a green skeleton's shield on World 3, jump and stand on the spear, and let the skeleton walk into a wall with you on the spear (and note the inclusion of slopes in this scenario as well).


I suppose one advantage to a vector-based system though (and your technique I'm guessing), would be using the same code for both your static and moving solid collision, for the sake of consistency and because having one system instead of two is probably "safer". I still don't trust vector-based though.

Fascinating. As usual, your write-ups are entertaining and educational. It's great to have people like you here!

 

[Rubikant]

Fascinating. As usual, your write-ups are entertaining and educational. It's great to have people like you here!

Heh, thanks! Sometimes I do feel a little awkward, like an old fart trying to blend in with the hip youngsters and all their fancy and scary new gadgets and gizmos (like shaders!). Everyone here seems pretty nice though .

 

[Paz]

How should I handle saving graphical options? There are four save slots...each has save slot specific stuff (like difficulty or controls or aliases or whatever), but graphical options generally remain constant? If I save graphical options per save slot, which do I load on the title screen, before any slot has been chosen? If you set graphical options and then switch to a new, unused save slot, should they reset to default or carry over the other save slot's stuff?

Annoying... = P

Quick I need Durante

We're going with save slots that store player specific game stuff like progression being cloud based while graphics/volume options are stored on the computer, so the decision is kind of made for us in that you only have one set of graphics options that are constant on the device.

If you log in to steam somewhere else it'll retain all your special gameplay settings but you'll need to tell it to run on high etc. Not sure if this is what makes sense for you but it's how I think games should handle this stuff.

 

[Feep]

Sounds good, guys! Makes it easier for me, anyway. Thanks for the help!

 

[Phawx]

@kingPenguin
You did a really great job on the sound in Super Soccer. I know that doesn't show up in the GIFs, but I thought you nailed it. It's such a simple thing, but the audio is really tight. Great job, and good luck!

Agreed. In my LP I was only remarking on how good the sound was, but the camera's slight pan and all of the subtle animation from the bounce to the kicked-up dirt really is fantastic.

 

[Mikado]

According to wikipedia, Unity2D, Construct2, Stencyl, and GameMaker: Studio all use Box2D.

On that note, what open-source, commercial-friendly alternatives are there for physics engines? Brief google searching brings up "Chipmunk" and "Bullet". I wonder if Box2D may actually be a robust engine, but potentially difficult to set up to operate properly.

We use Bullet in our engine. As with most of the physics engines we looked at, Bullet needs a bit of care-and-feeding to get the best performance out of it, but you can't beat the price/licensing/feature set. We've been happy with it.

Granted, we're mostly using it for 3d collision detection rather than actual dynamics simulation. Never tried it for 2d.

 

[Blizzard]

One more cross-thread reminder, the first Handmade Hero livestream just started: http://www.twitch.tv/handmade_hero

This first hour tonight may be mostly about setting up a Windows project and getting it running. But, it and all future videos will be on youtube at https://www.youtube.com/user/handmadeheroarchive.

I'm not affiliated, and I and other people here probably already know a lot of stuff that may be covered, but hopefully this project still has some useful material.

 

[Candescence]

According to wikipedia, Unity2D, Construct2, Stencyl, and GameMaker: Studio all use Box2D.

In the case of Construct 2D, yes and no. Box2D is available, but even though C2 uses polygon collisions for pretty much everything (and is even aware of when a smaller collision polygon is inside a larger one), Box2D physics are an entirely separate behaviour plugin that can only be applied on an object-by-object basis.

In fact, C2 actually has a fairly robust, if basic, platformer behaviour plugin that can easily do common stuff like one-way platforms, multi-jumping, jump sustain, etc. Hell, the whole 'stuck inside terrain' thing you can get in Stencyl and Unity is literally only achievable if the inside of terrain is hollow (as in, no solid tiles, which is not a smart way of doing things), and even if the player somehow gets stuck inside terrain, it's fixed with literally only a single event.

It's pretty much why I prefer C2 for platforming-related 2D stuff, since it's got the most robust existing 2D behaviour that can easily be expanded on via events and isn't reliant on a physics engine. That being said, the main problem with that is that it doesn't play nice with Box2D, meaning anyone who wants a physics-driven platformer will need to roll their own solution entirely via events.

 

[RastaGundam]

Here's the first (well, in two years, anyway) trailer for Narcosis.
A little rough around the edges, but gives a good sense of how far the game's come, and where we're planning to take it.
With the whole team rolling onto the project full-time, we're hoping to share more info in the months to come — questions and comments welcome!

A Taste of Narcosis: https://www.youtube.com/watch?v=XlDXchozGUQ

 

[OccamsBlender]

I just continued using the old-fashioned tile-based collision systems from the games of yesteryear, where the actors are just pushed out of 'solid' tiles (basically every frame the actors move to wherever they want, then are shoved right back out again of any collision they ended up in, but actor-to-actor collision and of course rendering all happens after the shoving out phase so you can't tell that's what's happening behind the scenes).

Embedding collision tile data as meta-data works best IMO. If only Fish Ed was a Unity plugin.
http://scaryfish.tv/fished/fe_main.htm

Physics engines can make very complicated problems easy but they tend to make simple problems insanely complicated.

 

[MrNyarlathotep]

Problem is, these days you probably can't find a tile-based 2D BG collision system for your typical canned game engine, you'd probably have to roll your own (I don't know if this is actually true, maybe there is some engines that still use the older method, but I assume most of them use the vector-based style so that it can be used for both 2D and 3D in the same engine, and to allow complete freedom to make whatever weird-shaped collision you want).

GameMaker definitely has the old school tile based collision included, probably because it's one of the older engines still being used - all of its vector based stuff has been bolted on on top to keep up with the joneses.

I think its standard drag and drop behaviours for generic platform game are all still tile based collisions and translates rather than vector forces and surface properties (although its hard to tell because their drag and drop behaviours aren't ever exposed)

 

[scaffa]

@kingPenguin
You did a really great job on the sound in Super Soccer. I know that doesn't show up in the GIFs, but I thought you nailed it. It's such a simple thing, but the audio is really tight. Great job, and good luck!

I wish I had the pixel art skills of Zotty, those backgrounds are killer.

For any text-based strategy fans, I've been working on a game called Zombie Safe Zone.
In ZSZ you will lead your small team through a crumbling city as you try to save what's left of the city's population. Along the way you will have to manage resources, create safe zones, and complete mission objectives. Devlog is here for anyone who's interested.

• The genre is strategy/tactical/simulation (think Rebuild)
• You control a military squad, or Unit, that moves from building to building within the city(think Urban Dead)
• There are a few basic resources, including supplies, weapons, and survivors (think, the Last Stand)
• The story of the game is progressed mostly through text (Dwarf Fortress)
• Each city is randomly generated with a variety of "zones", each with unique purposes (Sim City)
• It is inevitable that the city will die, you just have to survive long enough to reach your goal (maybe Fallout)
• Each game plays quickly and perma-death is real (of course, Rogue)

Thanks

ZSZ looks great, read some of the thread on tig and seems like a game I would play When do you expect to release the demo, it looks not that far off when looking at the progress bar

 

[Jacksinthe]

Speaking of Box2D, I just wrote pixel-perfect character controller for a friend. He's not that great at code and got all confused with raycast systems and custom physics so I re-rolled STRAFE's collision and physics system using nothing but colliders, triggers and rigidbody physics. Here's a screenshot I took of compiled code showing pixel placement accuracy zoomed in in chop:

What you are looking at is about 50 ish lines of code to make those corners possible. 300+ in all for the basic controller which includes independent air and ground acceleration and deceleration (you can configure accel/decel independently with each state), independent gravity, 100% functional and FAST AS HELL wall stick/jumping, moving platform physics when standing or attached to wall, no wall attaching in ground corners (that's just silly), etc.

My only caveat was that every object (other than Player) had to be in 1 layer. There are no "ground" or "wall" layers, every collision checks against a single layer no matter what your transform is to the object.

I'll say this: it took 3 fucking days. I had to run a million checks based on x and y magnitude, position relative to object, current collider states, transform X scale on specific colliders, etc to get it pixel perfect. Physics can feel tight and old school (game-y, unrealistic) or floaty and light (realistic). All options are editable from the controller's inspector.

I am more of a translate/raycast guy but I'm not too miffed about Box2D or Unity's physics. It just takes a lot of Red Bull to get right. I can post more on this if anyone has any questions, especially newcomers who don't want to be overwhelmed with a bunch of custom raycast/physics script.

 

[SappYoda]

Hello everyone, I just wanted to share with you the project I've been working on in my spare time for a long time.

It's been really hard and there have been some painful and great moment and I'm really happy to have the chance to be able to work with an amazing group of really talented people.

The game is called Outsiders: Countdown to extinction. It's a Augmented Reality turn based strategy game.

We just released our Kickstarter and I'm so nervous :S Please tell us what you think about the game and the campaign :d

You can reach our campaign here.

Thank you.

 

[AcceptableGhost]

This is why I ignored my co-workers that were all big on vector/surface-based collision systems for 2D games back in my industry days - I understand why its necessary for 3D, but you don't need it for 2D so I avoid it if I have any choice in the matter. I just continued using the old-fashioned tile-based collision systems from the games of yesteryear, where the actors are just pushed out of 'solid' tiles (basically every frame the actors move to wherever they want, then are shoved right back out again of any collision they ended up in, but actor-to-actor collision and of course rendering all happens after the shoving out phase so you can't tell that's what's happening behind the scenes).

That way, worst case scenario, if you do somehow end up inside of collision through a bug, you'll just get shoved right back out again (but possibly end up in a different place than you started at). Its not just the edges of the solid area that are checked like in your typical modern BG collision system, its the entire solid area that's filled with solid tiles, so there's no way to be embedded in collision without the engine knowing about it. Better than being stuck inside the collision boundaries forever though, I say. Only big downside IMHO is that if you want to make some really fancy collision shapes beyond just flat surfaces and tile-even slopes (1/1, 2/1, 3/1 etc) you have to make a bunch of special-case collision tiles in your collision tile set to handle it.

This is how I handle collision as well. Works great.

 

[Davision]

I made a turntable scene with Shootmephrenia assets, it shows the concept pretty straightforward or straightforward with ricochets. It also shows the different camera views with the annotations:


https://sketchfab.com/models/7a24f1cb603c4cf6a42911cc44ceb040

 

[Foshy]

Updated the Psyscolr OST playlist! https://soundcloud.com/maumaumusic/sets/psyscrolr-ost-1

by the way, if anyone needs some music...i've got the time for another project now that i'm done with this one

 

[Jacksinthe]

For anyone interested - 60fps jank YouTube:
https://www.youtube.com/watch?v=S_moCHnFoR0

Friend did not want "hangin by a tred" corner collision as shown in my post a few up so I made some corrections to make corners more natural. It was a bit of a trick to get things just right since you need to be able to hit the corner perfect, stand on it, jump, land, etc while triggering being grounded - however - doing so implies you need the perfect width for a ground check so your bool is not set to true/false when its not needed. On walls it would suck since a collision snug to the wall pixel-perfect would flip a ground bool, so I made a few exceptions to scale the size of the ground collider's X based on your LOCAL y magnitude+-. This way you can land a corner and flip the grounded bool to TRUE while when airborne the collider slims a tad to avoid false positives.

Moving platforms is just transform.parent = collision.transform when entering the trigger and on exit, null. Simple.

The last 3rd shows basic accel/decel of various speeds. I chose to take the variable before running code and dividing it by the maximum speed so

airAccel /= maxSpeed;

This way you can call it "acceleration" - the higher the number, the greater the acceleration. If you want to "dampening" instead you would maxSpeed /= airAccel and the greater the number the slower the acceleration.

You can watch the inspector on the right to see my bool/state checks. Most are private but made public for visual clarity in the video.

Again, using nothing but rigidbodies, standard colliders and Unity physics (except for accel/decel, there is zero friction or drag involved per my physics2D material). I still prefer rolling my own physics and using raycasts for custom collision detection, but i see nothing wrong with this. As long as you do your proper checks to make sure colliders do not enter other colliders and if so, MOVE THAT SHIT OUT (as Rubikant stated), it is perfectly fine.

I think he should be happy with this as a starting point to dissect the code and model rigging. Has a lot of important comments on use of rigidbodies, colliders, triggers, childing/parenting, etc. All great places to get started with Unity and understanding the basics, IMO.

Anything else you folks think I should throw his way? Or does that sound like a good foundation for basic movement, collision, etc?

 

[donut]

Updated the Psyscolr OST playlist! https://soundcloud.com/maumaumusic/sets/psyscrolr-ost-1

Summer feeling, man that's relaxing song. Sweet stuff!

Menu for Rova's Adventure

 

[superNESjoe]

GunWorld is out the door ($4.99 at our website) so we're shifting focus over to our second project. It's a co-operative/competitive game that can be played with 1-4 players. It has a variety of different game modes, but the headlining feature pits 3 players against 1 very powerful wizard.

We're deep into prototyping, and will be doing weekly development/playtesting live streams to get feedback. We've teamed up with a local comic shop to host weekly playtesting sessions too. Pretty excited about this one.

 

[Sadsic]

Updated the Psyscolr OST playlist! https://soundcloud.com/maumaumusic/sets/psyscrolr-ost-1

by the way, if anyone needs some music...i've got the time for another project now that i'm done with this one

i like these sounds

 

[Ashodin]

We got our psyscrolr code! It's time to lotcheck, then release ASAP!

 

[Jobbs]

We got our psyscrolr code! It's time to lotcheck, then release ASAP!

christ.

 

[Ashodin]

christ.

We almost thereeeeeeeee

 

[Foshy]

i like these sounds

Whoa, that's a really big compliment coming from you! I love your music

We got our psyscrolr code! It's time to lotcheck, then release ASAP!

aww yiss

 

[IupBundle]

Thanks

ZSZ looks great, read some of the thread on tig and seems like a game I would play When do you expect to release the demo, it looks not that far off when looking at the progress bar

Thank you Zotty, that really is appreciated. It is definitely a niche kind of game (not for everyone), but the march towards the demo is going quick. The goal is to put out a stable build after the major stuff is in there. It's my hope that people like you can let me know what's fun and what doesn't work as I continue to develop the game. It could be as early as the end of this weekend if I don't fall into that indie dev rut (comments like yours help in a big way though!).

@Foshy: The main theme of Psyscrolr, The Journey Begins, really starts strong. Great OST and some good beats!

 

[Ashodin]

psyscrolr submittttttttedtotlootchekcco OMG ITS HABBEDING

 

[TheHollowNight]

I've been making some music of my own! This is probably going to be the main theme in the Beacon menu screen. It's very Blood Dragon inspired and hopefully gets people pumped to jump into the game

https://soundcloud.com/axionmusic/beacon-menu

 

[Ito]

Good job GAF and specially Ashodin, you succeeded one more time at making me feel the slowest dev ever.

 

[Jobbs]

psyscrolr submittttttttedtotlootchekcco OMG ITS HABBEDING

I'll buy it no matter what because I always buy the games of indies I know, but if it sucks I'll get my revenge

 

[IupBundle]

I've been making some music of my own! This is probably going to be the main theme in the Beacon menu screen. It's very Blood Dragon inspired and hopefully gets people pumped to jump into the game

https://soundcloud.com/axionmusic/beacon-menu

UHHHHM THAT"S KILLLER.

What "sound/instrument/blip?" is that initial base sound? It sounds like Abducted by Sharks first tracks. Love it and want it for game!

 

[TheHollowNight]

UHHHHM THAT"S KILLLER.

What "sound/instrument/blip?" is that initial base sound? It sounds like Abducted by Sharks first tracks. Love it and want it for game!

Thanks!
The main synth bass line is a combination of these two VSTi's:

I never use the default settings mind you. But practically all the instruments I use are free plugins from CM magazine or on the web.
The two main instruments for melodies I use are SQ8L (which is the main bell melody in this track) and Alchemy.

Here's another in-game track I'm working on at the moment (soundcloud horribly compressed this one):
https://soundcloud.com/axionmusic/beacon-ost

 

[cbox]

psyscrolr submittttttttedtotlootchekcco OMG ITS HABBEDING

NICE!

Been blendering! Creating a family of ( so far ) low poly animals for a new project.

 

[IupBundle]

@TheHollowNight: That looks like voodoo magic to me (that's a complement).

The link doesn't work!!

 

[TheHollowNight]

@TheHollowNight: That looks like voodoo magic to me (that's a complement).

The link doesn't work!!

Haha. I would say this is one of my more simple tracks. I usually go a bit more crazy with my other music. I love bass lines that go all over the place. This is sort of how layered most of my songs end up:

Oh I know why the link didn't work (had the track set to private).
Try again now!

 

[Raonak]

NICE!

Been blendering! Creating a family of ( so far ) low poly animals for a new project.

Wow. I'm impressed how good low poly looks when done right.

 

[Ito]

Hey, Americana Dawn Kickstarter is live. These guys really deserve those 70K $ they're asking for, so let's help them, shall we?

https://www.kickstarter.com/projects/bitbonton/americana-dawn-historical-rpg

I love Suikoden II so needless to say this one has me really interested.

Spoiler

Downside... they made it to Kickstarter way before than me

 

[Feep]

Ashodin getting out a game in like four (?) months is absurd.

ABSURD

 

[Dr. Benton Quest]

Hey, Americana Dawn Kickstarter is live. These guys really deserve those 70K $ they're asking for, so let's help them, shall we?

https://www.kickstarter.com/projects/bitbonton/americana-dawn-historical-rpg

I love Suikoden II so needless to say this one has me really interested.

Spoiler

Downside... they made it to Kickstarter way before than me

What an excellent idea. Backed.

 

[Diablohead]

3+ years and I still test my game inside a mock up test zone, lol.

 

[Mystic River]

Ashodin getting out a game in like four (?) months is absurd.

ABSURD

4 months!!!!

that means I procrastinate too much! one year and a half now and still may go for a few months before I get pre-beta version ready...

 

[Ranger X]

3+ years and I still test my game inside a mock up test zone, lol.

LOL. Basically the same thing with me. Wait, I have 2 zones completed now in my game. Tutorial and then the first area.