Jump to content
  • Advertisement
Sign in to follow this  
Simagery

Unity What gamedev can learn from the web

This topic is 4583 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been wrestling recently with crafting a framework for gamedev. One of the things that struck me was how awkward it was to prototype ideas quickly. I found this to be an incredibly odd aspect of a creative medium. I spend a lot of time doing web dev stuff for fun (used to professionally), and it struck me that HTML/etc. is a very prototype-friendly context for development. In fact, I started thinking about how the current "web 2.0" model has all of the aspects of gamedev: structure (XHTML), behavior (javascript), aesthetics (CSS). I thought, why is there no equivalent in gamedev? Some may suggest that there is: game engines. But that's not quite it. Game engines would be the equivalent of a CMS app in webdev (Blogger, Wordpress, GoLive, etc.) Game engines are pre-defined structures in which you pump content. That's not what I'm looking for. I'm thinking of something more like XAML, but directed at games. I would think this would be incredibly useful as a large aspect of gamedev is interface design (as an extension of interaction design), and markup languages have proven themselves to be very applicable to this job -- or at the very least, there's a lot of intuition out there due to their use on the web. With the "web" model (for lack of a more appropriate term), you have the classic three components: HTML/CSS/DOM. HTML defines structure, CSS defines "look-n-feel" or aesthetics, and the DOM represents programmatic manipulation, i.e. behavior. So, the model is structure/aesthetics/behavior. This, to me, feels fairly complete as it maps very cleanly to a proven architecture: model/view/controller. Hmm... I need to give this some more thought as I'm really just making stuff up as I write... I'd be very interested in hearing what other folks out there have to think about this, though.

Share this post


Link to post
Share on other sites
Advertisement
I think SHilbert has been looking into the Model/View/Controller pattern as a means of game development.

Share this post


Link to post
Share on other sites
I've talked a lot about using MVC for gamedev, but I'm more interested in the actual tools for implementing that pattern. Namely, an XML-like language for strucutre, a CSS-like language for aesthetics, and a javascript-like language for behavior. Something along the lines of XML/OpenGL/Python or something...

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
could you consider a scripting language (python, lua) to be a controller?


Yes, definitely. A scripting language (or even compiled code) is used to author the game's behavior, which is equivalent (in part) to the controller in the MVC model. Of course, behavior is also an aspect of the model as well (simulation), so what I'm talking about isn't a strict 1-to-1 correspondance with MVC.

Share this post


Link to post
Share on other sites
Quote:
Original post by Simagery
Quote:
Original post by Alpha_ProgDes
could you consider a scripting language (python, lua) to be a controller?


Yes, definitely. A scripting language (or even compiled code) is used to author the game's behavior, which is equivalent (in part) to the controller in the MVC model. Of course, behavior is also an aspect of the model as well (simulation), so what I'm talking about isn't a strict 1-to-1 correspondance with MVC.


it seems like the most simplistic view is: programming languages, graphics api, scripting languages

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
it seems like the most simplistic view is: programming languages, graphics api, scripting languages


I'm not looking for the most simplistic view. What you listed are all elements to the implementation of what I'm looking for. To further elaborate:

There are several major divisions to the work that goes into developing a game. These divisions are nearly orthogonal (though games are a callobrative medium, so not completely orthogonal in the mathematical sense).

First, you have the "gameplay" or the model of the game. This would be the rules, the tokens, the verbs and nouns, the simulation that constitutes your game. This is the part of the game that can be designed as a board game (however tedious it may be to play) and can be described completely in a design doc.

Second, you have the representation of the game, the view onto the gameplay. This is an incredibly important aspect of electronic games. In traditional board games, the view was closely tied to the model due to the practical limitations. It's not fun to move around stuff that doesn't have any gameplay impact. In electronic games, we have a lot of "view" or aesthetics to the game that aren't directly related to the gameplay model, or simply provide "softer edges" on the underlying gameplay model.

Finally, you have the player-computer interaction, the controller for the gameplay. This is where the interaction between user and game is defined and implemented. This is another area where electronic games differ quite a bit from traditional board games. Automation can be introduced into the interaction, which allows gameplay where, for example, hundreds or thousands of soldiers can be moved independently with little effort (whereas a board game would require an incredible amount of tedium to accomplish the same end results).

Now, what I just described is a decomposition of a game into a Model/View/Controller pattern. I've seen elsewhere that some game academics have labelled this, in the context of game design, as Dynamics/Aesthetics/Mechanics. The Dynamics/Aesthetics/Mechanics suggestion is new to me, so I'll continue to use the MVC pattern as I'm more comfortable with its connotations.

The web is a different medium, one resulting primarily from the goal to present information. Interaction is not a fundamental, defining characteristic of the web, though it is largely becoming a critical element of "web 2.0." Regardless of fashion, though, the web is not defined by interactivity in the same way that games are defined by interactivity.

The webdev circles, particularly those in the "semantic web" camp (of which I'd count myself), like to decompose a webpage into three components: HTML, CSS and DOM, or roughly, structure, styling and behavior. I'm seeing some interesting parallels with what I want to do when developing (or at least prototyping) a game.

Structure is quite clear: games, as beasts of interactivity, are necessarily "software programs" and thus benefit from well-defined structure. More specifically, games have well-defined states and logical organization, even if it's as simple as Menu -> Game -> Scores. That would be a good example of the temporal structure of the game, but there's also the obvious spatial structure of the game, both screen relative (high score in the top-left corner, current score in the top-right corner, gameplay in the background) or gameplay relative (a house here, a road here, a car parked here, the bad guy is in here).

Styling, or aesthetics, is the difference between Wolfenstein 3D, Doom, and Doom 3. Or, more critically to the development phase, it's the difference between placeholder art with a diffuse shader and finished models with normal-mapping goodness.

And behavior, well, that's the interaction in the game, the give-and-take between user and computer simulation. Everything from the actual ruleset being played out to the way a unit is moved from point A to B or how a widget in the UI reacts when clicked.

And this raises an interesting deviation between the web model and the game model. The web model isn't focused on what would be considered the server-side, or backend, of websites. It's primarily focused on the presentation and interaction with the user. For gamedev, the model would need to be a slight hybrid that would incorporate the backend and the frontend into a cohesive whole. As a result, you'd have structure and behavior intermingled at both lower and higher levels of the design.

Again, just some more thoughts, all being made up as I go...

Share this post


Link to post
Share on other sites
I'm actually concerned with the difficulty of prototyping stuff. The MVC stuff Ravuya mentioned was more tied to doing stuff like networking and persistence (e.g. doing it at the model level and having the display be just a 'filter' or 'view' of the model info.) I think it (or something like it) could offer some benefits for prototyping, though.

Basically, your game world would be "domain model stuff" (e.g., World, Player, Enemy, Item, Weapon, etc.) and rendering would just be a "styling" of that information (of course, the trick is making it efficient so you're not just looping through every single thing in your game model each frame.) So, conceivably your game *view* could just be a hierarchal property/value dump, or a very skeletal stick-person/debug art/whatever view, and the game code itself would be fairly agnostic of that.

Anyway, the interesting thing is that if you could work on the stylings independent of a running game, you could develop the style for "drawing an enemy of type X" entirely separate from an actual running model of that enemy type; you could develop the style itself while running it off dummy data that just conforms to the same basic interface as a "real" game entity.

Anyway, I'm sure this is all very vague, and I'll try and organize it after I get some sleep, but it's definitely something to think about. Getting gameplay up and running ASAP (ideally with code you won't have to throw away later) is really important to any project.

Share this post


Link to post
Share on other sites
Quote:

I'd be very interested in hearing what other folks out there have to think about this, though.


Web apps have grown from two basic bases. The first is a simple, extendable networking protocol. The second is a common, dead-simple client rendering engine. The sheer variety and demand of modern video games means that even basic infrastructure such as this cannot be simple and ubiquitous. Simple and ubiquitous barely supports things as simple as static webpages.

Personally, I'm looking for someone to create a rule modelling language that is as expressive for gameplay states as regular expressions are for text description.

Share this post


Link to post
Share on other sites
Quote:
Original post by SHilbert
I'm actually concerned with the difficulty of prototyping stuff...


Yeah, I'm definitely more interested in the prototyping aspect, or what I'd consider "lightweight" game development.

Quote:

Basically, your game world would be "domain model stuff" (e.g., World, Player, Enemy, Item, Weapon, etc.) and rendering would just be a "styling" of that information (of course, the trick is making it efficient so you're not just looping through every single thing in your game model each frame.) So, conceivably your game *view* could just be a hierarchal property/value dump, or a very skeletal stick-person/debug art/whatever view, and the game code itself would be fairly agnostic of that.


Exactly what I was expressing. For a slightly better formation of my thoughts, I'd point folks over to my blog.

Quote:

Anyway, the interesting thing is that if you could work on the stylings independent of a running game, you could develop the style for "drawing an enemy of type X" entirely separate from an actual running model of that enemy type; you could develop the style itself while running it off dummy data that just conforms to the same basic interface as a "real" game entity.


Yeah, I mention this in my blog post and in the other thread I've got going on a gamedev framework. That's exactly my intent.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!