Support NeoGAF

[upandaway]

Is it okay to ask here programming questions (in terms of game design/logic, not really programming itself)?

 

[MikeHaggar]

Is it okay to ask here programming questions (in terms of game design/logic, not really programming itself)?

yep! ask away

 

[upandaway]

Aight~

I'm trying to write my first thing in Java and.. at first I thought to just write a different class for every entity type (like different enemies) in a hierarchy, but I'm thinking maybe it'll be better to create an enum as a singleton that has all the different types inside it, with their attributes and all that, and then create one class that has all the AI and logic and uses the enum to decide what it is. I guess I'm just trying to avoid having a huge hierarchy of a million classes for the entity types.

How is this usually done, is there a different way to go about this?

 

[MikeHaggar]

Aight~

I'm trying to write my first thing in Java and.. at first I thought to just write a different class for every entity type (like different enemies) in a hierarchy, but I'm thinking maybe it'll be better to create an enum as a singleton that has all the different types inside it, with their attributes and all that, and then create one class that has all the AI and logic and uses the enum to decide what it is. I guess I'm just trying to avoid having a huge hierarchy of a million classes for the entity types.

How is this usually done, is there a different way to go about this?

there's no "right" way to do it. try to design it in a way that is going to make sure your code is easily managable. if it were me, i would have a base class "enemy" and use inheritance for each of the specific enemy types. i would also include specific ai routines inside of the child classes instead of trying to include the ai routine for each enemy inside of a single class as i think that would be less managable. finally, i would implement an "enemy manager" type of class that is responsible for keeping track of and calling update/draw on all of the active enemies.

ultimately, just do what feels right to you. what i've suggested above is what makes sense to me. if what you are thinking feels right then go with that. if there is a better way to do things you will probably realize it at some point during development. at that point it is a learning experience and you can better implement the feature in your next game!

 

[JulianImp]

Aight~

I'm trying to write my first thing in Java and.. at first I thought to just write a different class for every entity type (like different enemies) in a hierarchy, but I'm thinking maybe it'll be better to create an enum as a singleton that has all the different types inside it, with their attributes and all that, and then create one class that has all the AI and logic and uses the enum to decide what it is. I guess I'm just trying to avoid having a huge hierarchy of a million classes for the entity types.

How is this usually done, is there a different way to go about this?

Using Enums is a very monolithic way to do things, which could work for a very simple game, but will get things way, way too cluttered otherwise. Luckily, there're many ways to go around that. One such model is the MVC one, which stands for Model, View, Controller: Say, you could have a "character" model with its attributes and abilities (move, walk, jump, attack, etc.), a separate view that renders itself, and a controller, which is what interacts with the model and calls its routines.

By splitting models and controllers, you could actually have the player, enemies and bosses all use the same model, only with different controllers (one of them takes keyboard input to call the model's methods, while the other two use state machines instead). The view doesn't just mean the object's sprite, but any other things that are drawn for it, such as a health bars, damage numbers, shield effects and so on.

If you want to keep all three things in a single class, you should at least use inheritance: Say, making an "Enemy" class with HP and basic abilities, and set them to new values or override methods for enemy sub-types. That way, you don't have to write the same basic code over and over for each and every kind of enemy.

If you want to to Object-Oriented Programming, the idea is that you make small-ish objects that each have a few functions limited in scope, so that you can combine and reuse them rather than write large classes that are harder to maintain and modifiy, and you can also resort to inheritance to reuse code (as child classes inherit all non-private properties and methods of its parent class and/or interfaces), and polymorphism, which takes advantage of the fact that child classes keep their parent's methods and properties to access them (say, both a tank and a combat airplane could have "shoot" and "move" methods inherited from their parent "war vehicle" class, which means you could call WarVehicle.Shoot() or WarVehicle.Move() and have it work regardless of whether it's a tank or a combat airplane, since you know both of them have those functions).

I only know about OOP from experience, and not from reading theory about it, so I might be wrong about some of these things. Still, I think the explanation is valid for the most part.

 

[show me your skeleton]

so fmod, an audio development studio, is now free for indies.

 

[upandaway]

Using Enums is a very monolithic way to do things, which could work for a very simple game, but will get things way, way too cluttered otherwise. Luckily, there're many ways to go around that. One such model is the MVC one, which stands for Model, View, Controller: Say, you could have a "character" model with its attributes and abilities (move, walk, jump, attack, etc.), a separate view that renders itself, and a controller, which is what interacts with the model and calls its routines.

By splitting models and controllers, you could actually have the player, enemies and bosses all use the same model, only with different controllers (one of them takes keyboard input to call the model's methods, while the other two use state machines instead). The view doesn't just mean the object's sprite, but any other things that are drawn for it, such as a health bars, damage numbers, shield effects and so on.

If you want to keep all three things in a single class, you should at least use inheritance: Say, making an "Enemy" class with HP and basic abilities, and set them to new values or override methods for enemy sub-types. That way, you don't have to write the same basic code over and over for each and every kind of enemy.

If you want to to Object-Oriented Programming, the idea is that you make small-ish objects that each have a few functions limited in scope, so that you can combine and reuse them rather than write large classes that are harder to maintain and modifiy, and you can also resort to inheritance to reuse code (as child classes inherit all non-private properties and methods of its parent class and/or interfaces), and polymorphism, which takes advantage of the fact that child classes keep their parent's methods and properties to access them (say, both a tank and a combat airplane could have "shoot" and "move" methods inherited from their parent "war vehicle" class, which means you could call WarVehicle.Shoot() or WarVehicle.Move() and have it work regardless of whether it's a tank or a combat airplane, since you know both of them have those functions).

I only know about OOP from experience, and not from reading theory about it, so I might be wrong about some of these things. Still, I think the explanation is valid for the most part.

Yeah I'm using MVC. I haven't really done anything yet but here's the git (mostly empty classes, but the general structure is there).
Considering I'm unit testing, I want to use less inheritance and more Composition and Inversion of Control (with lots of interfaces), and only really use enums as hard-coded singletons rather than actual enums, but I get what you mean to keep classes small. It'll make it a bit easier to change stuff later.

Guess I'll look into a class for every entity after all, dunno how I'll handle AI but oh well, it's a ways off.

 

[JulianImp]

Yeah I'm using MVC. I haven't really done anything yet but here's the git (mostly empty classes, but the general structure is there).
Considering I'm unit testing, I want to use less inheritance and more Composition and Inversion of Control (with lots of interfaces), and only really use enums as hard-coded singletons rather than actual enums, but I get what you mean to keep classes small. It'll make it a bit easier to change stuff later.

Guess I'll look into a class for every entity after all, dunno how I'll handle AI but oh well, it's a ways off.

I'd say AI is simple if you build state machines for their controllers. State machines aren't that hard to build unless your project requires extremely complicated ones, and they work nicely and intuitively for the most part.

Also, I'd say that enums are always cleaner than constants since they limit the kinds of data that can be put into them. You can also assign values to each enum, but that's a bit too hack-y for my taste.

 

[Mr. Virus]

so fmod, an audio development studio, is now free for indies.

I don't think that's the right term for it. FMOD is audio middleware, which allows people (especially actual sound guys) to set up complex events and sound cues, complete with variable states, without having to type a line of code. It isn't a "development studio" in the way that Pro Tools/Ableton/Cubase/etc. is, although FMOD studio has had a visual overhaul to make it a bit more friendly to people using them.

They've also announced their plugin for Unity as well, which is a hell of a boon to anyne who's had to use Unity's audio engine beyond dropping noises in.

If anyone's interested then it may be worth looking up Stephan Schütze's video series on Youtube to see what it can do (like this engine example in Designer, Studio's predecessor)

(Sorry, nitpicky audio dude. Not meaning to be a snarky arse!)

 

[Wyndstryker]

so fmod, an audio development studio, is now free for indies.

edit due to above post:

Well...I guess i'll be still looking into FL Studio.

 

[show me your skeleton]

I don't think that's the right term for it. FMOD is audio middleware, which allows people (especially actual sound guys) to set up complex events and sound cues, complete with variable states, without having to type a line of code. It isn't a "development studio" in the way that Pro Tools/Ableton/Cubase/etc. is, although FMOD studio has had a visual overhaul to make it a bit more friendly to people using them.

They've also announced their plugin for Unity as well, which is a hell of a boon to anyne who's had to use Unity's audio engine beyond dropping noises in.

If anyone's interested then it may be worth looking up Stephan Schütze's video series on Youtube to see what it can do (like this engine example in Designer, Studio's predecessor)

(Sorry, nitpicky audio dude. Not meaning to be a snarky arse!)

no, this is perfect. i am an audio guy myself, strictly composer at the moment, and my lack of product knowledge about fmod and a general rush to get this up here meant my post was way off.
thank you for the clarification and information. now i'm off to learn fmod and make myself hireable!

 

[Mr. Virus]

no, this is perfect. i am an audio guy myself, strictly composer at the moment, and my lack of product knowledge about fmod and a general rush to get this up here meant my post was way off.
thank you for the clarification and information. now i'm off to learn fmod and make myself hireable!

Ah, that's good then !

The music system is worth a look in that case. I know they've tweaked it in Studio but haven't been able to use it in that yet. Takes a bit to get your head round ha ha.

 

[-Pyromaniac-]

I'm playing around with Unity out of mostly boredom. I want to try making something really simple for the lulz but I've learned a lot by just listening to podcasts, doing youtube training videos and all that.

I have one question though and I figure this is a good place to ask. I found a great tutorial online for a 2D platformer, I've been following it but I want to deviate from it a bit but am stuck. I want the character to always be running forward. By default you have to press the running button while holding the right arrow key. Now I figured out how to make him move forward on its own but the running animation doesn't play. It just moves forward while the legs stay, like he's hovering.

How can I get him to run the whole time? I'll provide any info anyone needs if you can help If not it's coooooool.

 

[JulianImp]

I'm playing around with Unity out of mostly boredom. I want to try making something really simple for the lulz but I've learned a lot by just listening to podcasts, doing youtube training videos and all that.

I have one question though and I figure this is a good place to ask. I found a great tutorial online for a 2D platformer, I've been following it but I want to deviate from it a bit but am stuck. I want the character to always be running forward. By default you have to press the running button while holding the right arrow key. Now I figured out how to make him move forward on its own but the running animation doesn't play. It just moves forward while the legs stay, like he's hovering.

How can I get him to run the whole time? I'll provide any info anyone needs if you can help If not it's coooooool.

It depends on what animation system you're using and how you're managing animation changes.

Basically, you'd make the character's "Idle" state use the running animation (if you're using Mecanim) or just assign a looping animation of the character running around, and swap it with a jump animation whenever the player jumps if you're using the old animation system.

Since you said the character automatically uses the running animation when the right key is pressed, it means that whichever example you're using has set the mecanim animation system (or whatever is used) up to work that way, since Unity doesn't do so by default.

 

[Makai]

Dang.

http://mathworld.wolfram.com/Cumulation.html

Constructing those in code was not straight-forward at all. Took me the whole day.

 

[electroflame]

so fmod, an audio development studio, is now free for indies.

Nice. FMOD Studio looks a lot like XACT (except better, I think), which was one of the things I was really missing moving from XNA to Unity. I've no idea how well it works, though, since I'm not even to the point in a project where I'd need sophisticated sound.

However, SoundBanks are (to me at least) far superior to having tons of loose audio files in your project -- especially where you can manage individual cue volume and stuff outside of code. I'd highly recommend trying a SoundBank method if you guys have tons of loose audio clips in your projects -- I don't think I can go back to the alternative now (feels...archaic).

 

[Feep]

Dang.

http://mathworld.wolfram.com/Cumulation.html

Constructing those in code was not straight-forward at all. Took me the whole day.

New point h = averageOfAllFaceVertexPositions + normalVectorOfFace * h? Then connect it to all the vertices?

Yeah I can see why it would suck, though. = P

 

[Makai]

New point h = averageOfAllFaceVertexPositions + normalVectorOfFace * h? Then connect it to all the vertices?

Yeah I can see why it would suck, though. = P

Yeah, I've had functional stellation for a while, but it was never accurate enough. Using trig to get the distance of the stellated points away from the origin would be a few degrees off and it'd be really ugly. Strange that tiny inaccuracies would be so noticeable.

Then today I found that page and I knew I could get the solution out of it with enough knuckle grease. The problem here was that h is relative to edge length, but they forget to tell me that. Unless I missed it, of course. I read it a few times. Maybe it's a convention and they assumed the geometer reading would have already known. I assumed h was relative to the insphere radius or something because they refer to unit [polyhedron]. I thought the term would be parallel to unit circle/sphere.

 

[Heart of Black]

I wonder at times, should we split this thread between showing off your stuff, and asking for help with code and the like? It runs into some spells where it's barely readable for me, just because it dives so deep in one direction or the other.

 

[Blizzard]

I wonder at times, should we split this thread between showing off your stuff, and asking for help with code and the like? It runs into some spells where it's barely readable for me, just because it dives so deep in one direction or the other.

Personally, I like seeing both kinds. If split I think you might have the following problems:

• Neither thread gets much visibility, since right now this thread is popular but not TOO popular.
• There is already a dedicated "programming help" thread in the OT forum.
• The "show your stuff" thread might get old after a while, plus it might run into the problem of whether people are allowed to promote their projects or not. I feel like there is a fine line, since people are allowed to talk about their projects, and respond if someone else creates a thread for their game, but not allowed (I think) to create a thread for their own game. And of course someone could be sneaky and ask someone else to make a thread for their game, but you're presumably not supposed to do that either.

Probably minor problems, but I guess I just don't think it's really necessary, and the mix keeps things interesting.

 

[-Pyromaniac-]

It depends on what animation system you're using and how you're managing animation changes.

Basically, you'd make the character's "Idle" state use the running animation (if you're using Mecanim) or just assign a looping animation of the character running around, and swap it with a jump animation whenever the player jumps if you're using the old animation system.

Since you said the character automatically uses the running animation when the right key is pressed, it means that whichever example you're using has set the mecanim animation system (or whatever is used) up to work that way, since Unity doesn't do so by default.

Oh my god you're my hero. Yes it's using mechanim. I've been racking my brain for this for 2 days now and have been googling like crazy and never once did it occur to me to just switch Idle and Run around in the animator. I've been avoiding nagging you guys here with questions but this one I just couldn't solve so thank you.

 

[Wyndstryker]

Spent a week overhauling the collision because gamemaker is just horrible at collision. Now that I got it pixel perfect I can finally pull stuff like this off smoothly

 

[Heart of Black]

Personally, I like seeing both kinds. If split I think you might have the following problems:

• Neither thread gets much visibility, since right now this thread is popular but not TOO popular.
• There is already a dedicated "programming help" thread in the OT forum.
• The "show your stuff" thread might get old after a while, plus it might run into the problem of whether people are allowed to promote their projects or not. I feel like there is a fine line, since people are allowed to talk about their projects, and respond if someone else creates a thread for their game, but not allowed (I think) to create a thread for their own game. And of course someone could be sneaky and ask someone else to make a thread for their game, but you're presumably not supposed to do that either.

Probably minor problems, but I guess I just don't think it's really necessary, and the mix keeps things interesting.

I feel you. It's just like I swear I lose conversations all the time because a programming conversation pops up, or I don't think I should break up one. Dunno.

I posted about 30 minutes of gameplay a week or so back on my kickstarter page, but figured I might as well throw it here.

It's at a weird res because I'm building my game in the Playstation Mobile SDK, but we're moving onto Unity full time soon.

I also posted a bunch of stuff like this river background as well.

My kickstarter has become a repository for all of my art these days.

 

[Blizzard]

I actually made most of the progress I wanted to make by the end of the weekend, and am finally working on very basic real-game stuff. This is going to look super amateur-ish, but it really is satisfying when even a very basic editor you've made yourself starts being useful and letting you DO things with it instead of just work ON it.

I'm working on a turn-based strategy game. Any graphics for now are super placeholder, but suggestions are still welcome. Plus, any sort of mode suggestions or questions are welcome from the menu standpoint, though I'm not getting into the details of gameplay yet.

My current idea is for the singleplayer and multiplayer buttons to display the second menus shown above, and for each of those buttons to cause some graphics and text to appear that describes the mode in question, plus buttons to select New/Continue/Host/Connect/Play by Email or whatever other options are appropriate for a particular mode.

 

[Prophet Steve]

I actually made most of the progress I wanted to make by the end of the weekend, and am finally working on very basic real-game stuff. This is going to look super amateur-ish, but it really is satisfying when even a very basic editor you've made yourself starts being useful and letting you DO things with it instead of just work ON it.



I'm working on a turn-based strategy game. Any graphics for now are super placeholder, but suggestions are still welcome. Plus, any sort of mode suggestions or questions are welcome from the menu standpoint, though I'm not getting into the details of gameplay yet.

My current idea is for the singleplayer and multiplayer buttons to display the second menus shown above, and for each of those buttons to cause some graphics and text to appear that describes the mode in question, plus buttons to select New/Continue/Host/Connect/Play by Email or whatever other options are appropriate for a particular mode.

I'd say there are too many options at the start. Armies and Maps are a bit unclear. Normally you should probably place credits under options, but credits is always a bit of a weird one.

The difference between match and battle is unclear to me.

On the visual aspect I can't really comment. Just try to make it feel a bit integrated into the game. You could pay attention to golden ratios and other things, and they will definitely improve an UI, but I cannot help too much with that.

 

[Bollocks]

So who here is attending GDC?
I'll be there, first time.
Should we organize a meetup?

 

[Sycle]

So who here is attending GDC?
I'll be there, first time.
Should we organize a meetup?

Paz and I will be there (it'll be our first time going to GDC too!) We were offered the opportunity to show Assault Android Cactus at the Unity booth and at the Indie Megabooth!

In fact I've been flat out working on stuff for GDC and hardly had any time to add new things to the game, although I managed to get the next boss character intro animation done when nobody was looking

he's a big guy!

 

[Mr. Virus]

Nice. FMOD Studio looks a lot like XACT (except better, I think), which was one of the things I was really missing moving from XNA to Unity. I've no idea how well it works, though, since I'm not even to the point in a project where I'd need sophisticated sound.

However, SoundBanks are (to me at least) far superior to having tons of loose audio files in your project -- especially where you can manage individual cue volume and stuff outside of code. I'd highly recommend trying a SoundBank method if you guys have tons of loose audio clips in your projects -- I don't think I can go back to the alternative now (feels...archaic).

FMOD lets you create something similar to sound banks called "Sound Defs", which you can then use in different events .

I also agree with you re: XACT over Unity's standard thing. Even if it was a bit clunky you could do a lot more with it.

So who here is attending GDC?
I'll be there, first time.
Should we organize a meetup?

Should be floating around as another first timer ! Will be at stand 1238 with a load of other Scottish devs .

 

[upandaway]

I'd say AI is simple if you build state machines for their controllers. State machines aren't that hard to build unless your project requires extremely complicated ones, and they work nicely and intuitively for the most part.

Also, I'd say that enums are always cleaner than constants since they limit the kinds of data that can be put into them. You can also assign values to each enum, but that's a bit too hack-y for my taste.

Didn't know what state machines are so I looked it up, seems like I'll need to read for a while before I continue coding. The more I think about not using that the more messy everything seems, haha.

 

[Jack_AG]

Didn't know what state machines are so I looked it up, seems like I'll need to read for a while before I continue coding. The more I think about not using that the more messy everything seems, haha.

Everything is a state machine. No, seriously. One element does not make it more or less of a finite state machine depending on application. Some people consider this a philosophical argument but I take it as a fact since every program is a representation of the current state depending on user input (or not, in some cases). Dont let the technical mumbo jumbo trick you into thinking they are more than they are. Player controller, AI, physics, audio systems, etc - all state machines. An entire game - a state machine.

Dont be scared by the term since it technically means absolutely nothing special. Its just logic and rules. Nothing more.

 

[excowboy]

Good thing you got a refund. UnrealScript is discontinued in UE4 in favor of C++ (At least that's what they said when they demo'ed it 2 yearsh ago, been looking forward to it ever since.)

Oh dear! Still, I'm literally giving this book away if anyone can make use of it! It's just sitting on my desk at the moment and I'd rather someone get something out of it. Quoting myself again for reference - free UDK book if anyone would like it:

Hi all, does anyone here use Unreal, or would like to learn UDK/UnrealScript? I'm not really any kind of developer as yet, but trying to get into Unity and as such my wife bought me a book at Christmas - except she bought me an Unreal book!

http://www.packtpub.com/unreal-development-kit-game-programming-with-unrealscript-beginners-guide/book

I got a full refund from PACKT due to the error, but they don't have a returns process so told me I could keep the book! It's £30.99 new, but if anyone is interested please PM me and you can have it for the price of postage, or probably even free if you're in the UK

This'll be the last time - apologies if anyone is finding this spammy.

 

[Five]

Didn't know what state machines are so I looked it up, seems like I'll need to read for a while before I continue coding. The more I think about not using that the more messy everything seems, haha.

Just don't over-complicate it. Think of it as a way to partition the thinking and programming into discrete sections that make sense, split up by if-statements or similar. For example, with a simple bot that just walks back and forth until in shooting range, maybe you give it the two potential states PATROL and ATTACK. If PATROL, walk back and forth and keep an eye out for targets. If ATTACK, aim and shoot and know when to quit.

More complicated enemies get the same basic underlying principles but just scaled up with more states and more conditions for jumping from one to another.


I've been spending the last couple weeks working on mobs and mooks myself for my game. It's been interesting trying to find a balance between the simple hop-n-bop of something like Mario or Spelunky and the more technical of something like Dark Souls or Nidhogg. Really, the more important goal is to have a variety of munchkins who complement the player move set in differing ways, but it helps to have an idea of what you're trying to achieve.

 

[upandaway]

Everything is a state machine. No, seriously. One element does not make it more or less of a finite state machine depending on application. Some people consider this a philosophical argument but I take it as a fact since every program is a representation of the current state depending on user input (or not, in some cases). Dont let the technical mumbo jumbo trick you into thinking they are more than they are. Player controller, AI, physics, audio systems, etc - all state machines. An entire game - a state machine.

Dont be scared by the term since it technically means absolutely nothing special. Its just logic and rules. Nothing more.

Yeah I know, technically I was doing the same thing when I made a simple Pacman thing, it's just that I had it all spread out between the update() and some methods inside the enemy object, it makes a lot more sense to keep it in one organized place (it establishes some rules too). But I do want to read about the "standards" so I don't mess up again like not knowing about state machines to begin with.
I was also slow to realize we did a lot of those in high school, just in a different context, so I know a bit about how to build the diagrams even if they're complicated.

 

[Tash]

So who here is attending GDC?
I'll be there, first time.
Should we organize a meetup?

We'll be at GDC Play showing Shiftlings Come say hi!

Paz and I will be there (it'll be our first time going to GDC too!) We were offered the opportunity to show Assault Android Cactus at the Unity booth and at the Indie Megabooth!

In fact I've been flat out working on stuff for GDC and hardly had any time to add new things to the game, although I managed to get the next boss character intro animation done when nobody was looking

he's a big guy!

Woo, I'll get to hug Paz again and that boss looks awesome.

Been working our butts of for a completely new build and since FMod was mentioned: Been working with that too. It's a bit of a pita for VO scripts but it's coming along:

VO Trailer stuff

 

[Mr. Virus]

Given that the FMOD for indies happened yesterday Wwise have pushed out their play: https://www.audiokinetic.com/about/...ces-indie-focused-limited-commercial-license/

Free for projects under 200 sound files, which IMO is pretty much nothing but'll be okay for smaller projects.

Also worth bearing in mind that while both now have Unity plugins neither have Linux support.

 

[MikeHaggar]

Everything is a state machine. No, seriously. One element does not make it more or less of a finite state machine depending on application. Some people consider this a philosophical argument but I take it as a fact since every program is a representation of the current state depending on user input (or not, in some cases). Dont let the technical mumbo jumbo trick you into thinking they are more than they are. Player controller, AI, physics, audio systems, etc - all state machines. An entire game - a state machine.

Dont be scared by the term since it technically means absolutely nothing special. Its just logic and rules. Nothing more.

good advice here. i agree 100%. when i realized a game is just a giant state machine it all clicked for me and made building a 2d engine from scratch very easy for me.

 

[GulAtiCa]

Damn those game breaking bugs!

Found out there was a pretty big one with the co-op feature of the game (Wii U ZaciSa's Last Stand). If someone used the co-op feature (control a drone object with a wiimote (upto 4 drones can be controlled)) and restarted the game (via restart by menu or by gameover screen) and tried to use that Wiimote again, it will crash the system. This was because when the game was reset, I forgot to have all info cleared about which Wiimote Controller controlled which drone. So the game still bought Wiimote #1 still had control of a object that no longer exists. So it crashes the game.

It's since been fixed and resubmitted it to lotcheck. Now probably aiming for late March release.

 

[LSauchelli]

This makes me think of how bosses in 3D Zelda are presented. Really badass.

 

[Heart of Black]

I'll be at GDC. I'm speaking on the Indie Soapbox and on the Games Career Summit. Will be demoing Treachery in Beatdown City guerilla style.

 

[Lihwem]

Hey !

Is it possible to post a link to a Kickstarter project in which I am involved as a sound designer or is it too "auto-promo" ?

 

[Blizzard]

I'd say there are too many options at the start. Armies and Maps are a bit unclear. Normally you should probably place credits under options, but credits is always a bit of a weird one.

The difference between match and battle is unclear to me.

Thanks! You're probably right, I'll move credits under options.

Armies and Maps involve user-edited content, as opposed to playing the game. Not sure if there's a better way to categorize that, though if you click one the resulting screen should then provide information that makes it obvious what's going on.

I do probably need better terms for stuff like "match" and "battle" -- my plan is that in the context of my game, a normal match would be 3-5 battles, and majority wins the match. A single battle option is just for people who want a really quick game and don't necessarily care about balance over multiple battles. At minimum the plan is for another part of the main menu to change to graphics and text which describe each mode as you click on it (Co-op Campaign, or Battle, or whatever), so you can then click something else if the mode wasn't what you thought it would be. However, there are probably also better phrasings or organizations I could use.

I also didn't think to put a tutorial option under singleplayer. I definitely want to do that.

 

[JulianImp]

Didn't know what state machines are so I looked it up, seems like I'll need to read for a while before I continue coding. The more I think about not using that the more messy everything seems, haha.

If you're into AI programming, one of my teachers used to reference a book named "Programming Game AI by Example" for different kinds of AI behaviors (we only learned some basic flocking stuff with him, though).

State machines are a fine way of representing patterns for AIs, since you can make discreet states (ie: patrolling, pursuing, engaging, escaping), assign them transition triggers (ie: patrolling + sees player = pursuing) and have each other handle their model in different ways (move towards the player while pursuing, shoot while engaging and move away while fleeing) without touching anything in the model.

An important part of AIs is how you let them interact with other objects. Making them omniscient is the easiest route, but it can lead to both cheap AI and hack-filled code that's hard to maintain. Giving AIs a few methods to gather information from its environment is "safer" and more realistic, but slightly more complicated at first.

EDIT: Avoiding double post:

Paz and I will be there (it'll be our first time going to GDC too!) We were offered the opportunity to show Assault Android Cactus at the Unity booth and at the Indie Megabooth!

In fact I've been flat out working on stuff for GDC and hardly had any time to add new things to the game, although I managed to get the next boss character intro animation done when nobody was looking

he's a big guy!

Amazing! I'll probably wait to play the game with the added content until I have some other people I can play with, but from what we've experienced so far, AAC is looking to be a really entertaining game for some slick local co-op!

I think the intro animation looks a bit off right after the boss lands, since it kind of absorbs the impact from the fall and gets up way too fast for a robot of its size. Just nitpicking, though, since everything else about the intro looks great!

...Anyway, talking about good old Quark Storm, I'll be trying out an artist and SFX designer soon, so the game might see some progress soon. I've also migrated the physics system to 2D so I could use Edge Colliders, and they've been working wonderfully (having to edit the edge's vertexes by going into debug mode is a bit of a pain, though). Having the whole stage as a single collider makes things that much better, since the character can no longer bump into overlapping level geometry, and also doesn't friction applied to it multiple times if it happens to be touching more than one object that I used to build the levels.

 

[Heart of Black]

Hey !

Is it possible to post a link to a Kickstarter project in which I am involved as a sound designer or is it too "auto-promo" ?

Should be fine as far as I know.

 

[Lihwem]

Should be fine as far as I know.

Nice ! Ok, so here it is :



Basically, it's a story-based construction game made with voxels where the player will be able to build all sort of things (weapons, vehicles, ... ) to help him in his quest. Feel free to comment and/or share the link !

 

[Mr. Virus]

Nice ! Ok, so here it is : Planets³

Basically, it's a story-based construction game made with voxels where the player will be able to build all sort of things (weapons, vehicles, ... ) to help him in his quest. Feel free to comment and/or share the link !

Ooo, I saw this earlier. Looks pretty cool, good luck with the KS !

 

[Makai]

Nice ! Ok, so here it is :



Basically, it's a story-based construction game made with voxels where the player will be able to build all sort of things (weapons, vehicles, ... ) to help him in his quest. Feel free to comment and/or share the link !

Wow! The competition is getting fierce. Amazing concept art:

Can you walk off the edge of the earth?

 

[PapaJustify]

Maybe it's worth posting here as well that Sony WWS have released the open source code to their Authoring Tools Framework:

https://github.com/SonyWWS/ATF

 

[bumpkin]

Man, today's killin' me. Last night I was working on enhancing the input detection in my engine to recognize and poll game controllers (e.g. wired Xbox 360 and a Logitech F310), and made some really useful discoveries this morning. The crappy thing is I can only write code from here, can't actually plug in the controllers and test 'til I get home. The suspense of if my solution will work or not is killing me.

5 o'clock, get over here!

 

[rexor0717]

So who here is attending GDC?
I'll be there, first time.
Should we organize a meetup?

I'll be there! I was there briefly on a Friday two years ago, but I didn't really get a good sense for what it was like. So this is really my first time, I've just had a small preview before.

Nice ! Ok, so here it is :



Basically, it's a story-based construction game made with voxels where the player will be able to build all sort of things (weapons, vehicles, ... ) to help him in his quest. Feel free to comment and/or share the link !

I like how there are more traditional classes, then the Solid Snake class.

 

[Bollocks]

Paz and I will be there (it'll be our first time going to GDC too!) We were offered the opportunity to show Assault Android Cactus at the Unity booth and at the Indie Megabooth!

Should be floating around as another first timer ! Will be at stand 1238 with a load of other Scottish devs .

We'll be at GDC Play showing Shiftlings Come say hi!

I'll be there! I was there briefly on a Friday two years ago, but I didn't really get a good sense for what it was like. So this is really my first time, I've just had a small preview before.

Will make sure to visit you guys!

As for myself I'll arrive in San Francisco Monday evening, first time in San Francisco so I'm open for suggestions if you want to grab a drink/have a quick bite. Just drop me a line/message.

Will be my 2nd GDC after I volunteered at GDC Europe'12. So I kind of know what to expect yet it will be totally different. Can't wait.