Prototype sampler # 1

So, finally, I’ve completed my last major developmental milestone and I think that deserves a post. 🙂

The above video simply shows the playthrough of some of the game mechanics. The quest has not been fully written yet, and though all of the game mechanics are working, they’re not readily apparent without some introductions. The video is mainly to see how adventure and combat are blending as one piece.

I’ve slaved away on numerous aspects to accomplish all the major milestones I had set out to do. There were a few additions to these, but they were minor changes, and all in part of the iterative process of figuring out the closest gameplay mechanics I wanted to implement in Unity.

Though my work isn’t done yet — there are still UI issues I need to sort out — and there are still some niggling bugs present in the prototype, it is largely playable. By ‘playable’ that means you can run around, talk to people, and shoot Robots, and get shot back. You can plant a bomb, blow it up, and you can blow yourself up in the process as well. You can ‘pox’ a powerlet to get energy, you can buy and use meds to heal yourself. Frankly, a few months ago I didn’t think I could end up saying all this in one paragraph.

Most of the joy, and fear, of this prototype has been the implementation of a bespoke AI graph framework. It’s a joy because it actually works; it’s a fear because it sometimes feels too deep for me to always grasp its innards when some things don’t go right.

I’ve gone through mounds of halved/quarter-A4 to-do sheets with heaps of orange highlighter marks signifying all the big and small tasks or goals I needed done. There are so many disparate systems working that that if I didn’t have a calendar tracking my progress, I wouldn’t be able to grasp what I myself had accomplished.

For example, here’s a quick run-down of the aspects.

  • Asset creation.
    • I’ve heavily used Janus to break out animated sequences.  Using FORFILEs, a Janus looping construct that iterates through the lines of a file, creating an animated character, such as the Player character, was simple as I needed only to set up one angle and let Janus break out all the other 15 directions. Variable frame ranges for a particular animation were also taken care of using the same principle.
    • Janus was an important cog in the making of the prototype because of the amount of iterations for the scenes. An element would sometimes become designated as an interactable element, which had to be split from the main scene and rendered separately.
    • NPC/Robot portraits had a separate animation and render, and specifically had to go through post-processing.
  • Tiled was used in making the maps, and Rex’s TMX Importer was used to carry that information in C2. I had to do some modifications to the TMX Importer to enable the retrieval of the Tiles and Objects image source. Tiled enabled me to experiment and implement concepts by introducing certain datatypes for the engine’s use, which informs me of how I may implement the maps in Unity.
    • This had to be balanced with Game Data Documents which are comprised of text-based files of varying structures. These Data Documents are the immutable attributes used by the systems. In the beginning, the data would come from different sources; one would be defined in the TMX, while others defined in a CSV table. As I progressed, I refined the categorisation of data.
  • The in-game Inventory system was one hell of an undertaking, The Inventory system is connected to the Trade system, which is further split into two variants: the Container system, and the Merchant system; the former simulates the ability to store items in ‘containers’, and the latter simulates buy/sell transactions with NPCs. Merchant data, like price, buy/sell limitations, and price adjusters are tied to tables and the NPC entity as defined in the TMX.
  • While the code related to the movement was entirely specific to C2, I had to nevertheless overcome these issues to get a working prototype. Pathfinding needed some optimisations, behaviours related to physicality of entities needed to be coded in relation to the established movement behaviours. This aspect will largely be replaced by Unity’s navmesh, in addition to a target grid overlay that I may custom-build myself.
  • The Action Strip (a.k.a. Astrip) system — the method for interacting with elements in the game — was developed to be authored using text files (like most systems in the game).It serves as the hub for all ‘adventure’ interactions. It was also designed to be generic so that the display of interaction results can be be tweaked directly from the text file. For example, a ‘look’ action,  at an object may initiate a display of a description, or the narrative box, or initiate a dialogue, or anything else that has been allowed in the engine.
  • The Convo system was another early development. Some additional Python code was necessary to convert the authored .graphml files (using yEd) into a Markdown format (for readability in a text editor). However, the development of the AI graph framework proved that the Convo system was inferior, though both used node graphs. Although the Convo system has not yet been upgraded to use the same (or similar) framework of AI, this would eventually be done when the port to Unity is made.
    • The Convo system could be called by the Astrip system.
    • The Convo system also allows implicit trade of items. For example, if through speaking with an NPC, it gives you an item to be used. The Convo system communicates to the Inventory system and places the item in the Players inventory.
  • The AI system used the TGF format to represent a nodal graph. Then an in-game parser and callback/event handler framework handled the execution of the AI graph on a per-Robot basis.
    • The AI system is connected to other systems, such as the Inventory, the Trade, Convo (dialogue system) and of course, NPCs/Robots themselves.
    • Using the AI system, a Robot can accost you to do a contraband check, which was one of the first implementations of the AI (even before combat).
    • The AI can contextualise its own dialogue with the Player, changing it from a contraband check to an arrest, for example.
  • Lookups for gameplay values, such as hit-chance, effect of skills on gameplay, were done using a non-linear interpolation that was accomplished by using Open Office Calc’s cell formulas. This allowed me to tweak lookup values utilising functions as opposed to doing it individually, per cell! This application was conveniently placed to export to CSV directly, so no other intermediate process was needed to get it to C2.
  • The Combat system is closely tied with the AI and is comprised of many factors, a few of which include:
    • Alert level behaviour of Robots; certain actions at a certain alert level means differently for Robots. For example, running or crouching is OK when Alert Level is 0. But when the Alert Level is 1, running or crouching is interpreted as suspicious and Player will be fired upon.
    • Behaviour of Robots differ from one another. Some guard, some patrol, some check for contraband.
    • Offensive component
      • Player accuracy skill
      • Weapon attributes such as range, max_range, weapon dropoff (weapon damage and chance to hit is affected)
      • Rate of fire
      • Dual-wielding of weapons
      • Crouching increases accuracy
      • Bomb placement and detonation
      • Shock effect; certain weapon may stun a Robot for a period of time.
      • GMAC system, which is a modifier on top of a typical random number generator.
    • Defensive component
      • Use of cover for defence
      • Crouching reduces profile, increases Player defence against being hit
      • Running increases Player defence against hit but only if running perpendicular to Robot.
    • Stealth component
      • Crouching behind low obstacles for stealth
      • Noise level when running; Robot hears you!
      • Glitters is Electronic Counter-Measures and makes the Player invisible for a short period of time.
    • Hacking powerlets to get more energy, and the associated success rates, and the penalties for failure
    • And others that are too lengthy to include, but you get the idea…

Normally, a prototype is small, whose gameplay represents the root of what the game is about. Sometimes, a prototype is created to determine if a gameplay works or not, or if people like it enough.

But I built the prototype as a technical reconnoitre  of what I’m going to come up against. You can say I was also trying to form a beachhead at the same time. I don’t know if people would like it, but I can’t be dissuaded either way; I’ve gone this far solely on the excitement of taking a childhood game to my present.

But a prototype is also made to present the gameplay as clear as possible, that if the prototype is fun to play, then the real thing would be as fun, if not more fun to play. The problem I have with Citizen is that it is an adventure as much as it is a shoot-em-up game. The fun in 2400 AD, Fallout, or Shadowrun, for example, is the fact that it is an adventure. But I find it difficult to express the full adventure by doing a half-adventure. I think that’s due to my lack of experience writing for games. At the same time, I think that I’ve been focused so much on the technical aspects that I’ve not really dug as deep as I should into the potential of the narrative. I’ve been working on the framework in which I hope to base an adventure story (of which I have a first draft already), and I think that this prototype, as it stands, should be just seen as the prototype for the framework.

More to come.


9 thoughts on “Prototype sampler # 1”

  1. Thanks for your kind words. 🙂

    Do you mean constraining position of one element to another? I use Rex’s PinOffsetXY heavily since it allows me to numerically enter my offset.

    For example, the weapon blast, The ‘bullet’ is composed of 2 parts: a ‘bullet node’, which contains the real data of the bullet (damage, hit chance, etc), and the ‘blast’ which is the graphical representation of the weapon blast. ‘blast’ is PinOffSetXY’d to ‘bullet node’ with an Y-offset of a predefined level according to the originator of the bullet (Robot or Player).

    In earlier days, I attempted to attach the ‘blast’ to the nozzle of the gun.

    In one earlier version, I attempted to export image points by calculating it in my 3d app, then it was applied to the caproj using the app that I wrote, C2 Sprite Manager. The process had too many manual steps, however, so I stopped using it almost immediately because I thought that it was not sustainable. I got tired of revising and applying. 🙂

    I also tried calculating for a virtual ellipse (a circle in isometric view). It’s basically a re-working of ‘orthographic to isometric coordinate’ functions. But then I saw that there were actual aesthetic problems when the ‘blast’ originates exactly on the nozzle of the gun. The path to the target seems slanted in my directions. Basically it looked ugly. If I tried to fix it, I would have attempted to converge the ‘blast’ to the ‘bullet node’ as it went farther away. But I thought that was too complicated and dropped the idea. So I went back to simple PinOffsetXY. 🙂

    Lastly, I think I can improve one aspect about the ‘blast’: delay the visibility of the blast to make it look like it is originating closer the gun nozzle, and not the center of the Player.

    (But I’m not sure if that’s what you mean?)


    1. (Still not sure if this is what you mean, but I’ll give it go. 🙂 )

      The character is not technically on a platform. Technically it it’s walking flat around the C2 canvas. A grid (using Rex’s Board) is used for targeting tiles for destination.

      The zsort image you referenced is precisely that the character and the ‘walls’ are flat on the canvas, in one layer. In the image, of course, I temporarily used the mouse as a way to navigate the character, for purposes of demonstrating the new z-sort.

      I’m not not clear on what you mean by ‘connection’, though.

      A character entity is composed of an invisible base ‘mover’ sprite, and a character sprite. The character sprite is pinned to the mover. An invisible sort collider is also pinned. All of them are on the same layer as the ‘walls’. All 3 (and several other character ‘utitlies’) associated with this character. Is this ‘association’ what you mean by ‘connection’?

      If that’s what you mean, then there’s nothing special I do; I simply use instance variables. I create a ‘mover uid’ variable for the ‘character’ sprite, and a ‘character uid’ for the mover sprite. I also create a ‘character uid’ variable for the sort collider.

      When I want to pick or check a particular entity, e.g. mover checks status of character sprite, I use mover’s character uid instance variable. In other words, they all share each other’s uids.

      I didn’t like to use containers in this case because during creation, containers insisted on creating all of the objects in the container. Sometimes, to support persistent levels and global objects, I needed more control over creation; so I dropped containers and associated multiple sprites to each other using their uids.

      Did I understand it right this time? haha… 🙂


  2. 100% )
    But by this point I already guessed what the answer would be )

    When I was doing the lighting, I had to bind different manipulators to the set of objects (or characters) – movements, heights, etc. Some were represented by their own family. Everyone had variable Name. But I could not bind all manipulators to objects in one event, because I compared variables in a loop. I had to represent the links as pairs and run a loop for each pair. This feature of the event sheet – pick in a loop is impossible for more than two different objects. Or I just do not have enough knowledge )

    In any case – thanks for your time. And apologies for my English )


    1. I think that the picking of single-object-types is a popular limitation (some would say feature) of Construct. I think many 3rd-party have tried making something that would make it easier to refer to instance values of different object types, but not actually be able to pick.

      Families are useful for picking, but Families also require the same object type, so there’s no real way. Containers are ok, but again, you can’t pick them from variable selection because all picking requires a type. I don’t understand why this particular design was made the way it was… 🙂

      PS: Your English is very good, I just lacked context. 🙂

      Liked by 2 people

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.