Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›623 »

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Rocko Bonaparte posted:

2. Using event callbacks in some kind of way. I've naturally stumbled into this kind of came in my own thing. It means having to register to receive callbacks for anything that can send them. It's similar enough to GUI stuff that I'm used to it.

One way I've done this in the past is to have your central group of interfaces (the things that manage each component type) have some number of messages defined that they can send out, and anything interested registers for them via callback. Then they step through and fire off all the callbacks when that event is sent, where that event can be sent by anything.

Rocko Bonaparte posted:

3. Some kind of message bus where message packets are transmitted and received by those that might care. I have the least detail on this and I'm the most interested in understanding it for general software design's sake; it might be something I might use in non-game stuff.

... or, you drop the registration, and every message send to an interface hits every single component managed by that interface - and then you add another layer of messaging with which you can target an event at a specific object, and a method for sending a message to all objects within some spatial region.

For the message registration itself, you typically want a base message class and then a child class per message type, whether hand-constructed or built out from message defs in a neato precompiler step, with each handler being trusted in some way to upcast properly.

I've also seen it done without any child clases, just a base message class, where a message type is defined via FOURCC code and the arguments are stored via a wrapper around hashed list of argument names and arguments. This isn't very fast or user-friendly, but depending on your use case, it's not bad, and very easy to set up.

(you can also do argument-less messages, and make it a rule that all messages have an orginator object, and all objects have a data store, and each message looks for specific data elements in the data store as arguments... but eh, that's way slow)

EDIT: And you will probably need a concept of messages sent to the interfaces themselves vs messages sent to other objects, but depending, that distinction may not need to be enforced particularly hard in code. You may also want to consider object messages being handleable by more than one component type, in which case you end up with a separate messaging interface that routes messages to all components on an object, instead of only specific components that registered. You can do this with messages "owned" by specific interfaces, so long as you use a callback system and no assumptions are made about what components are registering for handling.

Shalinor fucked around with this message at 18:57 on Aug 8, 2011

# ? Aug 8, 2011 18:49

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 11:49

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Rocko Bonaparte posted:

Something for the game engine types: How do you pass information back and forth across game objects? In all the stuff I gobbled up on component-based design lately, I saw there isn't really a consensus there. It's kind of interesting really to see what some people come up with.

I've been using a very simple abstract Message type, something like

code:

abstract class Message
{
   public float DelayTime = 0.0f;
   abstract void Execute();
}

coupled with a list of active messages held in some widely visible GameManager style object. On each timer tick the GameManager goes down the list, subtracts the frametime from each Message's DelayTime field and calls Execute on Messages where the DelayTime is less than or equal to zero. Any object references are packed into the concrete implementations of Message at instantiation.

Just as an example, the Message classes look like this

code:

public class PlaySoundMessage : Message
{
  SoundEffect soundEffect;

  public PlaySoundMessage(SoundEffect soundEffect)
  {
    this.soundEffect = soundEffect;    
  }
  
  public override Execute()
  {
    soundEffect.Play();
  }
}

If a player throws a hand grenade, the Grenade.Throw() method sends a PlaySoundMessage(grenadeThrowSound) on a zero second delay and a PlaySoundMessage(grenadeExplodeSound) on a three second delay. It could also send other Message types that create a fireball at the grenade's position after three seconds and another Message that removes the Grenade from the list of active GameObjects at the same time.

# ? Aug 8, 2011 19:48

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Shalinor posted:

...
For the message registration itself, you typically want a base message class and then a child class per message type, whether hand-constructed or built out from message defs in a neato precompiler step, with each handler being trusted in some way to upcast properly.
...

From a development point of view, have you found it particularly superior to doing event callbacks? I saw mention of targeting things, or targeting things in a range. I imagine the same could be done with callbacks.

The most evil setup I saw was basically from, to, some type identifer, and a void*. More generally I see people using strings to describe their messages. I have some aversion to using strings like that because of people screwing up the spelling on something. You'd likely only catch it at runtime.

quote:

EDIT: And you will probably need a concept of messages sent to the interfaces themselves vs messages sent to other objects, but depending, that distinction may not need to be enforced particularly hard in code. You may also want to consider object messages being handleable by more than one component type, in which case you end up with a separate messaging interface that routes messages to all components on an object, instead of only specific components that registered. You can do this with messages "owned" by specific interfaces, so long as you use a callback system and no assumptions are made about what components are registering for handling.

Something I haven't figured out yet is how compatible Python and C++ can be with each other when it comes to this kind of thing. I'm probably going to end up doodling most of my code in Python, with the big iron stuff in C++. However, it could be C++ or Python at either side of the transaction, and what I can do that would probably determine the details anyways.

PDP-11 posted:

coupled with a list of active messages held in some widely visible GameManager style object. On each timer tick the GameManager goes down the list, subtracts the frametime from each Message's DelayTime field and calls Execute on Messages where the DelayTime is less than or equal to zero. Any object references are packed into the concrete implementations of Message at instantiation.

This is pretty neat. It looks like you have your timer built into your messaging system.

I think my big problem is some design paralysis from writing in C++. There's nothing really stopping me from trying anything out in particular, other than the fact that the little C++ monkey on my back yells that it's inefficient. But I'd gleefully try it in most any JIT or interpreted language.

# ? Aug 8, 2011 20:37

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Rocko Bonaparte posted:

From a development point of view, have you found it particularly superior to doing event callbacks? I saw mention of targeting things, or targeting things in a range. I imagine the same could be done with callbacks.

The most evil setup I saw was basically from, to, some type identifer, and a void*. More generally I see people using strings to describe their messages. I have some aversion to using strings like that because of people screwing up the spelling on something. You'd likely only catch it at runtime.

Yep, that's the risk you run with string-identifiers on anything... but - string identifiers make gluing your logic to script a lot easier. They also make it easy to do an abstract message that can carry any data you want (if you do string-referenced variable names), though for that, you could instead do something fancy with an enum.

Generally, for performance reasons, I would recommend a base message class + per-message children + callback. Your central message router that holds the callback registrations should also be capable of doing direct-to-object messaging (not just to everything-listening-for-a-message) and spatial checks (for the sending of a message to everything within a particular region). That, and make sure that a given message can be listened to by any combination of component types, and you're basically golden.

How fancy you get with it beyond that, though, is up in the air. Faboo message definition systems that generate the children AND generate the equivalent structure in script-space, etc, are pretty cool, but take time to build.

Shalinor fucked around with this message at 21:20 on Aug 8, 2011

# ? Aug 8, 2011 21:18

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

Shalinor posted:

Generally, for performance reasons, I would recommend a base message class + per-message children + callback. Your central message router that holds the callback registrations should also be capable of doing direct-to-object messaging (not just to everything-listening-for-a-message) and spatial checks (for the sending of a message to everything within a particular region). That, and make sure that a given message can be listened to by any combination of component types, and you're basically golden.

I use an event/message and object-made-of-components system for Caves of Qud, and one thing I'd suggest doing is allowing component-based priority, so you can ensure that one type of component will respond to a message (at least on a per object basis) before another type of component. This would save you some effort of building silly event chains like BeforeBeforeX, BeforeX, X, AfterX, AfterAfterX, to get the results of events stacking correctly.

E: Generally I like this approach (objects-as-set-of-components, communicating with events) and it has worked very well for the sort of program-things-to-do-anything-I-need stuff I need for a really flexible, emergent engine.

Unormal fucked around with this message at 21:41 on Aug 8, 2011

# ? Aug 8, 2011 21:38

Vino: Aug 11, 2010

Source has a spectacular entity IO system that I absolutely love. Qt has a similar sort of message passing system. I think they work great for game development. I think your second option is that, it's my favorite option. It does mean registering inputs and outputs and whatnot but it's super handy once it's up and running.

# ? Aug 8, 2011 23:10

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

Shalinor posted:

Yep, that's the risk you run with string-identifiers on anything... but - string identifiers make gluing your logic to script a lot easier. They also make it easy to do an abstract message that can carry any data you want (if you do string-referenced variable names), though for that, you could instead do something fancy with an enum.

Generally, for performance reasons, I would recommend a base message class + per-message children + callback. Your central message router that holds the callback registrations should also be capable of doing direct-to-object messaging (not just to everything-listening-for-a-message) and spatial checks (for the sending of a message to everything within a particular region). That, and make sure that a given message can be listened to by any combination of component types, and you're basically golden.

How fancy you get with it beyond that, though, is up in the air. Faboo message definition systems that generate the children AND generate the equivalent structure in script-space, etc, are pretty cool, but take time to build.

Do you have any links/resources for more information? This seems like the sort of thing that could be clearly summed up in a diagram, but I'm having a hard time parsing English into code mentally.

# ? Aug 8, 2011 23:15

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Pfhreak posted:

Do you have any links/resources for more information? This seems like the sort of thing that could be clearly summed up in a diagram, but I'm having a hard time parsing English into code mentally.

Nope, just my ramblings. Others in here might, or I might someday do a blog up on it, but that's all I've got for now.

# ? Aug 8, 2011 23:17

Vino: Aug 11, 2010

All of Source's object messaging system is in their free SDK and it supports all that junk that Shalinor just said. That might be a handy reference for you.

# ? Aug 8, 2011 23:20

seiken: Feb 7, 2005; hah ha ha

YO

I'm working on a game in C++ and I need an audio library that can do "DJ mixes" of the game music. Let be more specific: I'm writing all the music for the game, and I'm doing it all at 80 BPM, so I don't need to play music faster or slower or anything. Rather, I just need an audio library that can play 2 or 3 MP3 files at once, and guarantee that they will all play at exactly 48KHz or whatever. If I have that, I can start song B playing some multiple of 24 seconds - 8 bars at 80 BPM - after song A started, and they will guarantee to line up, and then I can fade them in and out and things. (Bonus points if it can start song B exactly 48000 * 24 samples into song A.)

We tried FMOD, but it seems like it if you have more than one channel playing at a time then you get no guarantees about stuff starting on time or staying in sync or anything. (Maybe I'm wrong about that, though.) Anyone happen to know of something suitable?

# ? Aug 8, 2011 23:34

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

Shalinor posted:

Nope, just my ramblings. Others in here might, or I might someday do a blog up on it, but that's all I've got for now.

Here are a couple of links that I found that inspired my componentized entity system:

http://www.purplepwny.com/blog/ - The blog is 2 years old, but has a few tidbits about component implementation to get you going. I wonder why he abandoned it.

http://cmpmedia.vo.llnwd.net/o1/vault/gdccanada09/slides/marcinchadyGDCCanada.ppt - Gives an overview on the system used in the game "Prototype" by one of the developers.

Hopefully they can help.

# ? Aug 9, 2011 03:03

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

HiriseSoftware posted:

http://cmpmedia.vo.llnwd.net/o1/vault/gdccanada09/slides/marcinchadyGDCCanada.ppt - Gives an overview on the system used in the game "Prototype" by one of the developers.

So would you say then that a component exposes no methods, just something to handle messages to/from it? I think that's what is going on in the slides. I'm letting that kind of set into my head, because it's kind of like history repeating in the whole component-based design stuff. I couldn't really grok having an entity object that is just stuffed with things to make it into whatever it needs to be. It basically throws away the whole inheritance side of OOP. Using messages basically throws away the idea of methods too for all the game logic stuff.

I think I do owe it to myself to understand Qt's signaling system because it's coming up more often.

# ? Aug 9, 2011 06:47

AntiPseudonym: Apr 1, 2007; I EAT BABIES

Rocko Bonaparte posted:

So would you say then that a component exposes no methods, just something to handle messages to/from it? I think that's what is going on in the slides. I'm letting that kind of set into my head, because it's kind of like history repeating in the whole component-based design stuff. I couldn't really grok having an entity object that is just stuffed with things to make it into whatever it needs to be. It basically throws away the whole inheritance side of OOP. Using messages basically throws away the idea of methods too for all the game logic stuff.

I think I do owe it to myself to understand Qt's signaling system because it's coming up more often.

I use a component system at work and at home, and we expose methods quite reguarly. The way we use them is to have a way of getting components from an actor (Literally just an actor->GetComponent<NameOfComponent>()) and call whatever we need on them. Obviously the GetComponent method is reasonably slow, so we cache anything that we're going to need more than once.

Inheritance definitely does take a back seat in a component-based system, though. It takes a bit of getting used to, but composition does have a lot of benefits over inheritance.

# ? Aug 9, 2011 09:22

1337JiveTurkey: Feb 17, 2005

Rocko Bonaparte posted:

So would you say then that a component exposes no methods, just something to handle messages to/from it? I think that's what is going on in the slides. I'm letting that kind of set into my head, because it's kind of like history repeating in the whole component-based design stuff. I couldn't really grok having an entity object that is just stuffed with things to make it into whatever it needs to be. It basically throws away the whole inheritance side of OOP. Using messages basically throws away the idea of methods too for all the game logic stuff.

I think I do owe it to myself to understand Qt's signaling system because it's coming up more often.

Scala does something similar with its actors. I'm using those for a roguelike right now and it's actually working pretty nicely. The actors all work on a message-passing basis but since the messages are objects, I can pattern match on the interface and have multiple implementations for some behavior on the message object itself. Splitting out the aspects of an entity object into individual parts (which can be polymorphic in their own right) ends up being a lot more robust than doing things with one big class per distinct entity object.

As something to think about : What happens if I have a IBlowUppable interface for things that can be blown up. Now if I blowUp(Explosion) everything in some area, what do I do if something isn't actually IBlowUppable? Reflection? Make everything implement it? Both solutions share aspects with message passing components.

# ? Aug 9, 2011 13:43

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

Rocko Bonaparte posted:

So would you say then that a component exposes no methods, just something to handle messages to/from it? I think that's what is going on in the slides. I'm letting that kind of set into my head, because it's kind of like history repeating in the whole component-based design stuff. I couldn't really grok having an entity object that is just stuffed with things to make it into whatever it needs to be. It basically throws away the whole inheritance side of OOP. Using messages basically throws away the idea of methods too for all the game logic stuff.

I think I do owe it to myself to understand Qt's signaling system because it's coming up more often.

Pretty much, yeah. Like 1337JiveTurkey says, you don't have all entities with the same game logic "blowUp" method whether they blow up or not. An entity component knows to respond to a certain message, so when you attach that component to an entity, you can send the MESSAGE_BLOWUP message without having to worry about if in fact that entity DOES "blow up".

In my implementation, there is an Entity class that has within it instances of classes derived from EntityComponent, like PlayerComponent (that takes in player input), ChaseComponent (for simple chase AI), or CollisionComponent. Entity just has Update() and SendMessage() much like in the presentation I linked. In each component's header file I use #define macros to register a particular message ID with that component (or if would respond to Update), so the subsystem builds a map based off of that information. I don't have components that inherit from other components, but thinking about it I don't think it would be a problem the way I implemented it. I build an entity (e.g. a "Monster") by using an XML file that defines which components are used and any attribute initialization, and the order in which the components are listed is the order in which their methods are called. I can then serialize that built entity into a single block of memory and make it a template so that to create a new "Monster" I just need one allocation and a memcpy and I'm good to go.

HiriseSoftware fucked around with this message at 14:43 on Aug 9, 2011

# ? Aug 9, 2011 14:39

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

HiriseSoftware posted:

Pretty much, yeah. Like 1337JiveTurkey says, you don't have all entities with the same game logic "blowUp" method whether they blow up or not. An entity component knows to respond to a certain message, so when you attach that component to an entity, you can send the MESSAGE_BLOWUP message without having to worry about if in fact that entity DOES "blow up".

Since you guys seem to have used it a lot, generally how clean or messy does it tend to get in the component itself versus having methods and callbacks?

I'm also falling for premature optimization here. I think I've seen a few variations of this posted online. I guess the gist of it is that you send a message to whoever manages the components for the entity (the entity itself or some entity manager) and that just passes it to each component. The component decides what to do with it. Do components tend to get spurious messages?

# ? Aug 9, 2011 15:02

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

Rocko Bonaparte posted:

Since you guys seem to have used it a lot, generally how clean or messy does it tend to get in the component itself versus having methods and callbacks?

I'm also falling for premature optimization here. I think I've seen a few variations of this posted online. I guess the gist of it is that you send a message to whoever manages the components for the entity (the entity itself or some entity manager) and that just passes it to each component. The component decides what to do with it. Do components tend to get spurious messages?

Well, each component has a public OnMessage() method that is basically a big switch/case statement to check for the message coming in and then do something with it. I suppose you could have private methods that actually to the meat and make the OnMessage pretty concise.

I'm not sure what you mean by "spurious messages". Like I said in my implementation, the entity will only call OnMessage on components that registered to receive that message. It keeps the system having to call OnMessage for, say, 20+ components when only one component really cares.

# ? Aug 9, 2011 15:30

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

Rocko Bonaparte posted:

Since you guys seem to have used it a lot, generally how clean or messy does it tend to get in the component itself versus having methods and callbacks?

I'm also falling for premature optimization here. I think I've seen a few variations of this posted online. I guess the gist of it is that you send a message to whoever manages the components for the entity (the entity itself or some entity manager) and that just passes it to each component. The component decides what to do with it. Do components tend to get spurious messages?

The way I do it is to have a "Register" function that's called on a component whenever it's added to an object. Each component uses this register function to add the messages it's listening for to the parent object.

So something like

Register( Object Parent )
{
Object.RegisterPartEvent( "BlowUp!!!", this );
Object.RegisterPartEvent( "GotHit", this );
}

and then the parent object stores a hash table of events and the parts (components) that are listening for those events, so when it gets an event it can quickly rip through the components that care about it, calling FireEvent on each one.

Object containers can basically peek at the dictionary for each object and see if it contains a bucket for the required event, and never need to call the object's FireEvent at all.

# ? Aug 9, 2011 16:07

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Well, giving everything string bindings and the like isn't strictly necessary, you can have stronger-typed approaches that make bindings more explicit. That is, objects that can definitely receive a type of event are bound to objects that can definitely broadcast that type of event, and individual world objects are essentially "controllers" that glue together multiple specialized objects, rather than having objects be gigantic message maps and attribute bags.

I think it's generally okay to pack functionality into the same components when that functionality correlates strongly, or when it has an extremely high level of cross-interaction that splitting them off makes a mess. UE3, for example, essentially treats skeletal mesh controllers as part of the physics system, because that lets it mix animations, IK, and ragdolls much more easily. It's not a big deal when those components can have components of their own with a common relationship (i.e. attachments).

You can also do stuff like group functionality by how the events propagate. Again with physics, you could decide that all events that propagate spatially should propagate via the physics system, which adds practically no complication to the functioning of physical objects, but does simplify stuff like explosive damage and the propagation of sound.

OneEightHundred fucked around with this message at 04:54 on Aug 10, 2011

# ? Aug 10, 2011 00:13

Synthbuttrange: May 6, 2007

Rupert Buttermilk posted:

I'm just starting in game development, and have decided, at least for now, to try my hand at Stencyl. Now, I know that this can come across as 'Baby's First Game Engine', but whatever, I don't have much programming know-how, but I'm willing to work on it, learn more as time goes on, and just get better, all-around. I'm not kidding myself into thinking that I'm going to be some overnight millionaire, or even close, but goddammit, do I want to make my own game.

That being said, I question how far one can go with something like Stencyl. I see that you're not limited JUST to using pre-made stuff, that if you know progamming (Actionscript?) you can get a lot of custom poo poo done. I'm sort of thinking of making a game that is, I won't like, heavily inspired by Mario 3. For clarification, I mean multiple overworlds with a beginning, end, as well as levels along the way, usable items, bonuses... stuff like that. Does anyone know if an engine like Stencyl can do this?

Also, I plan on dedicating a lot of my time to getting the physics of movement just right, so that they don't feel stiff, or too floaty. Can this be done with Stencyl, or are there a lot of limitations with it?

Been playing with Stencyl for a few days now and it looks like the controls and physics are easily managed.

The 'coding' feels silly at first, but I quickly got used to it, after making liberal use of the built in block searcher.

Looks sort of familiar somehow.

I've been peeking at the code in all the kits and games that look like they'll help and have cobbled up the basics for a game that I want, and slapped on some graphics I had lying around on top of it. I think I'm over the hump for 'What the gently caress am I doing?!' or 'How am I supposed to get anything done in this?' and am now in the stage of being able to break things down into getting stuff to behave the way I want them to and talking to each other and the interface.

Hopefully it'll be an RPG-ish gladiator management game when I'm done with it.

# ? Aug 11, 2011 10:02

Physical: Sep 26, 2007; by T. Finninho

SynthOrange posted:

Been playing with Stencyl for a few days now and it looks like the controls and physics are easily managed.

The 'coding' feels silly at first, but I quickly got used to it, after making liberal use of the built in block searcher.

Holy gently caress I have never been more repulsed and attracted to a development environment before. That thing looks cool but at the same time it makes it way too easy to program I am guessing. It's disgusting how easy it looks.

# ? Aug 11, 2011 21:09

Synthbuttrange: May 6, 2007

And then I run into a annoying stumbling block. You cannot simply select and copy chunks of code from one module to another. Oh well, the price of not being a coder person.

# ? Aug 12, 2011 17:41

Smugdog Millionaire: Sep 14, 2002; 8) Blame Icefrog

Physical posted:

Holy gently caress I have never been more repulsed and attracted to a development environment before. That thing looks cool but at the same time it makes it way too easy to program I am guessing. It's disgusting how easy it looks.

I hate it when things are easy.

# ? Aug 12, 2011 18:10

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Physical posted:

Holy gently caress I have never been more repulsed and attracted to a development environment before. That thing looks cool but at the same time it makes it way too easy to program I am guessing. It's disgusting how easy it looks.

They had similar things in the WC3/SC trigger systems. The bottom line is that it becomes much easier for non-programmers to set up events and the like, but it has a much harsher limit on how fast you can hammer out code. Knowing the APIs and having auto-complete in a text editor is much faster than clicking around all over the place to get a line of code out.

# ? Aug 12, 2011 18:14

Synthbuttrange: May 6, 2007

Stumbling block 2. Developing behaviors in their own game module became a real pain when I discovered that to get them into another game, you've got to upload them to Stencyl and then download them again into the new game module.

At least I've figured out using lists for inventories and stats and such. Making up some text input code though, that looks a little scarier. All the ones I've downloaded to look inside are full of

if key pressed = A
text_string+"a"
if key pressed = B
text_string+"b"
if key pressed = C
text_string+"c"

:ohdear:

Still, making progress.

# ? Aug 13, 2011 05:22

The Fool: Oct 16, 2003

What's the easiest way to put in some sort of replay system? I was hoping that there would be some sort of API that would allow me to record a video to disk?

# ? Aug 14, 2011 02:14

Jewel: May 2, 2009

The Fool posted:

What's the easiest way to put in some sort of replay system? I was hoping that there would be some sort of API that would allow me to record a video to disk?

Never do replays by video. Always try and work out a system to save key points, for example, in super meat boy they might just save when you hold a key, when you let go of a key, and use the actual level entities to simulate your character and any moving terrain/enemies.

Another thing if you game can't possibly work that way for some reason or other, is to save key positions every X frames, then interpolate between those. Ooor a combination of both, and compare the location you get to from the keypresses with the interpolated position, and mash the two together.

# ? Aug 14, 2011 02:29

Paniolo: Oct 9, 2007; Heads will roll.

The Fool posted:

What's the easiest way to put in some sort of replay system? I was hoping that there would be some sort of API that would allow me to record a video to disk?

Save your random seeds, record all input. To replay, reseed the RNG and replay the input stream.

# ? Aug 14, 2011 02:46

The Fool: Oct 16, 2003

That seems to be the consensus from what I've been reading, but seems to be a lot of work when all I want is a quick and dirty "Upload to Youtube" button.

# ? Aug 14, 2011 03:04

Jewel: May 2, 2009

The Fool posted:

That seems to be the consensus from what I've been reading, but seems to be a lot of work when all I want is a quick and dirty "Upload to Youtube" button.

Uhh oh, well, it's not as much work as it sounds (you'll need it for any project with replays, just do it), but if you want an "Upload to Youtube" button, that'd be a bit different. I say still go with the method/s that I explained to make the replay, then use some form of API that can save the main screen texture to AVI or somesuch when a user clicks a button.

If you're just making it record every game ever, the user's going to complain due to lack of HD space and unneeded recordings. What if they left the game running for a few hours while they went out? You don't want it recording all of that and then filling up their HardDrive. Let the user say "Ok, this replay was good, I'm going to save this replay at the end of the game (and they should only be a few kb if you've made it right)." And then later on, let them browse a replay menu to watch the replay, or click a button that says "Upload to youtube", in which you do the process I outlined in the first paragraph.

# ? Aug 14, 2011 03:14

Vino: Aug 11, 2010

SynthOrange posted:

And then I run into a annoying stumbling block. You cannot simply select and copy chunks of code from one module to another. Oh well, the price of not being a coder person.

If you understand the concepts behind this visual programming stuff, then it should be a small jump to learn the specific syntax that gets you to being an actual coder person. Really you're dealing with the same concepts, the only thing that's separating you from creating an actual program is learning C syntax. From what I see in Stencyl, you're otherwise doing the exact same thing a programmer does.

# ? Aug 15, 2011 04:19

Synthbuttrange: May 6, 2007

Maybe so, but the attraction of stencyl is that it sets up the groundwork for you for a lot of stuff. Getting my feet wet first, then when I feel I'm being hampered too much I'll move on to better platforms.

Stencyl learning update: Setting up keyboard inputs still eludes me, the listening loop just chews up all the processing power then crashes. Instead, resorting to an on-screen keyboard. I may feel like an idiot, but it works.

# ? Aug 15, 2011 05:41

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Paniolo posted:

Save your random seeds, record all input. To replay, reseed the RNG and replay the input stream.

To add on to this, if you're doing a client-server network game, record the initial world state and all state updates received from the network.

# ? Aug 15, 2011 16:14

Hughlander: May 11, 2005

OneEightHundred posted:

To add on to this, if you're doing a client-server network game, record the initial world state and all state updates received from the network.

Heck any network game.

If you're doing peer to peer you just need to do it even more. One good thing is to come up with a hashing or crc of the entire world state/input so you can quickly verify that everyone (All clients if appropriate, server if appropriate, and save game stream) agrees with the state.

# ? Aug 15, 2011 16:56

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Am I envisioning the behavior of Octrees correctly?

Is it the case that if an object intersects the very centerpoint of the Octree's space, that in a collision detection check of any other object in the Octree, that center object must always be checked? (ie. a tiny object over the center would occupy the same part of the octree as a giant object over the whole grid would?)

In my head how it works is an object is placed just once in the octree in the smallest cell it will fit entirely inside, and a collision check for a specific object must check against objects in the cell it's in, all parent cells, and the subset of child cells that it overlaps with?

(ie. a tiny object over the center would, in an octree 3 deep, only need to be checked against the contents of the root cell, all eight second-layer cells, and then only the 'centermost' child cell of each of the second-layer cells.)

Is this how it's generally done or am I missing something important?

Also, how deep does an octree typically go?

# ? Aug 15, 2011 17:02

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Hughlander posted:

If you're doing peer to peer you just need to do it even more.

In peer-to-peer games, "all input" and "all of your network traffic" are pretty much the same thing.

# ? Aug 15, 2011 17:13

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

roomforthetuna posted:

Is this how it's generally done or am I missing something important?

If I understand you correctly, then - yes, that's my understanding as well.

An Octree is meant to always have regular divisions of its space into progressively smaller cubes, those cubes arrayed based on the octants of the parent octant. As those octants divide alone the coordinate planes, if you have something, even a pencil, that happens to be aligned perfectly with one of the coordinate axis, it by definition does not fit into any one octant and can never be nested into a child octant below wherever it fell.

... now what I don't know is whether or not there are simple modifications of the algorithm to fix that. KD-Trees, for instance, avoid this with non-regular spatial division. The nested children aren't octant-aligned, they're AABBs that happen to divide the space into whatever fits, so those you can optimize to properly nudge around the object that just happens to occupy the center of the parent octant. It seems like there ought to be, but I've never worked on an engine that needed me to delve deeper than a basic Octree.

Regardless, assuming you stick with the regular AABB approach, that is the single biggest weakness of an octree structure. They're great for small objects of roughly uniform size and distribution - but they're terrible for, for instance, a sea of tall office buildings arrayed in a grid.

EDIT: VV Try googling for "kd-tree octree" and variants thereof. What you really need is, effectively, a 3D generalization of the 2D kd-tree algorithm, just like an octree is the 3D generalization of the 2D quad-tree.

Shalinor fucked around with this message at 17:52 on Aug 15, 2011

# ? Aug 15, 2011 17:30

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Shalinor posted:

Regardless, assuming you stick with the regular AABB approach, that is the single biggest weakness of an octree structure. They're great for small objects of roughly uniform size and distribution - but they're terrible for, for instance, a sea of tall office buildings arrayed in a grid.

That's a good point and a question I probably should have gone with first - is there a system that's not overly complicated that's significantly better than octrees for my particular purpose? What I have is a 3D space into which many immobile convex shapes are added (rarely removed, but more added on-the-fly) and a small number of moving objects that can collide with the immobile shapes. For moving object to moving object collision I'm just going to do a flat "all against all" comparison because there won't be more than 16 of those. Some (many?) of the immobile shapes will be long and thin, which may not suit octrees very well.

# ? Aug 15, 2011 17:46

This Post Sucks: Dec 27, 2004; It Gave Me Splinters!

I'm an Actionscript coder but have mostly only done Flex apps and the like. I've done very little work in Flash itself. What would be the best route to start in to game development?

I've looked in to Flixel and it seemed pretty straight forward and it works with straight AS3 and had good documentation to get started with? Is it a good choice to look in to?

# ? Aug 15, 2011 19:57

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 11:49

Physical: Sep 26, 2007; by T. Finninho

This Post Sucks posted:

I'm an Actionscript coder but have mostly only done Flex apps and the like. I've done very little work in Flash itself. What would be the best route to start in to game development?

I've looked in to Flixel and it seemed pretty straight forward and it works with straight AS3 and had good documentation to get started with? Is it a good choice to look in to?

As3 in Flash IDE is no different than flex. What you might want to do is write your code externally and link the class file with the file->properties option (or something like that). Also, I use APE for all my 2D stuff.

# ? Aug 15, 2011 21:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›623 »