next »

[Jordgubben]

The code named 'Project Nom' is a game where you become the target of a 18th century style a witch hunt. It features a CYOA (Chose Your Own Adventure) like interface, even though it actuallt works more like an adventure game. The game has no combat, instead it features a unique dispute mechanic inspired by fighting games, TCGs and JRPGs.



~~~ ~~~ ~~~ Try it now!  ~~~ ~~~ ~~~





====== Following is the Original post =======

This project has two purposes: 1. Make a short text adventure style game about not getting eaten. 2. To test a different approach to spare time development.

Project NOM - The game
The basic premisses is ta game that at surface level appears to be a VN or chose your own adventure, but works mechanically more like a text adventure or RPG (with ideas borrowed from strategy games, tcg:s and stealth games).

The story takes place in a large troll cave from where the main character must flee to avoid ending up add dinner. Tone is intended to be light hearted, but with streaks of brutality (somewhat like the Redwall books). Plot, theme or moral undertone is outside of scope at the time of writing, but I imagine it will revolve around whether or not one is responsible to help those who do not help them selves.

The game will be a web browser game reusing the engine (or rather world data model) of a previous project. Latest published work in progress is playable at the following url:

http://superattack.se/games/nom/



N. O. M. - The project model
For the last 10 years or so I've only been able finish 2 projects. One had a hard delivery date (entry for a competition) and the other was cut to half scope (I got a new day job and had to focus). All other projects have failed for exactly the same reason: Way to large scopes.

So this time I'm trying the complete opposite (for science!): Commit to the absolutely smallest possible scope. Reach this mini-scope, then iterate. The game need not not be innovative, interesting or even so much of a "game" at all in the first cycle. But everything but nothing can be half-done and everything created must be of release quality (ie. no place holders or obvious gaps). In short there should be "Nothing Obviously Missing" in the game.

Once this "NOM-point" has been reached, then one (1)! new idea can be tested. If proven to be valuable it will be implemented and polished until a new NOM-point has been reached. I should be able to stop with a completed game at every NOM-point, because every NOM-point is a potentially finished game.

[Jordgubben]

OK. First "release". The world has three rooms. Uploaded it mostly to give a hint of what type of game this is and to show where I'm starting from (ie. not totally from scratch).

Obviously Missing:

• Win condition
• Challange

This link will always point to the latest release:
http://superattack.se/games/nom/

This link points to this specific release:
http://superattack.se/games/nom-r1/
(But it will stop working if/when I clear out old releases in the future)

[Jordgubben]

Second release. It has a Main menu and credits. It also has a beginning, a middle and an end, with some from of challenge along the way. Nothing is obviously missing.

It could be considered complete, but I'm setting it at 90% so that the admins do not move the thread by mistake.

http://superattack.se/games/nom-r2/

Possible improvements:

• Deeper (and more complex) dispute system
• More things to dispute with (and more reasons to dispute)
• Combat system (when disputes fail)
• Stealth!
• Big monsters
• Levels and Exp
• An inventory
• Loot - High score based on what you manage to take with you
• Alternate ending (based on loot)

[Jordgubben]

Third release.

This is just a small update to have something relatively new for Indie Game Dungeon #4.

The dispute system now supports retorts. The guard has a reactively complex retort pattern, which probably impossible to figure out and predict (in an enjoyable way).

There is also a slight motif change.

Current release is at:
http://superattack.se/games/nom-r3/
(Currently this game at most 60% done.)

[Jordgubben]

Most obviously missing
The main problem right now it the lack of context, motif or concrete player goal. A game about talking to people must have people to talk to and things to talk about. This requires a story/plot of some sort.

The story must satisfy a number of requirements. It must be relatively short. It should also be expandable. It must present a clear goal and multiple smaller problems for the player to solve. I also feel that the player should be free to explore and solve problems in his/her own preferred order. Finally it should probably be exciting and/explore some relevant "big" question.

I'm toying with multiple ideas right now. These are my best ideas so far:

• You are the captain of the royal guard. You are at an important diplomatic dinner party. The queen has barely survived an assassination attempt. You must find the culprit without causing a scene, since attracting to much attention to this may start a civil war.
• Your sister/mother/daughter has been accused of Witchcraft and you must prove her innocence. Otherwise she will both be burned to death or drowned.
• You are a hostage negotiator. The presidents daughter has been kidnapped. Your only weapons are a bulletproof west and a megaphone.

[Jordgubben]

The witch hunt plot idea is slowly growing on me. Pesant mobs and inquisitioners could aper random encounter style and failing to convince them would result in getting burned on the stake. This provides both repeatability and urgency, both very important as explained in another post.

[Jordgubben]

National Geographics has a cool little interactive novel about the Salem Witch hunts. It's not much of a "game", but it does a good job at putting you in the shoes of an accused. There are some ideas in it worth building new things on top of.

http://education.nationalgeographic.com/media/salem-witch-trials-interactive/

[Jordgubben]

For the fourth release I have completely changed the motif to the early modern era (with possible future fantasy elements) and completely turned the dispute mechanic inside out. There is now a small town to explore and (some) of the villagers will actually argue back when disputed with. How time works has also been changed. It now uses an initiative point system behind the scenes.

Release can be played here:
http://superattack.se/games/nom-r4/

Git claims that it has been a total of 92 commits since the last release and that's probably true because this release has been quite quite exhausting. I'm going to take a break from larger technical things for a while and focus on more content.

[Jordgubben]

Tweaking up the different dispute arguments to get a more interesting game play is the obvious next step for this game/IF/thing/whatever.

I've been testplaying this game on paper and it behaves a lot like Nim. This is just an accident, but I remember playing a lot of Nim in my youth. I like Nim so thats a good sign (I think). But just like Nim it is very solvable. If both players (player and NPC) have the same (or at least equal versitile and powerfull) argument sets then the player who takes the first move can not lose unless he/she plays like a blithering idiot.

I can't see any really good way to get around this problem, so perhaps I should embrace it. A PvP game should not be solvable, but it should be ok for an PvE game (since the player is expected to have a > 50% win rate). Just like Nim has to be re-solved for every combination of stacks, every dispute needs to be different enough to require a new solution. The information is imperfect (the player does not know what arguments an NPC-oponet has or what they do) so the game can not punish defeat to hard. The player must have a fair chance to empirical figure out how the NPC works and then find the solution to every dispute.

Presentation of information provided also needs to improve alot.

[Jordgubben]

August has been a slow month. I'm  making this release mostly to get a record of what a "slow month" actually results in. The further I get the more I realise that developing this game is like playing a dungeon crawler. As I will add, fix or improve things I always uncover more "obviously missing things". I thought I was at 60% last release and now I've moved back to 50%. It would not surprise me if I'm at 40% at the end of next month.

Maybe this is to be expected since my design philosophy is centred around filling in the blanks and see what happens, rather than aiming for a predefined final product.

This release can be played here:
http://superattack.se/games/nom-r5/

New in this release:

• Main character can now block opponents arguments
• Arguments can cause status effects ("Regenerating confidence")
• Misc. tweaks make disputes easier to follow (but there's still allot more to do)

(I've also taken a first bite at improving the mobile experience. But so far I think I've only managed to make it a bit worse. I have a lot more to learn here.)

Most obviously missing right now:

• A final boss - An ending that is a satisfying struggle, not just a walk through an empty tunnel
• Complexity/Depth - More varied disputes and arguments, possibly with an upgrade mechanic
• Character portraits - I would love to start posting art and screenshots, just like the cool kids

[Moth]

Hey, surprised no one commented on this.

I really like your plan of iteration here- make something small and complete then sequentially build in bite-sized expansions on top of it. It's a nice approach.

It's interesting to see this project change from a dungeon romp into a Salem witch trials thing. I'm quite interested by how you used RPG battle mechanics to convey an argument. The first time I played an argument I wasn't quite sure what was going on, but by the second time everything made sense.

It's really cool, kudos. Looking forward to seeing what further development is like.

[Jordgubben]

Thanks. I'm really happy to hear it makes sense. 

I'd like to add more deep/complex chains of argument combinations, but there is a big hurdle in making it understandable for the player without breaking immersion.

I feel the presentation aspects still has a long way to go. But at the same time I'm trying to avoid/postpone everything that is even the slightest graphics heavy. Drawing and redrawing illustrations takes a lot of time, and adjusting the mechanics would then require more rework. Illustrations would therefore wait until the part being illustrated is ready to be "set in stone". And even then I'll have to be a bit careful. Illustrating some sections may cause other parts to appear relatively unillustrated, making those illustrations more obviously missing then if there had been no illustrations at all.

[Jordgubben]

The Barriers to Entry for RPGs Are Way Too High is an interesting because it's from a gamers (non-game-developers) perspective. I'm not sure the author understands it bur the gist of the article is that what makes (W&J)RPG:s unplayable is also what make them great.

The barrier to entry is also the barrier to exit. Once your mustered up the willpower to get over that hill and boot up the game, then that hill is in a way also what is keeping you there. Getting into it takes some effort, therefore getting out of it also takes effort.

[Jordgubben]

(Fun fact:  When I made the last post I got a warning that I had not made any posts in over 120 days. Getting a Wii U was a good idea, but not a productive idea.)


Today I'm going to explain the basic components of the world engine behind the UI. It will perhaps not be a very useful post in it self, but it will simplify thinking out loud in future posts dealing with more specific subjects.


The basic building blocks of the engine core are: Actors, Rooms, Exits, Targets, Actions and Story

The Actors are the subjects of the worlds. They are the only type of object in the model that can cause behaviour, not just react to it. Actors work on a timing schedule. Every "turn" all actors accumulate a predefined amount of initiative. They then take turn doing stuff depending on who currently has the highest amount of initiative. The player is prompted for input whenever a special 'protagonist' actor has the most initiative.

The game world is divided into a set of Rooms. Rooms are bound together by Exits. A single exit only goes one way, from one room to another (and not back again). Moving bidirectionally requires exits to be paired. This pair is smart enough that if one exit is locked, then the other side of the pair is also locked (by default).

Anything that can be acted on is a Target. Unlike the other core types, the Target is an interface. It does not have a concrete type, but Room, Actor and Exit all implement it. A room is available as a target for all actors in a room and all actors in the same room are available as targets for each other. Combining an Actor with a Target generates a list of possible Actions, the choices presented to the player. AI-driven actors could also use actions (in theory), but this is currently not used anywhere.

Story binds everything together. It instantiates and manages actors and rooms. Beyond that it's mostly acts as a façade that encapsulates complexity, hiding it from the (really messy) knockout-based UI code.


(Oh, snap. I just realised I've forgotten about the Translation andActivity types, but it can wait)

[Jordgubben]

Keeping it warm

(The following post is partially a re-edit of this post)

During January I've been doing a small experiment on my self (because test on animals is immoral). I decided to do something, if ever so small, with this game every day. I've often found that getting back to a game project is very hard once it "cools of", therefore I've opted to "keep it warm".

I've found there things to be very important.
1) Every day is every day.
1) Potentially tangible result.
2) Risk of (a small) failure.

Every day is critical to keep going. Tangible result are important because they are the only thing that move you forward. Risk of failure is important because they show if you are on the right path, or not.

So just thinking (really hard) about the game is not good enough. At best it creates scope creep. The "just thinking" part will happen naturally at other times as long as the game is kept warm.

Testing really small tweaks in code is very valuable, even if (or rather mostly if) the tweak turns out to be the wrong tweak and is discarded. I've found that doing very small incremental changes some times open up new discoveries, like a treasure room in a rouglike. I also get better at spotting new small tweak the more I do them.

Art (graphics) is another good activity. Not only does it have a high risk of "failure" (roughly 10% of what I've draw has actually ended up in the next release). It's also a uses a completely different mental fortitude resource than the one that solving technical problems (ie. my day job) consumes. So it's a good thing to do after a hard days work at te office.

I'm still testing this on my self so I'm not sure where to draw the line yet. But I'm fairly confident that "just thinking" or writing things down in a personal notebook is not good enough. Research is one grey area. Writing in this devlog is another. I'm not convinced that these two activities keeps a game warm. They may even (indirectly) cause the game to cool of a bit faster, because they give the illusion of keeping it warm. More experiments need to be conducted in the next ittration.

[Jordgubben]

I've been working almost every day since new years on this. A lot of stuff has happened.

http://superattack.se/games/nom-r6/

New and noteworthy:

• New path with disputes (of increasing difficulty)
• New IU layout
• Paged narrative
• Symbols improve clarity of dispute state
• Dispute Mechanics: Blocking and Posture
• Several new dispute arguments
• Argument presentation illustrations make it more clear who is saying what
• Navigation is simplified by changing the action name when returning to the previous room.
• Tweak how time works (again) - This time adding randomness and changing how the speed stat is used
• All (relevant) unit tests converted from jasmine to mocha
• Intro

Questions am exploring with this release:

• Can the mechanics be taught through play?
• Can difficulty be increased? (Is there "difficulty"?)
• Does the mechanic work with the story and setting?
• How much work is it to create one (propper) dispute?

Most obviously missing (from the top of my head):

• Active goal for the main character
• Final battle/Ending
• Release quality illustrations
• Progression system

Trying to assemble a concrete backlog (with estimates) has proven to be a mostly pointless exercise. So for this release I'm testing a new way to calculate progress. And yes, it appears I'm still moving backwards.

Aesthetics	20%
Story	10%
Mechanics	60%
Technology	90%
Average	45%

[Jordgubben]

Oh look, this devlog has been going for exactly one year today.

To celebrate, here is the current world map as a graph (spoilers?):

[Jordgubben]

I've posted the latest release in the feedback section. The main reason is to test if the game mechanic is understandable.

https://forums.tigsource.com/index.php?topic=53796.0

If I can get 3-5 people to play through it and post something useful, then I consider that a massive success.

[Jordgubben]

I'm starting to think there is a mathematical pattern to all creative work. Whatever one attempts, completing some work will always find 50% more work that need to be done. And completing this additional work will uncover more work roughly equal to 50% first found batch of extra work. To the total work amount goes from 100% to 150% to 175% to 187.5 % and so forth. It never reaches 200% but it gets infinitely close.

Since this project is as much about process as about outcome I will attempt to prove this with my current feature branch.

(I'm not completely certain that the constant is always 0.5, it' may vary with project and environment. But the general pattern is most definitely there there)

[Jordgubben]

So to test the hypothesis that there is always roughly twice as much to do than originally imagined, here is the test runner output from the first and (probably) last commit on my current (just completed, but still unmerged) feature branch.

First

Code:

 579 -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_,------,
 0   -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_|   /\_/\
 17  -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-^|__( o .o)
     -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-  ""  ""

  579 passing (863ms)
  17 pending

Final

Code:

 611 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-__,------,
 0   _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-__|  /\_/\ 
 0   _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_~|_( ^ .^) 
     _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ""  "" 

  611 passing (1s)

So where I initially imagined there would be 17 new tests there where actually 32 new tests. That is a scope creep of almost 90%. I have not falsified my hypothesis yet.