I have a new blog here:
Gap
So we haven’t made any updates in a while. Turns out both me and Zane had a lot of stuff going on in our lives, usually revolving around our careers, studies or that unmentionable thing called an emotional response to social events.
We (I) have concluded that this game was majorly over-ambitious, as we both kinda knew from the start. We will be working on a short, small topdown 2D game soon so that it’s a better contained small thing that we can push out. But we both have this terrible itch to still do Arkhamobster, so we’ll be getting back to that.
I’ve also been playing around in Unity since and will keep reporting on any development I do once we get back into Arkhamobster, or once we start blogging about our other game.
Much apologies.
Game Design: Working With Twine 2
So I was looking for tools to help with branching narrative. To date, I’d done some work on branching narrative in Ren’Py and Tyranobuilder while experimenting with visual novel creation. This was my fist introduction to using variables to control dialogue paths, or which text appears on screen.
The problem with these tools, however, was that the ‘overview’ of which dialogue option leads to which text bar was…well, non-existent, to be fair. Everything was displayed in a linear timeline from top to bottom. There’s no easy way to gauge which options lead to each other, or are mutually exclusive.
Twine is better simply for the overview it provides. It displays all text ‘entries’ as blocks on the screen, and then uses arrows to show the links between these different text entries. This ‘flowchart’ style allows you to see narrative branches that terminate nowhere, and whether any options are linked incorrectly.
Let me use an example of a choose-your-own-adventure game I’ve been doing as a test of the software. I called it ‘In the Beginning’, because it’s a ‘god sim’ sort of choose-your-own-legend interactive fiction, and because that’s the opening text line. Also, I think it resonates with modern Western audiences (feel free to disagree). So here’s a screenshot of the story overview so far:
As can be seen, I’ve only completed 2 of the 5 branching narrative arcs from the first major decision a player makes. As with most other games, we need a ‘choke point’ to reign in all the choices, otherwise we’ll just have narrative splintering off infinitely (and likely compromise on the quality with this quantity).
This choke point is the ‘Create First People’ narrative entry. And though we have multiple different branches available here (notice we already have 4), the player only be able to see a maximum of 6 at any one point in time. This is because most of these options are based on prior player choices and the variables linked to these choices:
Players have been confronted with two choices prior to the above point: choice of world (5 options) and choice of haven (3 options per each of the 5 worlds, for a total of 15 options). Each option they’ve made already gives them a unique choice on this page.
It’s with small touches like that which we’d like to show that player choice matters in Arkhamobster. As simple a choice as whether you skip the tutorial or not determines which of your 2 initial companions survives, for instance.
Needless to say, I’m already using Twine to map out Arkhamobster:
Overall Narrative Structure – The Hero’s Journey
SPOILER WARNING: This is a truly spoilerific post. If you or a loved one are in any way allergic to spoilers, you shouldn’t even be reading this warning message. The post below may cause swelling, mood swings and irrational behaviour.
Okay, so last time I was talking about player choice, and how we want to encourage it as much as possible. While a completely open-ended game isn’t possible, we can provide a myriad of ‘destinations’ to arrive at by the end. Despite maybe having only 8 endings (as a side note to Jacques, my choice of the number 8 is purely hypothetical, before you remind me of the workload I’m creating here), the story is about both the journey and the destination. Even if you get the same ending as a previous play-through, your actual gameplay experience will be different. Heck, the gameplay can provide conditional modifiers to make the ending slightly different if necessary.
I’m digressing. The point I’m trying to make is, ultimately we’re still limited by systems, budget and assets. In this case, our limitation is structural.
The overall story will follow the classic 4 Act Structure, which has often been described as the Hero’s Journey in Western story telling. Those of you familiar with my personal blog will know I tend to stick with this structure. Those of you who know Jacques personally know how he hates the idea of a predictable story. Just because the structure is known on a subconscious level, doesn’t mean we know which direction the story will take. We leave that up to the player. And structure gives the players something to cling to and feel secure, even if the security is false. Like an imaginary safety blanket.
The structure, in a nutshell is as follows. And for the curious, I like Roman numerals because I’m pretentious like that.
Act I: Introduce the hero, kick-start the plot with the incendiary event that begins our tale, and then introduce the first plot point in which the hero is forced to act and undergo a paradigm shift.
Act II: Exclusively about the hero’s reaction the the new events and situation and what kind of response is taken, too early for a direct attack. This is about gathering information, forging alliances, exploring options and seeking shelter. At the start of this act we introduce the antagonist in his/her/its full glory, usually. For our part, I intend to keep things mysterious and enticing. By the end of this part the character has prepared, and believes they have a workable plan of action. Then everything changes – new information enters the story, understanding of the situation changes, or new forces come into the fray.
Act III: This is where the hero becomes proactive and starts to fix things, after stumbling around a lot and figuring things out in Act II. The hero isn’t the only one making progress, however – our antagonist is as well. The antagonist becomes stronger, and his/her/its plans begin to move ahead steadily. The hero may make a few attempts at attacking the antagonist, but these fail. At the end of this arc we get the final injection of new information, and everything necessary/needed is known. The hero is now the catalyst for change.
Act IV: The pay-off. All events the protagonist and antagonist have set in motion come to a head. The protagonist takes all the preparation, and takes the lead in the fight. This is where he/she/it earns the right to be called a hero. This final act, from the player perspective, is where they witness how their actions have changed the game world, and then how they tie up all these loose threads they’ve left dangling everywhere.
So, judging by the above, I’d foresee having to write:
- 1 x Act I (this is the basic kick-off point; choices the player makes here affect the next phases)
- 1 x Act II (this Act is where the majority of initial choices get made; any differences in this Act can be accounted for using variables alone)
- 3 x Act III (3 is a hypothetical number picked for symmetry, and because i hate binaries)
- 9 x Act IV (if we stick with the hypothetical 3, we’ll have 3 branches from the previous 3 branches)
Next time I’ll talk about these branching stories, the conditions and variables I foresee affecting them, and the like.
Cloning of games and sharing details about Arkhamobster
I recently read a few articles on indie games being cloned (mostly on the iOS app store). The series of articles can be read here. I’ve met Rodain Joubert once (without realizing at the time who he was), since we have mutual friends in Cape Town. The result is that that article made me more fearful. I guess the probability of having my work cloned seems like a bigger reality because it happened to someone I know.
So I asked on Reddit and got two responses. Mostly, I got the idea that transparency is better than secrecy, even at the risk of cloning. Vlambeer, victim of cloning, still believes in transparency.
So I’m asking myself, how much should I share? In an ideal world, I’d share absolutely everything and put the code out there open source. But given the actual reality of game cloning, I need to make it actually some effort to clone the game.
My gut is telling me to share code snippets as much as I want. Our game may have some semi-original gameplay mechanic ideas, but a lot of it is based on story and atmosphere and character development. These things are either too tedious to replicate, or automatically copyrighted (unlike mechanics, which are unpatentable and uncopyrightable).
I don’t want someone to copy our idea until we’ve had our chance to put our idea out there on the market. After our product is available to buy though, I don’t care. Imitation is flattery and marketing, I suppose. Besides, we’re using HP Lovecraft’s public domain creations in the first place. It’s not like we have a leg to stand on when it comes to not copying others. There are so many Lovecraftian parody games out there that we’re gonna have a real struggle standing out based on that alone.
I’m probably going to eat my words, but I want to document exactly my thought process and code snippets so that any junior-but-not-completely-noob developer would be able to use parts of my code for his own games.
–
Shortly after writing this entry, I contacted Rodain Joubert and asked his opinion. This is what he said:
As a general rule of thumb: game ideas are broadly cheap and always worth sharing, because people who would steal ideas are generally less willing to put all the work/risk into building themselves. It’s not really worth it at all and somebody who tries to clone you before you get out the gate would have to be kinda stupid :p
Cloning is the greatest danger when you’re vying for a particular client rather than a public audience, and those are two different beasties entirely.
It’s also dangerous when you’ve already “made it” and have a popular game on the way because cloners prefer to find something safe and guaranteed to copy. At least as much as that’s possible in the current game dev landscape. But you don’t have much choice except to be open ANYWAY, because you’ll never get the audience/traction you need for a commercial project to get that successful *without* sharing a whole bunch.
If it’s easier to look at it this way: you’ll always lose more by hiding your game than you would by showing it to the people who want to absorb it while risking a clone. You may get burnt somewhat, but in that scenario it’s usually safe to say that it was still better to have taken the risk. You’re also not shit out of options when it comes down to that. Desktop Dungeons resisted a clone attempt successfully, and these sort of things do get flagged/reported on controlled platforms like iOS
That’s some stream-of-consciousness thinking for now. Other local devs in MGSA have similar opinions
When you talk about sharing code, btw, do you mean like segments, individual methods?
I replied and said: “Like, “this is the script which controls my camera” but not fully open source.”
ohhh okayWell, that sounds really helpful and hopefully people can use and learn from that sort of codebut yah, it’s a very big step from that to cloning :p
So there. Apparently Cape Townsmen think alike. Thanks a lot for the reply, Rodain. Zane, what do you think about the sharing stuff?
Oh, and I found out about makegamessa.com/ which is where a lot of the locals congregate. So I think I’m going to start lurking there for a bit. Maybe post a link to this blog and have a bunch of experts tell me how deluded I am, so that I can ignore them and tell myself that they with years of experience know nothing.
Will report back on that.
Slower updates
My study break is over and I have to start studying for a few months again. Also, things are getting a bit hectic at my job for the next month, and I’ve got various family/personal/social engagements I’m trying to get to for the next several weeks. Updates will come slower from this point on for a month at least.
Conceptual Testing of Arkhamobster in Unity
Physics and Camera Angle Testing
So, without giving too much away, I need to be able to have sprites (with animation, later) on a 3D platform. These sprites must stay upright at all times, and when I rotate the camera, the sprites must rotate with the camera without falling over. This was done fairly easily by adding a Sprite Game Object, adding a 3D box collider, and reducing the z-axis of the box-collider to 0 thickness. It has to be a 3D box collider because the 2D and 3D physics engines in Unity DO NOT INTERACT. Then, I added a Rigidbody with Frozen Rotation along the X and Z axis. The result is more or less what I was looking for. The object can move around and have physics, but it won’t fall down flat like a piece of paper, because it is constrained. Now I need to animate the stuff with scripts and see what that looks like.
Player and Camera Movement
Further testing showed that the sprites do not cast shadows and are unaffected by lighting. More info here. This means I either have to write lighting methods myself, or use 3D objects with textures. Considering I have to use a 3D engine, I may as well avoid 2D objects as far as possible. We still don’t know what models we’re going to be using. Since we’re going to be changing the lighting in various places in the game from daylight to darkness-stares-back-at-you darkness, it is essential we have full control over lighting. Next, I’m working on a script to move the player and camera, and another script to change the camera/game-mode from exploreMode to combatMode. I need to read up about platformer camera restrictions. We don’t want the camera to always move with the player, but rather have it move if playerPosition(x,0,z) – cameraPosition(x,0,z) > (10,0,5); or something like that.
I copypasta’d the player script from the roll-a-ball tutorial and applied it to the player here. For now, they player can move left and right, and up and down. The roll-a-ball tutorial used “AddForce(Vector3)” for the ball. What would happen if you added a force to a thin cube? It falls over and flops around because friction from the floor still applies.
I think I have to work through, or at least look at that one other tutorial I didn’t do. It explains how to move an animated 3D object. For now, I just want to play around with the camera and then I’ll do that tutorial.
The camera was fairly simple. I find the distance, on the x-axis, between the camera and the player. If the player is more than maxDistance from the camera (on x-axis), then the camera moves towards the player at a speed of (speed*distance*distance), so that the camera always catches up quickly to the player if he is far away, but slows down when the camera gets closer.
I made my first build (build1) and commit, and am leaving this alone for now. Will be taking a quick look at the other tutorial after this.
Player Choice and Storyline Effects
SPOILER ALERTS: Please note that while there are no direct storyline spoilers, this whole post gives insight into the workings of player choice and story structure within the game. Like a magician’s trick, immersion and the reality of your decisions always works better if you don’t know how it’s done. Read on if you’re interested, but knowing how this works may kill the fun factor for you a little too much if you’re a conventional player.
Today I thought I’d talk about player choice, and how it’ll relate to storyline in our game. As a tabletop GM, I find one of the most rewarding things about the medium is how players handle the near-infinite amounts of choice. Once you have a feel for what motivates your players and their characters, it’s easier to gauge what kind of challenges they enjoy and predict (within a reasonable margin of error) what their decision is likely to be. This allows you to offer them fewer options as the game proceeds, but each of these individual options are all designed to appeal to them more. The early game can be characterized by myriad options, with only one being the clear winner. The later game can present perhaps no more than 4 options, but each one holds value to the player, making the decision more difficult.
Digital games suffer some limitations at this stage, since there’s no omnipresent gamemaster (GM). For example, if it’s the battle against the final boss, and the player character chooses to sacrifice him or herself so that an NPC party member can get the hostages to safety, the game interprets that as a loss scenario. What’s actually happening is the player has chosen their victory condition and thus defined their objective. A GM can support the character and tailor the story in this direction. A game is programmed with preset scenarios based on preset conditions.
Some games use this limitation, but manage to mask the limited nature well. Players can be given choices all throughout the game, and each one can impact on the game world in a small way while allowing the plot to progress in a fairly unchanged manner. If players are invested in the decision with real things at stake—I’m thinking of Dragon Age: Inquisition, where (depending on the world state you imported) you choose between sacrificing your romance option from the first game or your player character from the second—then the decision itself has meaning, even if nothing much changes in game as a result. Others have limited decisions, but at certain key points the player makes choices which send the game on divergent paths. As a final alternative (that I can think of), we have a linear story with no branches or diversion, but the game takes note of player actions—dark side or light side in Star Wars, for instance—and assigns an ending based on the values the player has accumulated.
So how are we going to handle choice in Arkham Mobster? That falls into my lap, predominantly as a feature of design and planning. The plan is to use all the methods described above. Player agency will be enabled through the following design decisions.
BRANCHING STORYLINES:
Telltale Games makes some of my favourite ‘interactive movies’, as I think of them. Occasionally players get to choose one of two divergent paths, before the story comes together after this scene. Now, while players will be presented with certain missions in game which are mutually exclusive, I’d also like the larger plot to be divergent. I’d like to have about 2 – 3 key points where the plot diverges down different paths, with between 2 – 3 branches at each of these key points. Unless certain paths led to the same final scene, we could be looking at around 9 different ‘final chapters’ (primarily because writing more would feel like too much work, unless we release it as a DLC content pack for adoring fans). That in itself requires writing 13 ‘chapters’ of story, of which the player will only ever experience 3 in one play-through. So there’s a lot of writing to be done, but I’m prepared to take on that for the game experience I believe in.
MUTUALLY EXCLUSIVE MISSIONS AND SMALL CHANGES TO THE GAME WORLD:
If players see that small effects can have a difference, they’re prepared to take their larger decisions more seriously, and then be aware when the storyline branches off in different directions. Mutually exclusive missions are a good way of doing this. Do you rush into the burning building to retrieve a powerful artefact, or do you help tend to the wounded? You can’t do both. On the next play through, you might do things differently. At the same time, these little choices can have wider ramifications. Maybe one of the people the player failed to rescue runs a halfway house in the nearby village. If the player saves this person, their selflessness is remembered and they have free board and lodging. If they let the individual die, they find there’s nowhere to sleep in the town except the back-seat of their car. Little surprises like this help make the world feel more rich and alive. What The Witcher series does well is provide these choices without presenting them as moral binaries, and also by showing that a seemingly good action now can have dire consequences later.
DECISIONS THAT MATTER:
For everything given to the player, remember that you have something powerful you can threaten to take away. When they lose a valued NPC sidekick, or a favoured item, it hammers home that there are consequences to actions. Give them a reason to care about the world and treat it as real. Then threaten the things they care about. Provided we’re never unfair, the result is more emotional investment, and choices become more than based on character stats or the storyline you want to achieve.
TRACK PLAYER ACTIONS:
This is one both Jacques and I agreed early on. While I don’t like a binary system that measures light-side versus dark-side, good versus evil, renegade versus paragon, a record of player actions helps you gain some measure of who they are. Vampire the Masquerade: Bloodlines does a great job of presenting multiple ways of tackling a problem. You can stealth, use your charm or even go for the full-frontal assault. Even once you choose an approach, you have a variety of options at your disposal for how you do it. Even a simple tweak, like the game noting that you overcome challenges using social persuasion and having an NPC mention you’re famed for your wit and charm, proves to you as the player that what you’re doing makes a difference. Games reward players for going to extremes, but should also do the same if the player chooses a balanced middle-ground. This allows players to choose how they play without worrying about creating a nerfed character. In addition to tracking how players deal with problems, NPCs should remember if a player was rude or helpful, affecting their attitude. Player actions that help or hinder in-game organisations should have an effect when dealing with these groups, or determining how powerful they are at each stage in the game.
Whew, that was a long post. I hope it was suitably insightful. Any thoughts are welcome in the comments section.
Source Control: Bitbucket+Git
This guide is for both myself and Zane, as well as anyone else intending on joining us. We are using Git with a free Bitbucket account (Thanks, Atlassian) for source/version control.
1.) Download and Install Unity. I have Unity 64 bit 5.1.0f3 Personal installed.
1.1) Open Unity, create an empty project and determine your projects folder
2) Create a Bitbucket account
2.1) Tell Jacques to give you access on the repo.
2.2) Remember your username and password. You’ll need it later. (To help me remember: Mine is jacques_sucks@bitbucket.com, passwordsareeasytoforget)
3) By following this guide
3.1) Install and set up Git
3.2) If you know Git/Command line, you know the rest
4) If you’re not used to git/command line, install SourceTree
4.1) Link SourceTree to your BitBucket account. Open Arkhamobster and assign it to an empty folder inside your Unity projects
4.2) Pull (Never commit or push, unless you know what you’re doing)
5) Open Unity, openArkhamobster project
Final Unity Tutorial: More 2D Roguelike
[This is mostly a technical exploration of Unity and my learning thereof. If you want to skip the technical stuff, go down to "final thoughts"]
Board/Game Controller
This project is still ongoing for me. They explained static variables and their use (slightly) and used a static variable to make sure only one instance of the gameManager is running at any time. Furthermore, they implemented DontDestroyOnLoad(gameObject) to make sure that the gameManager is not destroyed between scenes, since it will have to keep track of score/health/levels throughout the game. A persistant instance of gameManager must always be running. This gameManager GameObject is saved as a prefab and the Main Camera has a loader script, which Instantiates the GameManager prefab if instance==null. It’s a basic way of making sure your Game Manager is consistent and persistent with pre-selected public variables.
Moving Objects
Abstract classes are used. I know how to use abstract classes and how they work in Java, but I’ve never had cause to write one myself, so I guess I should pay attention. In C#, methods in abstract classes are written with virtual (e.g. protected virtual void Start()), which allows them to be overridden (by e.g. protected override void and declaring a class as public class Name : MovingObject) . Also, I just found out multiplication is more efficient than division, so if multiple divisions are made with a variable, it is more efficient to convert variable to inverse and do multiple multiplications with this inverse. How clever. And all the programmers with degrees are saying “duh” at me right now.
Anyway, we’re using Abstract Classes here because both the enemy and the player will be using the Abstract MoveObject class, passing either a Player or Enemy component to the class. I highly recommend both checking the YouTube comments (the creator comments there) and the script on the unity page, as it has a comment on every line, as you can see in the image above.
I got a compile error from the Wall script, even if I copy-pasted his code, so I just used the Wall script included in the assets. I’m light on myself now but will figure stuff out once I start on my own engine, which should be by next week. I’m not sure how Unity’s Script Editor (MonoDevelop) works with sorting out compile issues. Usually I don’t realize there’s a compile error at all until I try to use the script from the Unity GUI. Will look into that.
—
Ah. I just needed to press F7 (build project). And it showed me that the errors happened because the assets already contained scripts and classes with the given names. So uh. I’ll just use their scripts and work along with the GUI stuff. Freaken things sucks. We’ll do it live!
Player/Enemy Animator Controller
This is quite nice. You set up animation states and determine when/how the transitions occur. I’m not focusing on animation yet, but will need to get back to this once I’ve set up the basic game logic and stuff.
Player/Enemy Script
They introduced [HideInInspector] which hides public variables from unity, but makes them accessible to scripts (if public). They also introduced Unity’s built in OnDisable function (self explanatory), and demonstrated how to inheret and override an abstract class and its methods. Furthermore, to load a new (or reload a current) scene, they used Application.LoadLevel(Application.loadedLevel); To assign a GameObject not specified, the used target = GameObject.FindGameObjectWithTag(“Player”).transform;
The important thing to note here is that the Player script has one new instance running per level, so any variables (such as health/food) that need to be carried over to the next level, must be stored in the GameManager when the Player/Enemy/Whatever script is OnDisabled, since the GameManager is always running. I’m assuming that this is good practice for Unity.
This guy has an interesting way of doing things. He sets the value of food in the player script. Then he sets the damage that the player does in the enemy script. I would rather have set the damage and all that in the player script, and called functions from the enemy by passing ints from the player. public void attack(int damage){}; Not sure whether my method would be better at all though.
Also to note is that he likes writing “return” in the middle of a method. I’ve been told that’s bad practice because it’s difficult to see all the exit points in your method if you do that. I agree with that assessment, so I’m going to continue using ifs en elses to reduce the exit points to a small number.
UI + Audio
More or less the same as the previous tutorials. A canvas gameObject is used with images on top that are anchored to the corner, and so on. The script then updates the text every time there is a change from damage or item pickup or level change. Simple stuff.
For sound, they use the SoundManager Game Object, with script SoundManager.cs. A cool between this and the previous sound manager is that they set public floats lowPitchRange and highPitchRange to subtly change the noises. Clever method I’d like to employ for non-dialogue and non-music sounds.Furthermore, they declare public void PlaySingle(AudioClip clip){}, and public void RandomizeSfx (params AudioClip [] clips){}. I thought that was pretty simple and straightforward. I’d probably use the exact same method, though with dialogue added as a third Audio Source.
Also: Blocking Layer
So, I didn’t really understand the “Blocking Layer” tickbox in Unity, so I checked up on that. It turns out (from Unity’s page on Blocking Layer) that basically, you can set any 2D or 3D object to a certain layer. You can then set which layers interact with which layers. For example, you can have enemies all from EnemyLayer. So the player can not walk through an enemy, but the enemies can walk through each other, for example. I also suggest looking at Unity’s cool Vector Cookbook page. It’s awesome for vector computations.
Final Thoughts
I am now done with Unity tutorials and will be working off of the documentation and Stack Overflow and whatnot from this point on. With this I am “ready” to begin with the game. Not actually ready, not really ready, not at all ready, to be honest. I need to know Unity, C#, and programming in general a lot better, before I can do this properly.
But fuck that, I don’t care. It’s time to start and see what I can achieve. I’m not going to increase my XP without grinding on a project like this.
I noticed from the comments that there are suddenly a LOT fewer people responding or interested in the intermediate tutorial. This, coupled with people from the beginner tutorial complaining that the “scripting part could not be less intuitive” and that “I like everything except that stupid scripting part” gives me the impression that there are actually a lot fewer competent+driven people out there willing to make games than I feared at first. I mean, with the amount of zero-effort games out there (see The Asset Flip by Jim Sterling), I think we actually stand a chance to release something that I’ll at least be willing to put put our for free, if not release for money.
Oh, and Zane and I decided on a studio name for now:
Arkhamobster 