Full Script Game Logic

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Full Script Game Logic

      Hey again,

      I have been thinking about how I would make an editor that could truly make a game completely from script.

      How would you guys go about it? I assume that asside from actor files, and level files, I will need to make something like 'scenes' that will be responsible for creating views and setting states in Lua.

      right now I create my views and set states in C++, this is ok, but in order for me to make an editor that will truly require the user to not touch C++ code I will need have these scenes available in script.

      *Edit*
      Maybe the way I am thinking about it is weird, in what process would you guys do this?
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz

      The post was edited 1 time, last by mholley519 ().

    • RE: Full Script Game Logic

      It really depends on how far you want to take this. My approach is to layer everything. I have a very low-level layer for things like the OS, utility functions and classes, etc. That's the Utility layer. On top of that is another layer that's in charge of solving larger yet still generic problems. These are typically self-contained modules that require the Utility layer but don't require each other. My resource system lives here, as does my event system, process system, core Lua system, etc. On top of that is the Core layer, which defines all the basic game architecture. My Application, Scene, and Logic classes are all here as well as my actor component system (I call them Entities but the principle is the same). My World classes are also here.

      The fourth layer is something different depending on the game. Abstractly, I've been calling it the Genre layer. The idea is to make a layer for each major type of game genre. So there's an RPG layer, a Simulation layer, a Platformer layer, etc. Each layer defines the common code you'd see in any game of that type. For example, my Simulation layer has ways of defining statistics on objects that can interact with other statistics in meaningful ways. This creates an economy of statistics that are used to drive entity behavior. The entire system is defined and configured in data. As another example, my Platformer layer has code for handling different types of common platformer mechanics, like moving platforms, spring boards, gravity, collectables, power-ups, etc. An RPG layer would likely have a quest system. These are all things that any game of that genre needs.

      The fifth and final layer is the Game layer. This is where all my game-specific code lives. This layer can be very small in the case of games that just implement the idea of a genre, or it can be the largest layer of all, especially when you include all the Lua code. Typically, I start out with a simple skeleton game and build stuff with Lua. The Game layer C++ code is maybe 100 - 150 lines of boiler-plate stuff (mostly overriding virtual functions to instantiate the appropriate factories). As the game gets more complex, so does this layer.

      Sometimes I bypass the Genre layer entirely if nothing seems appropriate. For example, I'm writing a chess game right now that has no Genre layer, it just comes directly from the Core layer. If I were into writing board games, I would like write a Board Game layer and use that, but this is just an experiment so I chose to skip it.

      I think once you have a good, solid Genre layer for the type of game you want to make, you can start building an editor that allows you to build that style of game. For example, an RPG has to have a quest editor. The Sims Medieval is pretty light in the RPG department, but even we had a custom quest editor. Simulation games need a way to attach stats to entities and have them interact with each other. If you don't have a good Genre layer and good tools that support your vision for a style of game, you'll always end up writing a bunch of code.

      For example, look at Starcraft's editor. It's really good at editing and making RTS scenarios. You could replace all the models and all the tuning and have an RTS that feels completely different without have to touch any code. But you can't use that same editor to make an FPS or an RPG or a platformer without writing a whole bunch of code.

      One you have the Genre layer nailed and all the editing tools in hand, everything else becomes attaching scripts that you write for special occasions. Then you're only really writing game-specific C++ for performance reasons. That's effectively what we did on Rat Race and close to what we're doing on The Sims.

      The line between script and C++ code is a hard one to define. Each has their advantages and disadvantages. I tend to lean towards C++ more than the typical gameplay programmer, but I have my reasons (which is a longer debate).

      Hope that helps. :)

      -Rez
    • I think the Unity Engine has pretty much accomplished this difficult task, with a few issues left outstanding IMO. In a nutshell here's what I think they did that made this possible:

      1. Create an engine that could be extended easily with a scripting language. In Unity's case you can even choose the scripting language - C#, Java, or something called Boo that I've never really used.
      2. Make sure that the editor itself can be extended with the same scripting language.
      3. Create a core architecture based on the Actor/Component model, and allow developers to customize or create their own components.

      Now, there's one more thing that I feel is similar to Rez's "Genre Layer", but much more simple, that Unity doesn't really provide (yet), and that's a "World Visibility / Streaming" hint, that optimizes larger levels to allow for interior, portal based visibility systems as well as outdoor, open world, PVS style visibility culliing systems. This type of hint could exist as a component attached to the loaded world, not a singular object.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • So you are saying that basically the way that Unity is able to cover multiple different genres without ever specifying a coding a specific 'genre' layer is by allowing for user defined components?
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz