Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualnfactorial

Posted 27 February 2013 - 08:57 AM

Caveat: "How close to the game code.." is actually a fairly perspective-dependant question. Many will say it should be very close, or that "the editor is the game!". Many will say not, there is no real 'true' answer only opinion.

 

Saying that, my own opinion is that "code wise" your editing application doesn't *need* to be that close at all, in fact I would say if it is close then you are significantly hamstringing yourself for no benefit. That doesn't mean it can't work, only that I think it's not the best way.

 

I would personally state that *data* wise, there should be a strong correlation between editor and game but not code wise. With the simple conclusion that a game is not an editor, and an editor is not a game. There are things both wish to do that are not of interest to the other and trying to get both to work in the same space will cause your final code to be a mash of both and the best of neither. Putting both together in the same code base narrows your options and forces you into design choices that are not based on what is best for your editor or game, but choices that don't break your editor or game.

 

Take, as a really simple example, a simple float. This represents the maximum 'strength' of something in the game, in the editor you would want associated metadata like an edit range, a display name, an edit type (numeric or slider, for example). The game doesn't need or want this meta-data, but it's there anyway because the editor needs it. You could then argue ways to provide that data that disappear when running the actual game (or even argue you don't want that data at all), but you're then already in the valley of "mash of both, best of none".

 

The code examples in the previous post (please don't take this personally, I'm just using as an example) ties the game & editor together in all kinds of ways I don't like (even if I were taking a "the editor is the game" approach).

 

My ultimate point is that you should be thinking much more along data-centric relations than code-centric, you can pile everything together if you like though that's not my personal preference (it can work) but I'd rather have an editor and a game with tight data driven relations. It's actually a big subject I could go on about for a long time unfortunately :s

 

n!


#3nfactorial

Posted 27 February 2013 - 08:56 AM

Caveat: "How close to the game code.." is actually a fairly perspective-dependant question. Many will say it should be very close, or that "the editor is the game!". Many will say not, there is no real 'true' answer only opinion.

 

Saying that, my own opinion is that "code wise" your editing application doesn't *need* to be that close at all, in fact I would say if it is close then you are significantly hamstringing yourself for no benefit. That doesn't mean it can't work, only that I think it's not the best way.

 

I would personally state that *data* wise, there should be a strong correlation between editor and game but not code wise. With the simple conclusion that a game is not an editor, and an editor is not a game. There are things both wish to do that are not of interest to the other and trying to get both to work in the same space will cause your final code to be a mash of both and the best of neither. Putting both together in the same code base narrows your options and forces you into design choices that are not based on what is best for your editor or game, but choices that don't break your editor or game.

 

Take, as a really simple example, a simple float. This represents the maximum 'strength' of something in the game, in the editor you would want associated metadata like an edit range, a display name, an edit type (numeric or slider, for example). The game doesn't need or want this meta-data, but it's there anyway because the editor needs it. You could then argue ways to provide that data that disappear when running the actual game (or even argue you don't want that data at all), but you're then already in the valley of "mash of both, best of none".

 

The code examples in the previous post (please don't take this personally, I'm just using as an example) ties the game & editor together in all kinds of ways I don't like (even if I were taking a "the editor is the game" approach).

 

My ultimate point is that you should be thinking much more along data-centric relations than code-centric, you can pile everything together if you like though that's not my personal preference (it will work) but I'd rather have an editor and a game with tight data driven relations. It's actually a big subject I could go on about for a long time unfortunately :s

 

n!


#2nfactorial

Posted 27 February 2013 - 08:55 AM

Caveat: "How close to the game code.." is actually a fairly perspective-dependant question. Many will say it should be very close, or that "the editor is the game!". Many will say not, there is no real 'true' answer only opinion.

 

Saying that, my own opinion is that "code wise" your editing application doesn't *need* to be that close at all, in fact I would say if it is close then you are significantly hamstringing yourself for no benefit. That doesn't mean it can't work, only that I think it's not the best way.

 

I would personally state that *data* wise, there should be a strong correlation between editor and game but not code wise. With the simple conclusion that a game is not and editor, and an editor is not a game. There are things both wish to do that are not of interest to the other and trying to get both to work in the same space will cause your final code to be a mash of both and the best of neither. Putting both together in the same code base narrows your options and forces you into design choices that are not based on what is best for your editor or game, but choices that don't break your editor or game.

 

Take, as a really simple example, a simple float. This represents the maximum 'strength' of something in the game, in the editor you would want associated metadata like an edit range, a display name, an edit type (numeric or slider, for example). The game doesn't need or want this meta-data, but it's there anyway because the editor needs it. You could then argue ways to provide that data that disappear when running the actual game (or even argue you don't want that data at all), but you're then already in the valley of "mash of both, best of none".

 

The code examples in the previous post (please don't take this personally, I'm just using as an example) ties the game & editor together in all kinds of ways I don't like (even if I were taking a "the editor is the game" approach).

 

My ultimate point is that you should be thinking much more along data-centric relations than code-centric, you can pile everything together if you like though that's not my personal preference (it will work) but I'd rather have an editor and a game with tight data driven relations. It's actually a big subject I could go on about for a long time unfortunately :s

 

n!


#1nfactorial

Posted 27 February 2013 - 08:55 AM

Caveat: "How close to the game code.." is actually a fairly perspective dependant question. Many will say it should be very close, or that "the editor is the game!". Many will say not, there is no real 'true' answer only opinion.

 

Saying that, my own opinion is that "code wise" your editing application doesn't *need* to be that close at all, in fact I would say if it is close then you are significantly hamstringing yourself for no benefit. That doesn't mean it can't work, only that I think it's not the best way.

 

I would personally state that *data* wise, there should be a strong correlation between editor and game but not code wise. With the simple conclusion that a game is not and editor, and an editor is not a game. There are things both wish to do that are not of interest to the other and trying to get both to work in the same space will cause your final code to be a mash of both and the best of neither. Putting both together in the same code base narrows your options and forces you into design choices that are not based on what is best for your editor or game, but choices that don't break your editor or game.

 

Take, as a really simple example, a simple float. This represents the maximum 'strength' of something in the game, in the editor you would want associated metadata like an edit range, a display name, an edit type (numeric or slider, for example). The game doesn't need or want this meta-data, but it's there anyway because the editor needs it. You could then argue ways to provide that data that disappear when running the actual game (or even argue you don't want that data at all), but you're then already in the valley of "mash of both, best of none".

 

The code examples in the previous post (please don't take this personally, I'm just using as an example) ties the game & editor together in all kinds of ways I don't like (even if I were taking a "the editor is the game" approach).

 

My ultimate point is that you should be thinking much more along data-centric relations than code-centric, you can pile everything together if you like though that's not my personal preference (it will work) but I'd rather have an editor and a game with tight data driven relations. It's actually a big subject I could go on about for a long time unfortunately :s

 

n!


PARTNERS