Posts Tagged ‘rpg’

Unity game – what to do next, part 2

August 31, 2014

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.

 

Guards vs Skeletons

June 4, 2013

Hi folks,

So I’ve done a little more work on my project.  This time I’ve sandboxed the progress in a new scene, with a road and some buildings.  The main aspects of experimentation have been Unity 4.1’s new MecAnim animation system, patrol pathing, and basic AI for recognition, attack, retarget, knockout and respawn.

TL;DR – here is the video:

As you can see the combat behaviour is not totally optimised but the general idea is there.

In terms of working materials, I have used a couple of assets from the asset store (one purchased – the guard and associated mecanim animations, the other free – the skeleton model and animations), and also some AI scripts following a bread trail starting  here.  Working with the AI scripts was quite interesting.  Amongst the key learnings I gathered (or rather, the key bugs), I discovered that quite a few were simply due to the fact that I had transforms in the wrong location.  Making extensive use of Debug.Log statements to check that the flow of the script was working as I expected was very useful and helped guide me to avoid various pitfalls.  I also found that simply defining obvious booleans (eg, Engaging, Attacking, Friendly) was helpful for debugging.

Basically what I wanted to implement was the following – a situation where there are three types of creature: players, guards, and mobs (enemies).  Enemies view players and guards as viable targets, players and guards view enemies as viable targets.  If there are none of the other present, guards (or monsters) will path on a preset sequence of waypoints.  If a hostile rel them passes into their line of sight (I found that checking for ray collision was largely empty unless I raised the ray emanating from the creature a nominal height; this was due to the nature of capsule colliders I am using for creatures), or is sufficiently close (their “noise” > given threshold value) then they move to engage that target.

Once they are adjacent to the target they move to attack it (I found that I needed to reset the transform periodically for creatures when they were attacking, otherwise it bugged out, ie they did not stay fixed in place.  Even when I did this I became confused since it was still bugging out, but then I realised I need to fix the rotation as well.  So prior to attack I calculated the initial position and rotation information and then fed these as temp vars into the attack function).  If the target moves out of range they follow and re-engage.  If the target is reduced to < 0 hp it is destroyed; the associated spawn point for that target is then empty.  The spawn point then detects this and a cooldown timer is initiated.  Once this cooldown timer reaches 0 a new creature is popped at the spawn point and starts to patrol, etc.  As part of the spawn process the list of targets for the creature which struck the knockout blow is refreshed, and a new goal (hostile creature) assigned if there are any in range.  It then proceeds to attack the new hostile creature.

I decided that skeletons should have 50hp and guards 100hp.  They both do a similar amount of damage.  In the video you can see the cycle of destroy-respawn-destroy-respawn, an unending tide of guards and skeletons leaping to rejoin the fray to replace their fallen comrades.

One more thing is worth mentioning.  I also kept track of variables to make sure that the animation playing is appropriate – this is the MecAnim part of the picture.  So the guards and skeletons have state machines for their animations, as well as for their AI behaviour.

————————————-

I am reasonably satisfied with the outcome, but I know that in theory the implementation could be a lot cleaner.  My code is not totally unreadable but still is, for some scripts, way too long and should be written in a more sensible, concise format.  I’m also certain that in a few places I’ve written out the same functionality more than once; a bit more focus on reusability certainly would not go amiss.  And also redundancy – I’m fairly certain that the code is not as tight as it probably should be, in fact, I know that it isn’t.  This applies more generally to the project at large.  There are many places in my work where I’ve coded the same functionality for different things in different contexts.  Or even functions that have not been used.

So a little work needs to be done at some point on said matters.

In particular, todos that spring foremost to mind with this particular line of work (many of which, such as style, readability, best practice etc. I likely will not implement since this is primarily a “finding my coding feet” ongoing exercise):

  • make it clearer if a creature is in combat (ie, none of this running around in circles spontaneously business) – it could be that artifacts such as running around in circles occur because noise isn’t refreshed immediately for the goal creature when the original target is destroyed.  This could be fairly easily redressed.  Or maybe I might like to simply have a fixed (small) radius wherein if the goal is within that circle the creature automatically moves to attack (this is currently not the case, but it should be, and that is what noise/”sound” detection (generalisation of said idea) was supposed to do)
  • possibly aim to fix creatures in place during combat – try to make things more static
  • morale stat for creatures – chance to run away if allies nearby down / no support (possibly hard) or hp low; then move randomly away from attacker, or seek “wall” tagged object to attempt to throw off attacker?
  • knockout animation & possible option (if player dealt k.o.) for ability to loot the creature; then despawn timer prior to respawn
  • refactor the code to make some of the classes less lengthy and so that they have a more logical structure
  • subclass creature.cs (my main AI script) as part of a SFS_creature.cs script so that it interacts well with smartfoxserver
  • NPC_targeting.cs (my main AI targeting / listing script) – make this dependent more on “Broadcast messages”, possibly local messages.  There is a messaging system I am currently using for health bars – this however is more general and can be extended.  If the world becomes quite large and hence contains 100s of monsters, guards, players etc I do not want every single monster / guard / player to have a list of length 400 encoding and tracking the position of everything else in the world – that would be untenable.  But that is precisely how the program works currently.  Evidently this will have to be fixed, so that only enemies / guards in noise / detection / aggro radius are detected.  Or “targeting radius” which is larger than aggro radius.
  • Incorporate the idea of “threat” levels depending on which creature is damaging which – ie first calculated purely as a function of total damage dealt, then maybe factoring in threat generation abilities (eg taunt – sets to top threat) or threat reduction abilities (feint), and threat reset effects (moving beyond targeting radius – as per point above).  Evidently want the creature with highest threat to be the creature targeted.

The next part of the project will focus on hooking up a mysql database with the smartfoxserver software I am using as described here.  Basically I’d like to aim at storing 8 fields: username, password, spawn location (x,y,z) and last seen location (x,y,z).  Essentially I would like last location to be updated every time the player logs out, and then persisted in the database, so that when they log back in (if it is not a first time logon), they appear at that location.

If it is a first time logon they appear at the default spawn location, and last location is null until populated.

The architecture of the goal application will essentially be

client unity application <-> server SFS2X application <-> mysql database

with <-> denoting two way communication, the client application written in C#, the server application written in Java, as is currently the case; the new component will be the database.  Naturally a database can consist of more than one table, and more than 8 fields.  In a full blown, sophisticated application, there is no reason that all data about the players should be able to be stored in an appropriate database schema.  So certainly there is considerable room for extending this aspect of my learning, once I’ve managed to get this proof-of-principle up and running.

Consequent to this I might look at readapting this patrol example for SFS2X-deployed unity games, or something completely different.

Game Development #4 – Shop, basic dialogue, and game state persistence

May 26, 2013

I’ve made some further progress with my unity game.  Here is the latest demonstration video:

Previous videos in the series, in reverse order of appearance:

Bridge Battle

Animation and multiplayer demonstration

Transmission of player location via smartfoxserver

In this video, I demonstrate essentially integration of some functionality from a package from the Unity asset store into my game.  The features added are

  • an action HUD, with “examine”, “use”, “talk”, and “focus” as allowable actions.
  • the ability to shop a store
  • basic dialogue (managed as a state machine) – together with the option to switch from english to afrikaans
  • game state persistence
  • basic inventory and ability to equip items

The things that I would like to look into next would be, in no particular order:

  • The option to choose an avatar (or save game) on entry.  Perhaps allow multiple avatars per player, but have persistence of their state (like in a standard MMO).  Allow for different characters to be played (ie, different avatar appearance) but synchronise the chosen avatar across smartfoxserver so that all players see the same thing; this could be done, for instance, by indexing a set of prefabs which was the allowable avatar form list.  Use MecAnim to standardise animations across all avatars, so that there is no ambiguity when it comes to making a call to a player animation in order to do something in particular (eg walk, strafe, jump, run, fight (melee), fight (archery), fight (magic) ).  [This is in fact a great strength of the current incarnation of Unity, the ability to essentially map animations to different character frames]
  • NPC guards on a patrol path.  I thought I might be able to use Rain{Indie} for this, although that might be slightly over the top.
  • A better inventory system.  Allowing one to have object representations for items and mouseover text, if possible.
  • A character representation for item placement.  Allowing one to drag and drop items to particular locations on the character’s frame, or, alternatively, to be able to select an inventory slot and equip / unequip whatever is available in character inventory.
  • Monsters vs NPCs, with spawn points for both – for an ongoing pitched battle.

Unity Game – Bridge Battle

April 14, 2013

Hi folks,

So I have a new progression in my “mini-MOBA” series, here.

Previous videos in the series:

In the first video I demonstrated the starter town, avatars, and multiplayer transform sync.  In the second video I took things slightly further and included synchronisation of animations.

In this newest installment I do a few things.  First, I introduce tab targeting.  It is not demonstrated in this video but I can tab between multiple targets ordered by distance.  As part of the targeting procedure I change the appearance of the targeted on the client machine from white to green.  I also display the name of the character.  Finally I display the target’s health in the top right corner of the screen.

Second, I allow for use of the esc key to deselect a target.

Next, I implemented a messenging system (based on the bergzergarcade tutorial #44) on the local client that updated the target’s health bar (and the avatar / prefab’s hp) every time an allowable attack (within 2.5 units, and facing the correct direction) was made on it.  Consequent to this I implemented a secondary messaging system to send the information to the server, and tweaked the server code so that the target’s client would have the updated information for their health bar.  This is demonstrated in the video by my pitched bridge “battle” where as you can see hit points are being decreased over time on the other screen when I make an attack on one client relative to the other.

Finally, I made a hodgepodge attempt at attack animations.  This entailed alteration of the state machine for the thirdpersoncontroller script.  The results were not perfect; the entire animation does not play prior to returning to CharacterState.Idle and the animation synchronisation information has not been transferred.  These are minor matters to be fixed.

Also another bug which is not shown in the video, was that I haven’t altered my code to allow for the logoff or disconnect of another player, which might cause difficulties.  I will deal with this matter prior to the next step in the project, or eventually, anyway.

Learnings from this work were firstly, the DoNotDestroyOnLoad for a gameobject – I found out that all the Start() functions of gameobjects are called even in scenes that have not been loaded yet.  I guess the alternative is to use an Awake() function?!, but I found that one of my gameobjects was being initialised and then being destroyed when I loaded the very scene that it was in! – very frustrating.  But when I found out what object it was (the health bar) the fix was surprisingly easy.

A second learning was the power of the statemachine in terms of driving object behaviour – this is still something I need to become more adept in.

Thirdly, it was very informative to really examine the workings of the server code, in terms of introducing my own messaging functions to implement health synchronisation / modification consequent to a melee attack.

Next on the agenda, after fixing the bugs:

  • fix the attack animations
  • allow for player logoff / dc

These would be:

  • Allow mouseover target skin modification and mouseclick targeting
  • Respawning (destroy playerobject & recreate when appropriate)
  • GameHUD update
  • Implement NPCs as “SpawnNPC” script managed by the server (don’t want multiple copies of same NPC per client instance!)
  • Implement inventory for players
  • Implement “shops” – I probably will not require currency at this stage but just allow them to be storehouses / other inventory screens
  • Allow for player chat (global)

Then, further afield:

  • Allow for conversation with NPCs
  • Monsters
  • Quests
  • Advanced HUD (mini-map in top right hand corner)
  • More trees, buildings, environmental features and places to explore
  • Leveling system
  • Character screen
  • Quest log
  • Inventory screen
  • Stat system
  • Item buff system
  • Basic missile combat
  • Basic magic combat
  • Currency (game) for items from NPCs
  • Cooperation / group adventuring
  • Arena zones only for player-player combat (default atm is global)

And in the very distant future (subject to a great deal of change):

  • Freemium implementation
  • Special effects for magic / melee
  • Special moves (melee eg whirlwind, charge)
  • Special ranged attacks (fireball, lightning, …)
  • Customised key bindings
  • Customised blender models and animations …

Anyway I’ll see how I go with this.  Very early days as yet.  I might well return to the bergzergarcade tutorials if my progress starts to slow considerably.  Alternatively there is something to be said for putting this project on hold, and instead looking again at Google App Engine.  I have a few ideas there that I’d like to investigate further.