Unity game – what to do next, part 2

In my last post, I outlined where my thinking on my Unity project was about six months ago.  In this post I will outline my current thinking as to where I’d like to take my game next.

Currently, the state of the project is that I have a multiplayer game, capable of supporting about 6 rooms of 15 players apiece on a small server sitting in a server farm somewhere, and open to the internet.  In the process of building the project, I have matured slightly as a software engineer and game designer, to the point where I have been able to build data driven games and deploy such on cloud architecture.

So that’s a good start, however now is the time to decide what sort of data driven multiplayer game I’m going to build, and I think I have a much better idea now than I did a few months ago as to what it should be.  In particular, I don’t want to build another MMORPG, as high quality games of that type have more or less saturated the market now.  Rather, I’d like to do something slightly different, and in order to explain my thinking on the subject, I will need to make a slight digression.

Over the last couple of years, I’ve been involved in a return to an old hobby of mine, role playing games.  And I don’t mean the world of warcraft style role playing game – rather I mean the old school variety, the TSR, wizards of the coast dungeons and dragon style game, where one person is the dungeon master, you sit around a table, drinking beer / energy drinks, and then pretending that you’re in a dungeon, or in a city, or travelling through the wilderness of the forgotten realms, or eberron – looking for treasure, adventure, and trouble.  Essentially, a collaborative storytelling experience.

Fairly recently, Hannu Rajaniemi gave a talk in which he discussed the future of the book.  In passing, amongst some other very interesting things, he mentioned role playing games as a form of storytelling.   Consequently, this led me to think – can the medium of computer games be focused more on fostering this sort of experience?

This is not ground that is completely untrodden, of course.  Roll20 is an ‘app’ or project / site that is geared around providing a tabletop gaming experience for gamers who are geographically separated.  Over the last year or so, as a matter of fact, I have been fortunate enough to have been involved in an occasion session or so of this application.  It makes for quite good fun.  Also, Neverwinter Foundry allows players to craft their own dungeons for other players to experience.

So I guess I was wondering whether I could build my own dungeon creation engine type of experience.  And I have to admit that the idea has me slightly hooked.  In particular, I would like a game where:

1. Players can log in and load a pre-exported map into a game room.

2. Players can take the role of a ‘player’ or a ‘dungeon master’.

3. Players can work on maps and export them while in game.

4. ‘Dungeon masters’ can continue working on / tweaking maps while ‘players’ are in them.  In particular, adding corridors, rooms, passages at will, adding monsters at will (drag and drop), adding chests, traps, furniture, trees, buildings at will.

And two other nonessential, but nice to have features:

5. ‘Dungeon masters’ can embody monsters, or groups of monsters, and move them around in first person, etc.  Eg NPCs.

6. ‘Dungeon masters’ have control over what ‘players’ can see and what they can do to a limited extent. eg, viewing monster hit points, moving other characters around (hopping into another characters first person perspective or drag selecting multiple characters to move).

So that’s the general idea.  Obviously there is a great deal of fine detail on top of that outline (eg, a ‘market’ of pregenerated player maps, a ‘favoured objects’ list for level design, menus and submenus for selecting objects to drag and drop in game, database / object persistence and handling, etc), but that’s what I’d like to build.

Evidently that is a mammoth task.  But I think the general approach to take would be:

  • Represent all objects and their locations as values in a database.  So when ‘exporting’ all that is truly exported in a database configuration file.  And when performing a modification to a map, all that is happening in terms of the metadata is that the map / data configuration / sql file is being updated.
  • For instance, each client could have some directory where objects are stored by a standard numbering system common across clients.  Then the database could contain a lookup table – eg ‘1’ would represent a goblin, and ‘2’ would represent a table.  Each of these items could have attributes assigned, for instance, position (x,y,z) and euler rotation coords(u,v,w).
  • For dungeon walls, or dungeon floors, the database problem becomes perhaps slightly more challenging, as one is interested in having multiple objects linked in a certain way.

To start off, what I’d like to do would be to allow for a game master, in game, to paint out a tiling starting from a world where there is nothing but a limbo-scape of featureless squares.  In this way, one has the basis for a game of the nature outlined in points 1 to 4 above.

One approach, and probably the one I will attempt to take, would be to allow the dungeon master to select a texture from a palette – eg ‘grass’, ‘stone’, etc, and then, using the mouse, select an area of the ground where they’d like to apply the texture inside – so essentially drawing a polygon which is painted inside.  I’d also like the option to ‘snap to grid’ for a more polished look if they want it.  The texture would be looked up relative to a folder using a ‘key’ for the texture in question, sitting in a table in the database, and assigned to the interior of all of the polygons associated to that texture, whose points (and order of same) would be stored in a separate table.

Then, to export, the game would export the tuples (polygonId, polypointId, textureId, pointX, pointY), and store this to a sql file, which could then be used by the player to reload the map.

 

Advertisements

Tags: , ,

One Response to “Unity game – what to do next, part 2”

  1. An open source in-game unity editor | Where's my hat?! Says:

    […] / game where dungeon states can be saved or persisted. Regardless, as I mentioned back in this post, that seemed like an awful lot of work if I sought to build such from scratch, and I thought that […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: