Grid: Background
I’m working on a puzzle game in Unity. It’s based on the product of a self-imposed game jam challenge, called Grid. In the game, the player controls a ball which bounces along a grid of interactive tiles. A prototype image is below:
Initial Release
My strategy at this point is to release the initial game on iOS (and perhaps eventually Android) and then add-on packs with new art, sound and puzzles.
The initial game will either be free or very low price point (haven’t decided on financials). It will include at least:
- One world theme
- 6 varieties of interactive tiles
- A selection of puzzles depending on the price point
The worlds consist of unique:
- Background art (3D)
- Music
- Shaders
The interactive tiles consist of unique:
- Mesh
- Textures
- Sound effects
- Behaviours
DLC
The problem I have is in planning for DLC. I have very little idea how I’d approach building the game to enable DLC to slot seamlessly into place. I don’t know if there are any platform specific oddities I need to consider when planning for expansion packs. I have never done any of this before.
Expansion packs will all include:
- New worlds
- New tiles with new behaviours
- New sounds
This leads me to think that the only viable solution to the basic framework is to store tiles and worlds and anything expandable in resources to be loaded at run-time.
The next step is to try to conceptualise how the architecture looks.
For starters I have no idea how a game supports DLC. I am assuming when you purchase the DLC a package of some sort is downloaded which extracts the contained files into the appropriate folders. If that’s what’s happening, then DLC could get by doing something like:
- Game peruses resources for .DEF files describing available Worlds
- .DEF files include pointers to level-select screen art, and pointers to individual level files
- Levels are written in an extendable format, probably something simple like hex codes for the tile type
- Each world also contains a file cataloguing tile-types to those hex codes
- Tile types are behaviours inherited from a base and stored in a master folder into which new tile types can be dropped
Glancing at it, it feels like it meets the following criteria:
- Worlds can be expanded at any time by dropping new world.DEF files into the appropriate resources folder, so long as the art and levels referenced in that world.DEF file are also present.
- Tile types can be expanded at any time simply by dropping new monobehaviours into the appropriate resources folder, and again ensuring tile art/sound effects are present.
- There’s no dependencies between worlds or requirements to purchase DLC in any order.
- DLC which shares new tile types can harmlessly over-write any existing types.
EXCEPT that I don’t know how to deal with the new tile types. The game can’t compile downloaded MonoBehaviours, can it?
Perhaps the game could employ some kind of required title update that implements the new tile types, and they’re utilised by the DLC, with any attempt to download the DLC forcing the player to do a title update?
The Question
The purpose of this thread is to get some advice from any who might have been down this road before. Historically, my games have all been ‘hard-coded’ rather than data driven, so this is kind of new to me and requires thinking about the content in a more nebulous and independent way. Maybe planning for DLC with my first commercial game release is foolish, or maybe I’m doing the right thing by planning ahead. I really do not know!