next »

[Pfotegeist]

Hello,
I'm the sole developer of Bunneh. I'm making this in Unity.


Done so far:
Some prototypes and animations. 2D and 3D physical prototypes. "Dialogue physics" is a concept: So far there's a calculator, and for ease of increasing the data and therefor the realism I write an esolang.

I've learned a lot about programming GUI and C#. In object-oriented C# it's still difficult to input a large quantity of data in a pleasing way. After three years there was just no standard that appealed to me. Hopefully, I've found a way to bridge the gap.

Currently, I am writing an esolang for all things related to in-game objects connecting and communicating. Technically this can be done in 2D or 3D, text is a very abstract choice but following the dialogue physics path, anything other than text can be done after. A text back-end is preferred.



First Step to Make a Game: "Bunneh Demo" is going to be a very short standalone game with a runaway story.

Setting: It takes place in a fantasy world in a single dimly lit apartment bedroom.

Gameplay: There will be things to click on. You'll probably get roped into some kind of dungeon exploration behind Jerri's bed. Avoid eating furniture or Jerri will put Bunneh back in his glass cage. Investigate the inside of walls. Grab snacks.

Bunneh has a few thoughts he shares. He's stealthy in shadow. It's easy to hide under and behind things. Loud noises are scary, try not to hide near those or Bunneh will be caught.  

Jerri talking is distracting.  Jerri is very tricky at times because she sometimes picks Bunneh up, but she'll have to find him first. Bunneh can get very cute!

Warning. Jerri is an innocent girl at heart and in her closet rests a stuffed army. Bunneh will be very well hidden. Pro tip: Rabbits blink a couple of times per hour.



The full game title "Bunneh" will sport a very short story and a longer game.  It's probably best to leave it at that for now.

The target level of quality for visuals.


more from the same scene
pt2pt3pt4

[Pfotegeist]

Original post from: March 13, 2017
You're going to see a bunny. After years of practice posting on Tigsource I'm confident this will work.




If there is no bunny, the image isn't loading. This link could help:
http://i.imgur.com/gcgkGWX.


This is Bunneh. He didn't want his real name used. He's amazing. Uh...

Other features are in progress. *swish* - Pfotegeist

---->

Iterating over bunny design. Earliest model started Feb. 2016.



same stuff gallery
http://imgur.com/a/vqTgz

[Pfotegeist]

is a compass, don't ask me for directions.

vidyb
http://i.imgur.com/XSiCNdc.gifv

[Pfotegeist]

http://i.imgur.com/KDsOt1m.gifv


http://i.imgur.com/OF8sZbB.gifv

Short version:

I started checking to see if I could manage the 2D/3D interface blend. It was already there, and too easy. 10 seconds of clipA.

I expanded to 2D/3D physics modules, clipB.
I decided I wanted to prototype the next GUI "toy".

More details.

Setup:
visual: 3D there's a standard shader and an outline shader. The color change in this case is taken care of by overlapping a 1x scaled cube with a 1.01x scaled cube.

coding: This is done in Unity C# and takes advantage of delegates, enabling/disabling children to toggle their functionality.
basic example:
Onenable a child class subscribes to a HUB class with many delegates
Ondisable the child unsubscribes


gui concept (magnets): Stuff in 3D touching stuff in 2D. It's very distracting.
I finished the compass system by cleaning up a script I already had. Making is push around physical bodies with 2D physics (ref. previous post).

The Resulting Log:

Code:

2D/3D/magnets
	o 2d thing
		
		o hover
		o click / toggle
		o lock / hide, 
			simple as disabling appropriate control
		o physics
			o collision 
			o fling
			o slingshot + solo module
			o slip out of grip (forced release)
		o drag-drop -
		o on other 2d thing ( required collider 2d, trigger requires rigidbody 2d )
		o and pick it up again from the dropbox / droptarget / catcher
		
			
	3d thing 
		o basic collision / distance check to activate functionality
		
		mouse
			o hover
			o click / toggle
			o drag
				o work while active
				o limit to range
					o alt: no limit if held
					
					oo extend
					o no slippage, move back in range if held
				o disable limit, but use the same actions....
					
		physics
			o imitate the 2D module
			o slingshot / cannon
			o interest: difference of moving from an origin vs camera
			o problem: difference of moving screenposition vs worldposition
			o vexing: similarity of HingeJoint2D and HingeJoint (eg the limit of 1 axis), ends up using SpringJoint, wobbles.
			
		drop effect 
			o hover range warning
			o drop within range of a trigger (eg. the selection limiter)
	3d thing 
		instance and storage (untested in 2d thing)
			o spawn on click
			o limit spawn with item manager, a bit too simple
			
			o spawn when clicking a charged dispenser 2D or 3D
				o the dispenser can store the exact object

	made a more abstract class for dropper/droptarget
	
	Magnet
		o switch between 2d and 3d behavior
			I accomplished this by switching objects
		o Still be holding it if there's a switch while I am pressing the button
		o A mouse-hover for speciic targets is now very easy to check. A drop-hover is not as clean but uses the dropped object's collider.
	
	Better canvas collision
		o A 2d token instance representing my cursor.
			Makes more sense for multi selection. Well hey it's there now, I can change it as I please, and change what it does as I please.
			

	surprised by the fact I can use my activation while holding button combo instead of clicking on things, and it isn't terrible.

	Some basic scene loading	
	o Take a bare room.
		load the objects from another scene
		delete
		repeat once
	
	cover current view with menu
		2d	
		x UI, easy, canvas grouping
			Maybe for final, with animation
		change the scene to blank room
		
		change the scene
		
		x 3d
			Optional. why? 
				x 1. if I prerender a 3d scene I could use it like it's a 2d scene.
				2. I can change to a different 3d scene, between loading. (ala Assassin's Creed)
	
	^ done with a sequence 
	
	Satisfied the requirement of persistent objects with one easy script. 
		Can't be duplicates.
		Won't automatically destroy.

[Pfotegeist]

The human is named Jerri.

This week I think I'll make a bare minimum behavior tree that satisfies some need to have her walk around and interact, based on location. I think the tree will be sorting through something like this (highly inaccurate prediction  in 3 2 1).

Code:

Moving
Wait

Bunny
	Comfort
	Pet
	Food

Cage
	Feed Bunny
	
Bed
	laptop
	sleep

So that's what I need to accomplish. The resources I've reviewed after waking up today* are merely an inspiration. Work will start tomorrow.

Why behavior tree?
I have tried a conditional loop but I've optimized my programming recently with a landfill folder and scripting hierarchy. Enable/disable game objects lets me turn on/off large chunks of code, which is what conditional loops would do. (In Unity: OnEnable, allows me to decide if I execute code that frame. OnUpdate (an optimized version of Update which is called by one update manager) lets the code repeatedly execute.)

What I have atm.
Bunneh has hiding spots, movement, and some effects that alter movement.
Jerri can lie on the bed, move, and can see Bunny from her eye.

This is what the hierarchy looks like already. Pretty much. Although the behavior tree is currently a timer.

Code:

Jerri.Context 
	Global resources, such as nameless NPC, anything Jerri related Jerri doesn't need to know.
	Jerri.HUB: A HUB that lists the active named strategies
		
		Jerri.NPC, Behavior Tree Root
		Jerri.Resources
			
			Body (Animator+Nav Agent+Rigidbody )
				Colliders
					eg. arm length, feet
				Meshes

The real hierarchy looks like a mess atm. My early diagrams of how the NPC system worked aren't descriptive enough.

This is what I want to have :
AI use strategies and response strategies: In this case I interpret strategy as a behavior that takes resources.

Behaviors found in a tree below the HUB class.
1. submit "name" on enable. a string indicating the behavior.

2. behavior tree nodes, well, consider which ones I actually want to use.
   

Initially Jerri will have a list of named behaviors, set using a behavior tree. Any responses can be determined from the list. The behaviors they don't respond to are left up to the player to identify. Well that's the idea.




*
http://aigamedev.com/open/article/behavior-trees-part3/
http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php

[Pfotegeist]

Behavior tree with working repeat, sequence, parallel, and waiting.

Currently does nothing but blink.

[Pfotegeist]

I'm getting too excited so it seems I take a break. The behavior tree already 3x deeper and the first challenge of writing proper leaf nodes. I finally replaced the original timer based ai.

Jerri now patrols and walks up to Bunneh in a logical manner but doesn't pet him :sadface:.


do I... do I post a gif? I'm remembering my entertaining guide. I should advertise early as possible. It's reached quality I can accept, here goes.

part 1


click on these to see everything. (4 mb average)

pt2pt3pt4




Not game related. Programmer stuff:
My thoughts on behavior tree:
I'm able to extend the code indefinitely, each decorator is like a function in Python.

I've read formalized behavior trees limit the executing code to the currently active tips. I pretty much wrote the exception to that right away, which added a state system. I read that this is what I did, so that's neat.

Inevitably control logic becomes very abstract and maze-like, which isn't suitable for OO programming. Behavior tree is unnecessary for script junkie, but easier on OO programmer and easy to represent in flowchart. 

I'm not really convinced formal behavior tree will be flexible, but I think a template-based functionality which allows case by case adjustment is key.

my version of an #include would need adjustments continuously, it could probably be emulated through scripting with parameters, and +/- of the base functions
#repeatInvoke {base:repeat (2 times) -> delay (2 seconds) ->} connect the effect leafnode

 result: (2 second pause) effect, (2 second pause) effect

#repeatInvoke - repeat, effect
 result: (2 second pause) effect

scripting would be straightforward with one leaf node per module

while in a behavior tree you'd generate a visual... which is more straightforward when an include could have many options, and multiple leaf nodes.

I'll look up scripting languages on my break now that I think I could actually learn something.

[JWK5]

It looks pretty interesting, I'll have to keep tabs on it as I am looking forward to seeing where it goes. While I like the colors and styling of the 3D elements I absolutely love the icons, they very much remind me of the GUI/HUD elements of Okami or even Persona 5, that very stylized and bold/contrasted art. I think you're on to something special here.

Keep up the good work!

[Pfotegeist]

If it isn't obvious I am working on features. After the features are thoroughly completed they won't be user friendly, but I intend for it to be easy to construct a narrative that loosely resembles my imagination.

I haven't thought about this for the past 3 weeks, so I cleaned up any loose ends in my daily routine for now.

This is what I'll be thinking about to reboot the creative process. I'm describing a state-like structure, which can be represented through audio, ui, animation, or any future feedback features I implement.

Easiest example is musical scores setting the mood on television / cinema. It's important that I find a parallel in the various features and visual just for the sake of allowing mastery.

I'm probably not going to show progress soon while I reboot the creative process. I will be thinking of how cues impact how the player interprets the game and probably writing a bucket list of potential features until I reestablish what can be done right now with the new things I've introduced from just the behavior tree and gui.

Code:

state changes
	When she wants bunny (situational irony)

conditions
	sight / hear
		eg when she says "Bunny" that is a condition
	proximity
		signify proximity matters
		I suppose I could state this with a timer
	
crit/opening/chance
	chance: an action can have a very different outcome
	introducing a tool that will cause a very simple outcome
	
anticipation 
	prior to any of the above, there can be an anticipatory notification

It sounds simple. This in itself requires some refining. Similar to when I described behavior trees the actual result of the pseudo logic is something bigger I have to work through repeatedly until it comes out right.

Oh that's right I thought of an easy example for this.
So imagine you have a game with multiple colored dots and a colored board.
state: Changing the color of the board would indicate a level/state
conditions: Changing the color of one peg is a condition
critical opening would be introducing a tool that changes multiple pegs
critical chance would be having pegs randomly light up so they can change multiple pegs
anticipation: having every peg that would change light up before the player makes the decision, and having the board light upbefore the last one is changed (indicating the level is almost done)

This of course assumes the feature you have are peg colors a background and some way to know the player is hovering. Fairly simple in cg.

[Pfotegeist]

Just a random thoughts update

I worked on Bunneh's animations, he has some great animations, but this is the issue. I only use half the animations atm because they were scripted without behavior tree, so I'll probably redo how his animations are picked when I script him a nice behavior tree.

I didn't work on Jerri's animations so these are the animations she needs to look right


pseudo hierarchy

Code:

jerri.animation
	pose = state ( animation state )
	
	pose.stand
			.walk
			.idle
			.reach
			(both arms, move body)
			
			.hold
			.admire (look down)
			.give (what I'm holding)
	pose.bent
			.idle
			.reach
	
	pose.kneel
			.left
			.right
	pose.crawl
			.move
			.idle
	pose.inbed
			faceup
			facedown
			side
			.idle
			
			
			.side.laptop
			
			edge
			.idle
			.reach

There's actually a bit of an abstraction to this pseudo hierarchy because I don't have IK and I probably wouldn't use it right anyway. Reaching is going to require several poses and I'll blend between them. I did something similar with bunneh's ears so I could script him turn his ear.

yep so they will probably start as poses so I can check if they look good, then idewally I'll add some transitions and movement and she'll suddenly look different, just from the animations. You don't believe it, I don't believe it, but the same thing happened with Bunneh. I'm convinced I should do the poses, and then I'll slip back into full gamedev again, probably by next week I'll plot the behavior tree that drives the actions Jerri makes as well as the animator states.

I personally only think of opening Blender and doing some animating there. But I do have a description of much of the game prepared long in advance.


Here is a roadmap when I try to breakdown what each major step in development currently looks like when I look up, outside my current scope

jerri animations
jerri behaviors
bunneh behaviors
status module (override the behavior states)

somewhat abstract. entering enjoyable game territory.
applying the UI on everything
work on minigame delivery
begin testing NPC dialogue

[Pfotegeist]

Human's animations and after much waiting, Jerri pets things.

Jerri pets the cube.



Jerri pets this bed.

[Pfotegeist]

I updated Bunneh's Blender armature, the early setup attempted the use of IK and had many extra bones with movement restrictions. The heck with that. Now Bunneh has forward kinematic and whole face moves.

Bunnies don't blink more than 2-3 times per hour so it'll look more like this in-game.

[Pfotegeist]

I'm not finishing this because it would enable shitty people to understand important social matters. This is something I've been struggling with while deciding if it's worth the inherent risk advancement poses.

From the very start the issue has been that other people who don't deserve an opportunity would be granted one. The fact they're genuinely bad people I shouldn't help is new.

After a long adventure into other game communities it's come to my attention that I'd be endangering lives. It is definitely not worth the risk by enabling strangers with negative goals.

I'm stopping the game's development.  It's not happening.

[Capntastic]

Here's to more fun stuff in the future though

[Pfotegeist]

I'll try some other thing. It's not an exit from game dev. I'll be here.

[Pfotegeist]

I was thinking of how to introduce the game.

"Your mission is whatever the bunny needs.  The bunny can be all powerful, the bunny can be clever. Make Bunneh very happy. (But first, you should pet his nose)

The core feature, the bunny-memory, is the entire game.

You will need some things to empower your bunny memory... sometimes bunneh has an idea.

There's a story, or uh, is it your story?
There are some really easy books, I think the bigger bunny buys a few. Grow a library of personal knowledge, you just need to eat a few while she's out.  You could learn to read them but tearing out pages is so easy.

No matter what, make Bunneh happy."


MORE ABOUT WHAT I'M DOING
I wrote a lot.  Enough to figure out exactly what the game needs programmed, but not enough to predict how I'll program or animate it.

Programming smarter, understanding "game object" better, and linking them together. so it's not a matter of if I can, but rather, how much can I get done in a day? Which I really don't know.

I have a dialogue prototype in the works.  Interacting, I mean clicking things, and with the added dialogue UIs, the "dialogue" is meant to be one of the most dangerous fun aspects of the game. It'll be ... augmented as I keep programming, like an "augmented super dialogue game"(TM).  The second best aspect is the stealth system of course, which is easy to understand, works perfectly :wink:.  Then there will be jumping, which I wrote in length about. Then there's other stuff I wrote about, it's a big mystery what I include or not at this point.


the order of things now:

model small, draw a little, animate (animate less), program, write big, program more

project order:
1 prototype parts of demo
:dialogue version 1, memory prototype, the full controls with jumping, Jerri (behavior has been reworked)
2 try to make a conclusive free demo - start asking for donations
3 the rest of it
:many interface(s)-as necessary, bunny memory, final dialogue driven story, more than the necessary content to supercharge the bunny memory

[Pfotegeist]

I worked on ui. There's a small issue about gathering all the raycasts into a reliable list, but I wrestled with it and nevermind it's a Unity thing. I also spent some time on text, I need to be alright with that before I release the prototype because it has high risk of slowing down if I don't completely solve the program ahead of time.

Major effort was put into the Datesim, the image zone (very important), this emulated laptop was for effect really, and that stuff all explains itself.

Here is the alpha progress. It should look something like this when it's ready to be tested.

[Pfotegeist]

As an objective outside observer I need to actually see this game with my eyes before I'll believe a word of it.


There are a list of features, and so far I've got.

1. 3D bunny
   a. stealth
   b. animated
2. very good point and click ui
3. webpage level of text ui. actually harder to program in unity than you'd expect.



the text will reach wiki levels of markup, then I can start the bunny memories project.

This was the order I said I'd do things right? I'm checking.

I was pretty vague earlier. So this is good.

I'm not finishing this because it would enable shitty people to understand important social matters. This is something I've been struggling with while deciding if it's worth the inherent risk advancement poses.

From the very start the issue has been that other people who don't deserve an opportunity would be granted one. The fact they're genuinely bad people I shouldn't help is new.

After a long adventure into other game communities it's come to my attention that I'd be endangering lives. It is definitely not worth the risk by enabling strangers with negative goals.

I'm stopping the game's development.  It's not happening.

it's true I go through a struggle between fear of being famous, and the silent 'vote' of common people to make their lives worse. But I'm pretty sure that with enough writing I can make my game bullshit enough it won't make any difference at All and I'll slink into the darkness when it's over you 4l1j235l12jkl!

back to work

[Pfotegeist]

The bunny memory has some flaws.

The first column of text is raw code. In the second someone would have read and started talking gibberish. The third column might be all a person on the other side of a wall could hear. After a few minutes the memory mutates and a logical memory which would be, I'm guessing.

Bunneh
Bunneh         
mmmm
         Bunneh
             stuff in curled braces is preserved for show

[Pfotegeist]

I have a script walk through the whole text a character at a time. But I am also getting a bit better at using old knowledge.

After some additional work the code is now rejecting anything I haven't registered, so I know if I misspell anything important. Also I have colored it and emboldened it so it will mock me in tasty green text.




Probably interesting to programmers only.
I am not so secretly but badly displaying that the text is turned into completely unique data packet.

for example. something points to a stream to perform a more direct action

1 scan a stream: I can check if a stream can receive, logically. Paper receives haptic. It take extra steps in a parser during the stream to determine how much is being written ala the third box.
2 use method: basically a standard set of virtual methods. Theoretically writes to a stream with special text triggers, if the method's implemented. I hear it's a good use of Oo programming.

everything is intended to pass through all potential streams, just in case

this multiplies the number of text packages and it'll need more writing, something I'll be willing to do. A lot of packets will disappear since the remembered streams are limited, bunny memory oriented, but it increases the potential for idea mutations, seeing but not hearing what someone says, and behavior triggers when NPCs are given a rudimentary stream that only toggles boolean operators around, and memorizes a few things that they're programmed to remember if they heard (future feature).

tldr Probably interesting for example. scan a stream: use method: everything is intended this multiplies the number of text