What gamedev can learn from the web

I think SHilbert has been looking into the Model/View/Controller pattern as a means of game development.

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 &#106avascript-like language for behavior. Something along the lines of XML/OpenGL/Python or something...

could you consider a scripting language (python, lua) to be a controller?

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.

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

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...

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.

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.

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.

Quote:

Original post by Telastyn 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.

That's kinda missing the point. I'm not looking for a generic, all-purpose game engine. I'm more interested in a toolset for rapid game development, in the same vein that desktop apps (XAML) and the web (HTML/CSS/DOM) fill. I think it's a little presumptious to suggest that games possess more "variety and demand" than the average rich-client app or AJAX app.

Wait, you say, a game like FEAR is far more demanding than any word processor or a web app like GMail. Yes, more demanding in terms of physical hardware resources like CPU cycles or video memory. But are games significantly more demanding in architecture? I don't think so. There's far more going on under the hood of MS Word or Outlook.

So, if XAML could be used to help design rich client apps, why couldn't an equivalent be used for game development?

Quote:

That's kinda missing the point. I'm not looking for a generic, all-purpose game engine.

In a sense, you are [smile] Maybe I'm suffering from tunnel vision, but you'll need to have some supporting components (engines) to run your 'rapidly developed' content. HTML/CSS/DOM needs a client runtime (your browser) which takes care of the view part of the MVC pattern, as well as the controller part for most static webpages. I'm pretty sure XAML also needs an extensive runtime aka engine.

It's an interesting comparisson and I think there is in fact potential for this kind of game development, but there's one problem. The "web 2.0" model hasn't changed too much over the past 5 years (other than some fancy wrappers and newly coined older paradigms) and it can afford not to change because the main goal is information presentation in a rather static domain, as you already pointed out.

Games on the other hand are developed in a much more volatile domain, with significant hardware changes every few years and a continuous pressure to get the most out of ever evolving hardware for a broad variety of interaction models. This would make it extremely difficult to create and maintain a runtime for your rapid game development environment.

I'm definately going to think about this some more though, a very interesting concept!

Perhaps I'm a little presumptuous, as I don't do much work with webapps, but I would be highly skeptical that a word processor or GMail (or even Word or Outlook 15-20 years ago) were/could-be effectively rapidly prototyped beyond 'look an edit box!'.

Quote:

Original post by Simagery For a slightly better formation of my thoughts, I'd point folks over to my blog.

Quote:

What are my credentials? I’m currently employed as a Senior Field Application Engineer Solution Architect at Electronic Arts.

Quote:

While I’ve never actually shipped a title myself, I have helped many game teams get to gold in one way or another. So, take my opinions with a grain of salt as they definitely originate more from my theories and superficial experiences than any kind of in-the-trenches, first hand experience.

I knew that such a shiny silver bullet just had to come from an architect. :-)

Quote:

Original post by dmikesell Quote: Original post by Simagery For a slightly better formation of my thoughts, I'd point folks over to my blog. Quote: What are my credentials? I’m currently employed as a Solution Architect at Electronic Arts. Quote: While I’ve never actually shipped a title myself, I have helped many game teams get to gold in one way or another. So, take my opinions with a grain of salt as they definitely originate more from my theories and superficial experiences than any kind of in-the-trenches, first hand experience. I knew that such a shiny silver bullet just had to come from an architect. :-)

Thanks for visiting the blog! [grin] And the architect thing is very new (last few weeks). And I don't architect technology, per se, I help teams plan their workflows, which is all based on experience working with other teams and refining their workflows. So, it's a spiffy title no doubt, but if we met in person I'd say it with a little false modesty and a wink... ;) But I know exactly what you're hinting at...

Seriously, though, I'm not looking to craft some panacea for game development, just an efficient toolset for my own experiments. As mentioned earlier in this thread (or maybe the thread referenced at the top), this isn't (yet) intended for big-time commercial game development, but really just my own personal one-man efforts.

Quote:

Perhaps I'm a little presumptuous, as I don't do much work with webapps, but I would be highly skeptical that a word processor or GMail (or even Word or Outlook 15-20 years ago) were/could-be effectively rapidly prototyped beyond 'look an edit box!'.

I don't know if those specific products were developed this way, but the current methods of Test Driven Development would argue quite the opposite, that the bigger, more complex applications benefit most from what is essentially rapid prototyping. You do have to decompose the app into pieces though, which means in reality you're prototyping a lot of individual components. This is very similar to the processes being employed by quite a few game studios these days, BTW.

Quote:

In a sense, you are [wanting a generic, all-purpose game engine.] Maybe I'm suffering from tunnel vision, but you'll need to have some supporting components (engines) to run your 'rapidly developed' content. HTML/CSS/DOM needs a client runtime (your browser) which takes care of the view part of the MVC pattern, as well as the controller part for most static webpages. I'm pretty sure XAML also needs an extensive runtime aka engine.

Very true. What I should have said (and what I actually meant) was that the point of this thread is not the implementation, the runtime engine, but more the language/tools for creating at a "mid-level," i.e. HTML/CSS/DOM. In other words, the web developer does not care how IE or Firefox renders a div on the screen, whether with hardware-accelerated triangles or a pixel-by-pixel software rasterizer, but primarily cares about the concept of the div and its semantics. (Of course, the reality is that these things do matter and the web developer, like the game developer, does care, but I'm not too concerned with those aspects in the context of this thread. I know how to craft a 3D API if that's what I need, or a scene manager, or thread scheduler, or terrain renderer, or a tile-map renderer, etc.)

Quote:

The "web 2.0" model hasn't changed too much over the past 5 years (other than some fancy wrappers and newly coined older paradigms) [...] Games on the other hand are developed in a much more volatile domain [...] a broad variety of interaction models.

Maybe you've been playing different games than I have over the last five years... [grin] Seriously, I've been staring at AAA, commercial console titles for the last five years and have not seen a significant change in the architecture of games. If anything, the ones that have been moving forward have been moving closer to a paradigm like I'm describing.

In fact, the parallels are even closer to the web than some may realize. As target hardware for games have become more powerful (as web browsers have become more standards-compliant), game developers have adopted more established software engineering practices (web developers have adopted more standards-based designs). Most senior game developers are well aware of the ideal software development process (most senior web developers are fully conversant is 100% W3C standards-compliant markup), but most accept that concessions have to be made in exchange for performance and time-to-market constraints (but most accept that not all users have up-to-date web browsers or that all clients will pay for the extra time and care for accessibility).

I'm definitely not going to pretend that compromises aren't necessary. But we should be striving to push more and more of those compromises into the implementation and out of the design. The new "low-level" programming is OpenGLES/D3D and shaders, mid-level programming is heavily C++/OOP, and high-level programming/design is in the scripting languages and tools we create. I'm just looking to shift that slightly and make that mid-level look more like HTML/CSS/DOM and less like the unmanaged environs of C++.

Quote:

Perhaps I'm a little presumptuous, as I don't do much work with webapps, but I would be highly skeptical that a word processor or GMail (or even Word or Outlook 15-20 years ago) were/could-be effectively rapidly prototyped beyond 'look an edit box!'.

You'd be surprised how much prototyping is possible for extensive webapps. Looking at Visual Studio 2005, there's a wealth of prebuilt components for both GUI and DB and the same also holds true for PHP. I once prototyped a basic IMAP mail client in half an hour or so, which can be done because of the high level of abstraction typical web platforms have to offer.

Quote:

Maybe you've been playing different games than I have over the last five years...

We've been playing a different game alright [smile] I've been looking at web apps mainly for the past 5 years, so I guess it partly comes from the familiarity of things we work on that they may appear a bit stagnant. I can't comment on the architecture of games, but when I look at the high-level paradigm, I'd say the "web2.0" model still is much easier to abstract into HTML/CSS/DOM.

Web apps adhere to the relatively basic http client-server interaction model. However flexible that may be, it takes a lot of the 'silver bullet' out of developping webapplications, since ultimately you're simply serving some texts fitted with HTML/CSS markup and some DOM/&#106avascript code (discounting Flash/Java/ActiveX content for simplicity) to a client that isn't too fancy either. I'm not saying writing a webbrowser is trivial, but it's core functionality basically comes down to 1) rendering the page, 2) handling the simple navigation/form submits, 3) providing some scripting host and 4) hosting active content.<br/><br/>Though the parallels are there, I'm not sure the functionality of your regular game engine could be separated enough from the mid-level you'd like to replace with a more HTML/CSS/DOM type model. I was first thinking that XAML does it too though, but that also builds on the relatively straightforward interaction paradigm of a form with its stuck-on components. Any underlying functionality also still has to be handled in C# 'Code Behind' files.<br/><br/>As I said, I like the idea very much, but I'm afraid don't know enough about commercial 3D engine design to assess if it would be possible to do this. When you look at a game sufficiently high-level I'd say it should be possible, but I think the restrictions put in place by such a new mid-level won't work well with the myriad of interaction models used in games. On the other hand, using a kind of 'Code Behind' approach for implementing solutions to the compromises imposed by the limitations in this mid-level might just do the trick.<br/><br/>Well, at any rate I'd say this concept deserves some thorough investigation [wink]

I wrote a post relating to this on my (recently re-animated) blog. It's not exactly the same thing that Simagery is saying, but pretty it's close and it's relevant.

I'm really not too hot on frameworks for behavior, personally. If there's anything we've learned from the profusion of CMS systems for the Web, there are about a million ways to define similar domain behavior, and it's difficult to label any one as "the best". That being said, I'm sure you could produce something that saves time for 80% of the people for whom it's a good fit; I'd just be wary of making something that looks like it might be helpful to users until they get into it in detail and they find out that it's not flexible enough on some particular after investing a lot of time in conforming their game to your framework.

As far as rendering (which I go into in the blog post) I think that anything that's too frameworky is going to cause problems (as per the already-mentioned difficulty in making a 'universal game engine'), but of course most games ultimately DO boil down to the commonality of GL and D3D, so maybe we can look for ways of looking at those APIs from different angles that let people be creative without imposing too much structure on them.

Damn this thread! It's preventing me from getting any work done [smile]

Anyway, I've been tinkering with my own engine to see how well this concept would go with it. Since I'm already using Scene objects for doing my rendering and interaction, I think the most natural way of implementing this concept would be to creating some XML-style markup language for describing the scene, inspired by ASP.NET webpages. Something like:

<scene>  <rendering renderer="default">    <environmentmap type="auto" />  </rendering>  <camera class="some.package.FreeFormCamera" />    <entities>    <entity type="default" behavior="rotate" onLoad="doSomething();">      <model type="prefab">some.package.Grid</model>    </entity>    <entity type="custom" class="some.package.CustomEntityImplementation">  </entities></scene>

This is pretty lowlevel so far, but ideally a system like this should be extendable, so you could define your own 'tags', like instead of the grid entity defined above. For flexibility, the behavior code could be contained in either:

1) (Custom) events, like the onLoad thing. This could involve scripting

2) In a behavior attribute, which points to a set of predefined reactions to events

3) By a custom implementation of an entity subclass


This takes care of a good part of the basic model and controller needs for the proposed MVC pattern and it should be pretty doable so far. What I can't place yet is where to handle specific rendering parameters. You should be able to specify styles for entities, so this could be done with some CSS style language that defines textures, shaders and other material properties.

I like it better every time I see it [wink]

Glad to hear that some folks are latching onto the idea. SHilbert, I'll be sure to read over your blog post in the next few hours. It doesn't surpise me that others are thinking along similar lines.

I find it useful to consider two scenarios of existing tech similar to what we're describing here. One is from XAML, the other is from web2.0.

First, a bit about XAML... one of the very satisfyingly simple aspects of XAML is that it basically takes a markup tag and translates it directly into an instantiated class of the same name. There are some additional subtleties related to namespaces, and some syntactic tweaks for complex types, but essentially you get the 1-to-1 of tag to class.

I find this very comforting, personally, as about 6 years ago I formed a group called OpenSWF.org (now defunct) whose goal was to maintain an open, standardized specification for SWF (Shockwave Flash) along with an open-source player. For those that don't know, SWF is a "tag"-based file format. In this case, it's not tags like markup languages (nested), rather SWF tags are equivalent to IFF chunks (i.e. a type field followed by a size field followed by a data payload). Are designs at the time were for a Java-based SWF player that communicated with what we dubbed a "Tag Server." Basically, if you were playing an SWF and encountered a tag that was unrecognized (from a newer version Flash file, for example), the player would contact the Tag Server and download the corresponding class/jar for the tag. Utilizing Java's dynamic class loading we were able to implement this trivially.

I've since toyed with applying the idea in my "day job" as a game developer. I've not worked on any Java-based titles (or .NET-based titles), just classic C/C++ console/PC titles. As a result, there's no simple convenience of dynamically loading classes. Of course, you can kinda fake it by using techniques similar to COM with DLLs (or whatever the appropriate platform-specific mechanism happens to be).

To bring this back to XAML: this is essnetially how XAML works. Again, like Java, XAML leverages the advanced facilities of the underlying language/runtime, .NET, to (almost) trivially provide this feature. XAML actually "cheats" in that it primarily produces source files for compilation (though it can function dynamically if desired).

My point of this lengthy explanation of backstory: my concern is not so much with worrying about defining a specific language that fits everyone's needs. That's why it's more of a framework. The language, the "tags" so to speak, can be wholly defined by the individual implementation of the framework (or extensions to a common framework implementation). It's more the notion of having a runtime that consumes the tags in a pre-defined (standardized) way; it's about having a notation that anyone could look at it and understand what was happening without knowing the specific tags or their implementations. In other words, the notation is self-documenting by-example and by the fact that it's human-readable and intuitively structured.

My second scenario is from web2.0. Specifically, I'm thinking about the elegant AJAX webapp called TiddlyWiki. This webapp takes the standard notions of a "webpage" and an "HTML document" and turns them on their head. It's an excellent example of how the "structure" part of the three-pronged web2.0 idiom does not have to necessarily apply to the physical document structure, but rather the logical data structure (DOM as database). Specifically, TiddlyWiki uses div tags to represent little mini-docs in a database (what they call Tiddlers). These divs are then manipulated through the DOM to be displayed, edited, marked-up with Wiki syntax, searched, etc. The result is webpage that's a stand-alone application not requiring any backend server. Very cool...

And this raises a final, critically important point. In my comparisons to web2.0, I think I've given the impression that I want to be able to wholly create a game inside of this paradigm. I think this should be possible in many scenarios, but I also realize that "one size fits all" actually means "one sizes poorly fits many." Much like XAML, I would expect individual games to introduce custom tags that implement dramatically different features. I would also expect games to implement the "webserver backend" equivalent of web2.0 as well. Whether that backend is implemented wholly in the markup language (like TiddlyWiki), in an intermediate language in the engine (like PHP), through extensions to the engine (Apache mod_rewrite, etc.), or by customizing the engine (IBM WebSphere, etc.) is somewhat irrelevant.

At the end of the day, though, this is lots and lots of talk, and I need to put-up or shut-up... which means that this weekend I need to put together a prototype to actually test some of these ideas. Who knows, maybe I'll find it to be piss-poor... [grin]

After some additional thought on the subject... what can we learn from the web? Well as mentioned we need a browser... so just some basic thoughts on architecture of that browser... again, let us look at the web.

First off, I stand by needing to establish a GOM - Game Object Model. But that's a big can of worms that can stay freshly sealed for the moment. While some have mentioned that perhaps every game can't support a GOM, I think that's nonsense... if you actually skim over the spec for the DOM at the WC3. It's designed in it's very nature to be open to any kind of displayable content without restricting content possibilities. Again... a can of worms for another time...

Back to our "Browser" (OpenEngine) basics...

At the base level you would have some sort of core. The core facilitates the configuration of the actual engine and would then also create support for an API for interpreters. Interpreters would actually do the heavy lifting. This creates the flexibility that is needed to support different peoples choices of languages. But supporting a plugin style architecture, if somebody wishes to utilize the engine with what they know, they need only use an interpreter for that language.

There would be two divisions: Structure/Display and Scripting. Again with the browser analogy, we have XHTML/CSS and &#106avascript. We haven't nailed down WHAT XHTML/CSS would be represented as per se, but that doesn't explictly matter right now. <br/><br/>The scripter could be handled by an interpreter of any of the languages that currently do that job. People have mentioned Python and Lua so far in this thread, an others could be added via the interpreters. The core unites the scripting with the structure/display aspect where appropriate.<br/><br/>Next you'd deal with the actual Structure/Display plugins. First we have our XHTMLforGames. This would be loaded by a Parser for that type which would then feed that information to the GOM constructor which would universalize the information and check for validation of the content (assuming it was taken to the extent that we'd were using validatable standards to begin with). The constructor then outputs the GOM which can then be actively manipulated by the scripting. The GOM is passed to a rendering engine that interprets our GameCSS to apply styling information to our content and then the GameCSS styled GOM is passed to the actual rendering agent that would do the rendering.<br/><br/>Each of these things would be modular really, so as long as the API that was established by the core of the program was clear as to how the different parts interact, then one could change the actual render or optimize any given part for a particular situation. The key to usefulness would be to have a solid set of stuff "out of the box" which could then be used for prototyping and then that prototype can be refined to an actual game within the same architecture because all the parts can be manipulated independently to achieve the appropriate results.<br/><br/>This excites me in the pants and is detracting me from other work... so yeah... there's my two cents... PLEASE expound upon this. Keep the ball rolling.<br/><br/>-C. Richardson