Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1369411 Posts in 64342 Topics- by 56356 Members - Latest Member: grui4

November 18, 2019, 09:40:01 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsPrune - Released!
Pages: [1] 2 3
Print
Author Topic: Prune - Released!  (Read 11171 times)
noethis
Level 0
**


View Profile
« on: July 10, 2014, 07:06:43 AM »



Prune has been released on the App Store! Go pick it up if you have an iDevice: http://apple.co/Prune




-------------------
ORIGINAL POST:
-------------------



Hi! This is Prune-a puzzle game about shaping trees. It's about trying to control and manipulate something that is inherently natural and random and beautiful. I have to say, I'm a pretty big fan of trees, so it's a fun game to work on. Smiley

Anyway, been meaning to start a devlog for a little while now. I've been working on the game for a couple months now, and am hoping to finish by the end of summer. I'll (hopefully) be updating this devlog at least weekly. Let me know if you have any questions!

Tweet at me: @mcdjoel



« Last Edit: July 24, 2015, 01:37:06 PM by noethis » Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #1 on: July 10, 2014, 07:07:31 PM »

Awesome. Congrats on starting the devlog! Looking forward to following this project.
Logged

0x0961h
Level 2
**


Quantum Demon


View Profile
« Reply #2 on: July 10, 2014, 09:28:00 PM »

I love this color palette and overall visual simplicity. Droop
Logged

Blambo
Guest
« Reply #3 on: July 11, 2014, 02:35:24 PM »

slick
Logged
jctwood
Level 10
*****



View Profile WWW
« Reply #4 on: July 11, 2014, 02:59:52 PM »

Loving the palette.
Logged

noethis
Level 0
**


View Profile
« Reply #5 on: July 18, 2014, 11:00:23 AM »

DevLog Update 01 – Transparency in Scoring
So I was hoping to show you guys something sexy this week, but alas, this was a week filled with less than sexy work. Part of what I did this week was make a little change to how scoring works. But before I get to that, I wanted to write probably far too many words about the scoring in Prune.

In The Beginning..
When I initially prototyped Prune, my first thought was to score things based on the “size” of your tree. But what exactly does size mean for a tree? Height? Breadth? These didn't seem quite right since you can have a really tall tree with no breadth and vice versa. Then I thought about what it is I’m trying to measure with the score—after all, scores are just an expression of how well a player executes within a particular set of rules. So in my case, I wanted to measure pruning ability/efficiency. Number of branches left is a pretty decent measure of that. But that doesn't necessarily distinguish between a close shave and a sloppy cut. Not to mention, there’s *a lot* of branches.

I quickly realized what I really was wanting to measure was the actual volume of the tree—i.e. - the surface area of every branch. That way close cuts would be rewarded, right? Here’s what it looked like:


It worked pretty well, overall. Sweet, moving on… But then when playtesting, I quickly realized people didn’t actually know what the numbers at the top of the screen represented. Now at this point, I probably could have put more into visualizing the score rather than having an abstract number—you know, like a gauge that fills up/etc. But there was a more subtle problem—the solution granularity was too fine. What is the difference between a score of 8.0 vs 8.1? Did I care? Not to mention, is it even fun to make the exact right precision cuts? (spoiler: no, it isn’t)

Ok, so obviously I need to ditch the opaque scoring system and just go with the old casual puzzler standby of collecting stars, right? I actually considered this for like two microseconds, along with the even simpler binary “touch the exit to win!” approach. It certainly works for some games, but for such an organic (hah) game like Prune it was clear I still needed something analog.


Eating Of The Fruit
So that’s how I landed on “fruit scoring.” It gave me the granularity I was looking for while being more transparent to the player. The score became a whole number of apples rather than those gross fractional amounts with the volume scoring. But I knew I didn’t want to do an apple per branch (or even for every ‘leaf’ branch) because it quickly became uncountable:


Since each branch already had a unique id associated with it, it was pretty easy to make the rule “an apple every 12 branches (at a certain depth).”


This was feeling pretty good. I could control it to where 20-30 apples would pop out on a given tree, making each apple feel somewhat meaningful, but still allowing for plenty of room for improving one's score.

But it also created situations like below, where there'd be noticeable gaps in the fruit. It doesn't look so bad, but becomes a bigger deal when you're pruning down to just a few branches and those few branches don't yield any fruit. Plus, the “every 12” rule is *still* not that transparent to the player (or even to me, and I know how the branches are id'd).


Soooooo... that finally brings us to this week. I still wanted a countable number of “fruit,” but it also needed to be a bit more predictable/regular. The solution? For every branch at depth n, spawn an apple or two on one of its child branches. Since I wanted around 20-30 apples on a given tree, n=5 would produce 32 apples on a perfectly dichotomous tree. Hey.. that works out pretty well. It's even got the predictability of being able to prune a branch at say, depth 3, and knowing that you'll lose 4 apples because of it.

(unrelated: trying flowers instead of apples now...)

Is this the obvious thing I should have done first before doing Every-12? Probably. Is this the be-all, end-all solution? Maybe not. It's still not fully transparent to the player, but I think I might be okay with that. Who knows, maybe next week I'll change it out for stars after all (probably not).
Logged

jctwood
Level 10
*****



View Profile WWW
« Reply #6 on: July 18, 2014, 12:12:30 PM »

Thank you for the insight into the thought process you went through during that development period. I appreciate it when devlogs give a deeper look into how they got to where they did rather than just what they had at the end.
Logged

noethis
Level 0
**


View Profile
« Reply #7 on: July 19, 2014, 06:35:41 PM »

Yeah, I definitely appreciate it when other devs break down their design/tech process (Tom Francis is great at this)! Hopefully I'll have more of this in the coming weeks.
Logged

Slader16
Level 8
***



View Profile
« Reply #8 on: July 19, 2014, 07:02:59 PM »

Yeah, I definitely appreciate it when other devs break down their design/tech process (Tom Francis is great at this)! Hopefully I'll have more of this in the coming weeks.
Oh yeah definitely, my favorite thing about Tom Francis is that he loves to break down his design process.
Logged

AlanZucconi
Level 0
**

PhD student at Imperial College London by day. Gam


View Profile WWW
« Reply #9 on: July 20, 2014, 06:56:38 AM »

Hey, I've just discovered this thread thanks to ScreenshotSaturday and... yes, this game looks amazing! I have a thing for games which take advantage of nature's beauty. Such as Eufloria, for instance.

One interesting "mechanic" in real gardening is that sometimes plants don't have enough energy to create fruits or flowers on every branch. And attempting to do this will simply kill the plant. This is also why some trees or flowers actually require have pruning to, paradoxically, help them to distribute their resources in a more effective way. It might be interesting seeing something like that in your game. Trees can have a maximum amount of energy and, according to how you distribute it, you'll end up with nice, big apples. Or with a lot of small, taste-less ones. Or, if you aim too much, with no apples at all because the exhausted all of its resources.

Of course it's just an idea, but since you're early in development I'd love to see more mechanics implemented! :D
Logged
noethis
Level 0
**


View Profile
« Reply #10 on: July 20, 2014, 07:04:06 PM »

Yeah, I still need to check out Eufloria--looks really cool.

Regarding the "energy conservation" mechanic, yeah, I've definitely thought about doing that. Haven't actually gotten around to trying it yet. I'm treating fruit as atomic, so it would probably play out such that pruning a branch would cause more fruit to spawn on other branches. It gets tricky though, because I want the score to reflect how well you pruned, so if I do end up redistributing the tree "energy" it would need to have some decay factor to it.
Logged

noethis
Level 0
**


View Profile
« Reply #11 on: July 28, 2014, 02:20:10 PM »

DevLog Update 02 – On Randomness
Wanted to write a quick post about randomness. But first, let me tell you a story about some bears. Three bears to be exact. There was Papa bear, Mama bear, and Baby bear and one day--

The POINT is, randomness is a tool in the designer's toolbox and, if used, it's important to have just the right amount. Too much and the game will be chaotic and frustrating. Too little and you potentially bore players. Randomness in game design is a little like properly seasoning your food--just the right amount of salt brings out the flavors in your game systems.

OK, enough with the terrible analogies.

One of my key aesthetic goals with Prune is the idea of 'man vs. nature', or learning to control the wild, organic patterns nature throws at us. So it was pretty important I got randomness right. But at the same time, it's a puzzle game, so things kinda need to be deterministic/consistent every time you play.

At first I just had the perfect platonic ideal of a tree, zero randomness. Great for puzzle consistency! Not so great for everything I mentioned above.

(mama bear)


Then I started adding randomness and it produced a lot of interesting trees! But determinism flew out the window--a level might require 15 "fruit" to pass, but the random dice roll of a tree could potentially only spawn 12. The other problem with this is that even if the fruit was consistent, the shape/location of the branches matters a lot when you're trying to prune and contort the tree into a tight space.

(papa bear)


Luckily, computer randomness isn't true randomness. Random seeds save the day! Each level will get its own unique random seed and will therefore have its own unique snowflake of a tree.

Now, since I'm dumb and hadn't really worked with random seeds much before, I figured I could just set the random seed at the start of the level and be done with it. Things were looking more consistent but I was still noticing some variability, especially in the upper tree branches. What I didn't realize was that, at least in Unity, the random seed gets "reset" (well, incremented) every frame. This is fine and dandy for most things, but in my case certain parts of the tree would take shorter or longer to grow and cause the upper branches to pull their random values from a slightly different part of the pseudorandom number sequence.

So it was just a matter of setting my special level-specific random seed # at the start, AND setting it again any time there's some sort of time delay (e.g. - a branch growing).

Now I've got perfectly deterministic, random looking trees every time. So tasty!

(baby bear)
Logged

noethis
Level 0
**


View Profile
« Reply #12 on: August 11, 2014, 07:36:21 PM »

DevLog Update 03 – Optimization
You wouldn't think a simple game like Prune would need any optimization at all. I mean, it's basically one tree and some circles. But there are three things you have to realize: 1) I'm a terrible programmer, 2) trees tend to have a lot of moving parts, 3) see #1. I've become quite skilled at hacking together barely functional, terribly inefficient code in the name of "prototyping" and then moving on.

When I first started prototyping things, I didn't really see any slowdowns on my PC so performance wasn't even on my mind. But then when I tried it out on my iPad 2 for the first time, it brought it to its knees. So I started reading up a bit on mobile performance and found I was basically doing everything wrong.


Put Your Draws Down
First order of business was to get my draw calls down. Turns out, keeping draw calls low is *super important* for mobile. For whatever reason, my branches were initially made out of quads instead of proper 2D sprites (in Unity). As soon as I would override the material color (e.g. - infecting a branch red), the draw call count would go crazy. Instead of a pleasant number like <50, it would spike up to 500 or so to match the number of tree branches.

Luckily, this was an easy fix. After messing around with trying to batch the quads and use a shared material, I found simply switching to sprites took my draw calls down to the single digits where they should be for a game with a single silhouetted shrub.


iTween, uTween, weAllTween
Since I had used iTween on other projects, I naturally began using iTween to animate all the tree branches growing. Again, this was pretty much fine on PC, but as soon as I tested on mobile I found that iTween'ing 500+ objects in parallel was A Bad Idea due to the considerable overhead. I quickly found a much faster alternative in LeanTween.

I also ended up just writing my own simple little loops for lerping stuff like branch color and branch size since I wanted it to run as fast as possible and allow for Prune-specific stuff.


You Get A Collider, YOU Get A Collider...
For my initial prototype, I made the (hasty) decision that each branch would get a box collider (set to trigger). My branches were rectangles, so they deserve box colliders, right? Of course, this was overkill, but I didn't know it at the time. It made things relatively easy to get in quickly since I could just add a bunch of OnTriggerEnter type calls.


After awhile I realized that all I really needed was a line segment to define a branch, so I switched over to Unity's Edge Collider 2D. This, combined with realizing I needed to add RigidBody components (oops), ended up improving performance quite a bit.



So Many Branches
But all was not well in framerate land, I was still having major framerate drops on my iPad. I knew the number of branches trying to update at once was a problem. Early on, I went from a tree depth of 9 to a depth of 8, which basically cut my branch numbers in half (~500 instead of ~1000). This was an easy change because that final layer of teeny tiny branches was pretty much invisible anyway:


But I wasn't willing to go down any further in tree depth. I still somehow needed to update fewer branches every frame. My hunch was to implement some sort of round-robin system, and after talking it over with Aaron San Filippo, I decided to try it. Dividing the branches into 3 "pools" and then having them take turns updating helped immensely.


Throwing Out Collision
Things were feeling pretty good now. But I'd still get the occasional slowdown, especially in certain "worst-case" scenarios. I wanted the framerate to be ultra buttery smooth and it was not always ultra buttery smooth.

Relatively early on, I switched from a collision based "swipe" to a manual line segment intersection based swipe when pruning. This did wonders for the precision and reliability of pruning:

In the back of my mind, I knew that I probably needed to take this approach with all my branch "collisions." I knew the best solution would be to just get rid of branch collision altogether in favor of writing custom "collision" code for my situation. Well, I finally got around to doing this last week and I can say that I'm now pretty darn close to ultra buttery smooth!


Future
I'm trying to avoid the whole "premature optimization is the root of all evil" thing, so I won't be doing these things if I don't have to, but two further areas I could optimize are:
  • Budgeting/throttling - Place an upper limit on how many things can be updated in a single frame. Queue for later anything that exceeds this limit.
  • Space partitioning - Divide the playspace into cells so that when doing my custom collision checks I'm only checking branches in the neighborhood.


So there it is. I'm probably missing some really obvious optimizations, but I do feel like I've learned a lot in the process. Plus, it's even kind of fun to squeeze out another few milliseconds (did I just say that?).
Logged

jctwood
Level 10
*****



View Profile WWW
« Reply #13 on: August 11, 2014, 10:33:26 PM »

This is a wonderfully insightful post! Thank you : ) I was just wondering if you are using UnityRemote at all?
Logged

noethis
Level 0
**


View Profile
« Reply #14 on: August 12, 2014, 07:11:25 AM »

I used UnityRemote a bit back when it was a joke (before it was updated). Probably should give it another shot. I've found a pretty good workflow working on PC and then periodically pushing to iPad.
Logged

jctwood
Level 10
*****



View Profile WWW
« Reply #15 on: August 12, 2014, 08:00:59 AM »

Well the update is very nice.
Logged

noethis
Level 0
**


View Profile
« Reply #16 on: August 20, 2014, 08:39:59 AM »

DevLog Update 04 – Planets

Just a quick update, mostly an excuse to post screenshots. Been working more on tree "planets" recently. I won't lie, they're maybe not super deep mechanically, I really just like the way they look. Smiley Plus it's nice to not always have to be grounded.

Oh, and don't worry mechanics-purists, I've got some interesting puzzle things planned for them as well.






Logged

AxBattler
Level 0
**



View Profile WWW
« Reply #17 on: August 20, 2014, 09:00:57 AM »

The planets look really nice! Well, everything else too Smiley
Logged

@APantaloni | Currently working on: Exgenesis | Out now: Avoid Sensory Overload | www.48hstudio.com
jctwood
Level 10
*****



View Profile WWW
« Reply #18 on: August 20, 2014, 10:11:52 AM »

The way the roots invert against the planet is genius, I love this project so much.
Logged

noethis
Level 0
**


View Profile
« Reply #19 on: September 12, 2014, 07:42:48 AM »

DevLog Update – Shadows
Been playing around with shadows the last few days. For a while now I've had a sun mechanic in the game, where branches would be attracted and grow towards any "suns" in the level. And this may not be common knowledge, but light sources tend to produce shadows! So I thought it couldn't hurt to try a quick and dirty implementation of them.

And by quick and dirty I mean attaching a long rectangular sprite and rotating it. Smiley

I figure SUN ~= PARALLEL LIGHT SOURCE so it's all good, right?


So shadows are pretty to look at and all, but what do they do? Inhibit tree growth of course! (see screenshot above) But I quickly ran into a problem--what's the difference between pruning branches before they enter the shadow and just letting them shrivel up and die in the shadow? Since the goal is to grow fruit/flowers, and since I didn't have any concept of early pruning redistributing the "tree energy" elsewhere, there was no difference.

So I made a fundamental change to the game. Now, pruning early redirects some growing power to the rest of the tree. It's something I've been wanting to do for awhile now but was afraid of the consequences of the change. It ended up not being as big of a deal to make the change as I thought and it makes for a more interesting, slightly more forgiving, game overall.






Logged

Pages: [1] 2 3
Print
Jump to:  

Theme orange-lt created by panic