This looks amazing and that is a very awesome trailer! Best wishes and following along

One more:



This is the walking animation above, but with the extra layer of animation added. This is final.

[First, what I'm working on:]

Updating this really quickly to get more into the habit.

First, what I'm working on:

This week I have been putting the first enemy in, a guard robot:



First animation test. Just using a pre-existing animation to see if it works.



Run cycle. This is asymmetrical, which meant it required a bit of planning to look OK. It's 7 frames, 5 legs that all move independently. This animation is missing an additional layer that adds e.g., wobble effects.



Hit responses. This incorporates everything, so this animation is more or less complete.

I'm really going hard on this.

Next, Some Changes

You can read a full blog post (below) about some of the design challenges I have been having.

Short version, though: a few life changes, which meant that external pressure was much less, combined with extensively testing the game at Calgary Expo (I had some people play for 2-3 hrs) have made me face the fact that the timeloop mechanic-- which I have based the entire story around-- is just not suited to this type of game.

Paradise Never is excellent in what it does well, and the game is incredibly strong technically (I have never had a project that is so much fun to work on and gives me so much flexibility) but the road I was on will not result in an excellent game, because the good parts will be frustrated by the bad.

So: the story part of the game has been rebooted without a timeloop. This isn't maybe as major as it seems and is a huge relief in game design terms but it does push the release back quite a bit. I was maybe a few months from a chapter 1 being released so... yeah. I could have made it work, and the good parts would have been very good but it would have been a frustrating thing to play through. There's no way around it, gotta go thru!!

If you're curious, please do read the blog post, here:

http://kittylambda.com/index.php?p=journal_2017-05-13_paradise_never_update

A lot of people focus on "finishing" their game. The standard advice is, "just get it done" and for small things, yes absolutely push it out so you can learn and get on with life. But with a big project, where you already know what you're doing (I sorta do by now), this approach might be the wrong one. A game that is 95% of the way there will be about 40% enjoyable-- that last 5% will ruin everything else, mostly. Paradise Never isn't a "learning project" for me. So instead, the mentality has to be, "do whatever you have to do to make it 99% good."

Right now I'm working very hard building a vertical slice, hoping to show it in Edmonton in September at something called GDX. In the past I've resisted doing this (vertical slicing) and instead have been sketching out the entire game first, then layering it up. Now that I'm rethinking everything I am just... why not? It's not a bad way to work, since it eliminates so many unknowns, and a vertical slice makes the game a lot more marketable since you have finished things to show, as well, which could factor in if I decide to run a kickstarter.

For your reference, the OLD planning spreadsheet (for Chapter 1) was at: (3999/4964) Kind of unbelievable, if you see this spreadsheet you really get a sense for the scale of making games like this. And it would have grown more (but not a ton more, actually... it really was that close!)

But who cares?

What matters though is that the NEW (i.e., current) planning spread sheet is at...

(242/346)

*** BRAIN DUMP TIME ***

Now's a good a time as any...

TIGsource has warned me that I hadn't posted in over 120 days. Wow!

I'm not sure exactly what or how much I've changed since then. A lot, naturally.

I finished my first playthrough of the game in December; I took about 600 notes during the playthrough. It is absolutely true that you need to watch other people play your game-- I've done this quite a lot by now (not as much as I'd like, though.)

But it's also true you got to learn to watch yourself play your game. This requires mindfulness. In the same way that you can be blind to things because of what you are used to (this is the conventional wisdom for user experience) you can also have additional insight that you can't get from just watching someone else. Your own thought process can be incredibly insightful if you can learn to pay attention to it.

Well anyhow.

Needless to say, the playthrough notes added quite a lot to the list (about 400 items) but progress is still really good. Most of the playthrough notes were based around awkwardnesses or bugfixes that needed to happen. Cleaning these up means the game is feeling tighter and tighter all the time.

The larger problems are mainly:

- The moment-to-moment gameplay is still not good enough.
- The main timeline quest works well, but needs to be expanded.

Moment to Moment

I'm addressing this by adding some additional obstacles. Basically, if you try to reduce Paradise Never, most of the game is walking (or boat-driving) from place to place. This is the essence of RPGs, though it's not the first thing we normally think of.

Expanding and finetuning the world generation will help address this, since going from place to place will be more to see, which is more interesting. (This is already planned, though it doesn't make it into the planning spreadsheet since I draw it into a black book.... maybe I'll describe this later.)

But more than that, I need obstacles. I had hoped that maybe the design would not require this, but in fact it's just a proven tool and by avoiding it all I'm doing is tying my hands behind my back.

What's an enemy, or an obstacle? A lot of designers refer to this as friction but really what I need is not so much friction but a more frequent risk-reward cycle. Friction, to me, is the breaking-up of a line tha the player would normally navigate in the pursuit of a goal. So a simple block in their way, or a wall to walk around. This could involve a reward (for instance, slashing a bush to get a rupee) but friction doesn't involve danger, per se.

What is needed is to imperil the player, somewhat, to give them intermediate objectives that change. Otherwise, the map layout gives on it's own all the information they will need for the next 5 or 10 seconds, which can be boring since nothing is happening in the interim. All this is just a long way of saying I will add a few simple enemies (robots) that do not affect the narrative flow. These are pretty simple to implement and will add a huge amount. My main reason for resisting was to try and keep a kind of aesthetic purity but it's maybe a bit too lofty.

This is a late addition, but it needs to happen. I've already added two enemy types to the plan, I will go ahead and put them in. When you're playing the game, you can think back to this post and say, "wow... such a large gameplay element added so late! how unconventional (or... is he just a terrible game designer?)" (note that both can be true but in this case I think neither is.)

Timeline

So the game has a timeline of three repeating days where events happen. What the playthrough reveals I have neglected is there is nothing pulling you through, only pushing. In other words, the game is very busy doing things behind your back, at all times, to keep you busy (there is (truly) no "off-screen". A key design conceit and not simple to realize.)

However: you yourself do not feel like you usually have a goal. A quest pointer saying, "go here next" is the major-fifth (I am making a music analogy, I mean) of game development. Yes you can avoid it but it's idiosyncratic. Well this analogy is probably going too far (quest pointers are not really that fundamental), but what I'm saying is, having a clear goal is not really a negative. Having only mundane goals or uninteresting actions, is, however, and I feel when people complain that something is "too linear" this is more what they are getting at.

It's not fun to always be reactive, but the current design is sort of too-much-that, because it's driven by timeline events, not quest goals you are pursuing. So in order to fix this I need to add more main timeline quest goals so that you always feel you are being proactive. I won't go into more detail here except to say, this can happen within the confines of the existing systems, so hopefully it won't be too much work.

I've spent a lot of time mulling both these things but I think they are the right solution.

Game Designer

I've always struggled with game design; I don't think I'm a natural game designer per-se. Aspects of game creation come naturally to me, but I don't think always that clearly in terms of what systems make sense. Please don't think less of me, or anyone, for this.

I rebel against the notions of minimalism or perfection. I'm doing what I do, because in one sense I want to and in another sense I have to (creatively, I mean; not so much practically.) In my case, I do want to create something enjoyable as a game in the conventional sense; that's always been my goal. But I don't have to justify it or reduce it to it's ideal formulation.

Climbing/Jumping

I've also added climbing/jumping mechanics-- this is a huge change to the game so late, but it was easy.

Paradise Never is extremely well organized. It's really complex, but I've done the right thing throughout and reworked things as they needed it, even if that process is a little messy. As a result, making a change like adding jumping/climbing mechanics was very doable. Anyhow, now that it's implemented it works well and feels really nice.

The jump mechanics are basically ledge-grab, and then jumping off a tall surface. The geometry of the game is such that the player can fairly easily climb most walls; however others like barbed wire fences and hedges cannot be climbed. This feels about right.

Most buildings can also be climbed up on, with a higher jump; however, I will make this require a special item to enable. Jumping off a building triggers an attack hit, which is sort of fun. Depending on the height of the building, you might fall over when you land.

I can make NPCs climb walls, but I won't worry about it for now.

Animations/Art

I'm working with an artist (not yet announced) to do some art. I'm doing other art. I've finally gotten to re-doing the items in the game. This is final art and they look fantastic but I'm not posting any here, right now.

I'm also redoing all the NPC animations. There are almost exactly 100 of them. Some take an hour or two to do. They need to be re-done because they are not readable. Improving them is going to (I hope) improve things a lot. They are higher resolution. This work will take about a week of full-time work. Absolutely exorbitant amount of time on one thing which is why I had put it off for so long. But it can't be avoided.

Once that's in, I can start adding the final NPC art (which is all drawn, now) onto the NPCs. This process itself requires some work but at that point (wow) the NPC art will be final. As in, final final.

It's very late. Good-night.

(2800/4047) (yes, that's not a mistake. oops.)

Good. Combat is overdone anyway

Seconded! I kinda love the idea of an "information" based exploration game, which could work so well since the world is immense, you have to make smart choices to "mine" for the info you need. Well that's my $0.02!

Some Beach tiles. Should look pretty cool when we get the shore animated later:

Hio!! I am /really/ enjoying following this project, the screenshots are gorgeous

Do you have a twitter account you post these screenshots on? If not is it OK to repost the screenshots to my twitter, linking back to this thread? I just wanna send you some more people!

I love the village scene's colour palette especially. Following eagerly

Game looks really lovely and I love the concept of the Vision Game System. Thanks for putting so much work into your dev blog, too!

Keeping this dev blog alive Happy Friday!



I'm churning through NPC combat stuff right now; there's still a fair bit to do here and it's very intricate, so as a result the list tends to grow at a large rate these past two weeks. I.e., I'm finishing tons (about 30 things a day) but adding tons, as well. However, this is the last of the difficult stuff to do; after that it's really just world gen content/rules, quests/scenarios, dialogue, and art. I am looking forward to being on that particular home stretch, as long as it might be.

The boat above is one I made a long time ago. Today however I had to adjust some of the boat physics. Basically there are a number of z offsets to consider:

1- the "true" z offset of the particle; this is relative to the hitbox for the boat.
2- an offset for the boat model that is rendered
3- an offset for the waterplane, per boat, so that some boats ride higher in the water than others
4- an offset for the ground, so that some boats touch the ground (and beach/sink to) different level than others
5- an offset for the waterplane, this time that controls how far under the boat has to be to take on water

I had these mostly in line until today I realized that the physics were too high. This was a bit hard to notice because mostly boats just crash into other boats, and since their hitboxes were all essentially above the waterplane by the same amount, they would still collide in a normal way.

However, NPCs were able to swim through the boats. I thought this was because I didn't have collision set between these types of objects, but when I went to turn it on I discovered that wasn't the case. So then I rendered the hitboxes, and realized they were floating somewhat in the air. The NPCs were swimming underneath.

This explained another bug I had seen but not investigated, which is that boats which had sunk were sometimes colliding with boats that floated over them; in retrospect this of course makes sense, in part however this was because the ground offsets were correspondingly out of whack.

Basically, I need the hitbox to align so that the top of it aligns to the boat "deck". The hitbox itself is always centered on the particle, and this can't change. So step one is to align the visual of the boat so that the deck lines up with the top of the hit box. After that, I can go through and adjust the other offsets without worrying that something will look broken later on.

The hitbox has a limitation; basically has to be as wide as it is deep; it can be longer however. Actually it's an ovalized sphere, stretched along the boat's "front" axis. Good enough, however. It's just how I'm calculating the physics, which are very stable and fast but not perfect or as flexible as they would be if I were using a third party physics engine, which my religious order forbids me to.

So anyhow, it actually took a long time to sort through all this for the existing boats, even though there are only 6 or 7 of them, but it's working alright now. The final game will have many (many!) more boats, so it's good to get this completely correct now, rather than later. And I have a process for tuning new boats when I add them, that should make sense and make sure I don't forget the order to do the tweaks!

A bit about the planning spreadsheet. I feel like the list will likely grow to about 3000 items in total. Based on my current progress it should be possible to maintain about a 30 items per day average, actually maybe a bit faster as the stuff I'm doing right now is difficult by comparison to a lot of the content stuff which is still to come (for instance, every line of dialogue has an entry in the spreadsheet.) So that puts a "done" date about 75 more days of work! Four months might seem like a long time, but to me, it feels like it's just around the corner. Such a relief!

(754/2369)

Thank u pal )) PS wandersong boats 100! 100! 100!

Been working really hard the last couple of weeks, actually feeling a bit burned out today. At any rate, I am texturing the buildings. They key is not so much, can I texture buildings, but, how can I do it so that it doesn't create too much work. The technical side is actually a bit more complex than it might seem, because the textures need to go into an atlas, yet they need to wrap. You can figure that one out if you want

The textures themselves are gradient mapped, each building has a single gradient colormap and then I choose coordinates in that image along with a greyscale gradient image (hand drawn, as above) which then creates the final gradient image. This helps keep the building color scheme homogenous.

From the greyscale image we can also generate a bump map and effect maps using a simple mapping function. So I am actually generating three textures: a diffuse color atlas, a normal map atlas, and an effects atlas; the effects encode r = reflectivity, g = gloss, b = emission. It's a useful system and managable.

The other thing I put in today was a simple system for better handling pointer-snapping in the UI. So for instance, a UI element can be set to have a "left" neighbour which it will snap to when you press left. The UI system right now tries to make a guess as to where to snap the pointer to, and it's a reasonably sophisticated guess based on positioning of the cursor, size of elements, etc., but it often doesn't make sense. So this will let me set it explicitly without much work. The UI system itself is really nice in how it works, I should do a post on it. Paradise Never has a ton of UI stuff, so a good system is really important.

About 26% of the way through the list, a good milestone. And most of the hard stuff was up front.

(595/2227)

Made a pretty forest and some butterflies:

Very nice!

Steadily working through some of the harder stuff to do.



One of the smartest things I did with Paradise Never was make a really robust object manager. It manages containment and positioning, together with loading sprites in/out as you move around. Objects can always be operated on even if their sprite isn't loaded, this is important so I can for instance have an NPC turn on a street lamp even on the other side of the map.

Other times, it's great because e.g., I handle fire through the same system, so fire is an object that gets placed inside an object in a certain type of slot. If the object doesn't have that slot, it can't catch fire. Likewise, fire looks for nearby slots to spread to-- so if an object is flammable it really is, there's no special code required except for a callback that the fire makes every so often to tell the object it's being "consumed" (the object can decide what to do about that) and a "fire type" property for objects that says what type of flame to use.

(374/2111)

Good progress today but can't really describe what I was working on without spoiling things.

The way I've organized my tasks is to do the most feature-heavy first.

In practice this means doing the harder things first.

There are about 3 or 4 major feature groups that need to be sorted out, basically fairly dramatic things that have to happen that will require a fair bit of custom code; I've finished one of them today and now am started on the second.

In addition to this, I'm chipping away at textures by trying to draw just a few each night.

(342/2078)

More work on things I don't want to reveal, but a productive day. Fixed a lot of bugs.

***

Here's something I can explain a bit. In general, the NPC AI is organized into a heirarchy like this:

[behaviour controllers x N] [scenario controllers x N] <- default behaviours and scenarios; each can have an action priority)
        |
        |
        V
[main controller] <- can exist in one state, the "action priority"; chosen from the above based on priority)
        |    \
        |     \
        |      \
        |       \     [travel manager] <- used by travel controller to plan trips)
        |        \         /
        |         \       /
        |          V     V
        |   [travel controller] <- used by main controller to perform travel related tasks; complex)
        |        /
        |       /
        V     V       
[body controller] <- shares this with player; very basic things)

All these run in parallel to each other; so for instance, a behaviour might decide that it's nighttime and generate an action priority to go home; the main controller might pick this up, depending on if anything else is going on (this priority will be ignored e.g., if we're being attacked, or even if a certain scenario is playing out.)

But if it does, then it will engage the travel controller and say "move us to HERE" (where HERE is defined by the action priority set by the behaviour, i.e., we want to be inside our house.)

The travel controller then sets the travel planner going, which does some pathfinding and so forth and comes up with a travel plan. Any of this can be interrupted, and for instance this (as you might expect) does result in NPCs standing around for a bit while they decide how they are going to get home.

What can happen though, is the travel planner can fail; for instance, the NPC could somehow have gotten stuck, the pathfinding might be taking too long, etc. What it does then is the dreaded "warp shift", i.e., it will try to just jostle the NPC around by warping them to a nearby open spot (it also tries to detect a few other situations and deal with them reasonably.)

So that's how that works. I fixed a bug with the travel failure states today.

(329/2062)

Sort of a long day so not going to go into detail, steadily working through the list and fixing bugs here and there as I go along, too. Yesterday I recorded video for the dev blog, just have to edit and put them together.

(308/2045)

Yeah! I like the ortho look, but actually I think I will go with very slight perspective; I made it tuneable, right now I'm at pi/18 radians fov which is very narrow.

But a little bit of perspective helps, in particular the terrain is smoothly rolling (and so far, want to keep it that way, though making it more angular is an option as well) and having perspective helps that. Also, it improves the impression of some of the lighting effects, e.g., fresnel looks a bit better when you have just a bit of an edge showing. Also the art will become slightly less angular as time goes on (e.g., going to have some perturbation for the buildings to make the walls a bit rough geometrically, etc.) But either way, reducing the perspective down to where it's barely noticable has been a huge improvement. I'll write a post or maybe do a dev log video on it, actually.

So other news, been working on a few things I don't wanna talk about. In general, the part of the spreadsheet now that I'm really working through are features. These are all features that will be required, and it's easier to add placeholder art where needed to support the features than it would be to add placeholder features to support the art.

In the evenings, however, I've been doing some texturing... I do the textures on periscope, which is fun and usually gets about 10 viewers. Pretty nice! I'm not sure but I have a funny feeling periscope works to feed you viewers until you reach about 10, which I am 100% ok with it. Twitch streaming is fun and in a lot of ways preferable, but I do my art (drawing) on a netbook so that won't work. I like the small screen, as it's nearly 1:1 with my small tablet, and I also can't really load a web browser or anything (too slow, which is ironic since that was the original idea behind netbooks.) Well anyhow.

There are probably fewer textures needed for PN than there were for Cellpop (my last game, here: http://therealtexasgame.com) so that is nice. But I got behind on art with Cellpop and want to avoid that here. So, I'm chipping away at the textures each evening. It's a relaxing thing to do in the evening.

Here's a fun thing, a progress pic of one of the textures, this one turned out well:



Progress 1 - using a 6px brush with pure white.

I make the brush pressure sensitive for opacity only, other than that it's a simple circular brush. I don't want too many variables because this will inevitably lead to less consistency in the art overall, which is why I don't make the pressure sensitivity change the brush size. If I were a better artist with better control, I could use brush size as well. But where I'm at I find having a system that limits my options actually helps the final result.

I am drawing on inverse, because it seems easier to start this way.



Progress 3 - using a 6px brush with 65% white

Next, I fill in the blocks by drawing a million circles, lightly.



Progress 3 - using a 4px brush with 35% white

Now, invert the image. I use a smaller brush so I'm getting into a bit more detail, and now I'm creating a bit of a chiseled edge effect, as well as drawing sort-of "grout" into the corners between the blocks.



Progress 4 - using a 2px brush with pure black

Drawing in between the bricks with a fine brush to define them more. Sort of undoes my "grout" step earlier.



Progress 5 - using a 2px brush with pure white

Now going in and basically putting hilights in. What I'm doing here is, essentially, using the interference pattern or negative space created by the circles in step 2 and using that to create a kind of natural-looking marble-ized weathered stone effect.

This texture will then be put through a gradient map and effects (bump map, but also emit, shiny, gloss) will also be extrapolated from the same image.

Doing this saves me time in drawing originally (don't care about color or even very much about contrast at this stage) and also in color harmonizing later on. I can also take one drawn-texture and produce more than one colormap texture, which is very useful. Recoloring-- use it, it's videogames!

(286/2031)

There's a new, short video on one aspect of terrain generation:

https://www.youtube.com/watch?v=bTkX9lBNv7A&feature=youtu.be

And here's a short gif:



I decided last night to go ahead and get fire working for boats, as well as figuring out those few other things, rather than putting them off.

After that, the next thing on my list was to try and address a camera issue, which is that the zoomed-in state does not feel useful because you can't see much. As a result, everyone who plays tends to just zoom all the way out at all times, which makes zooming in feel a bit useless. It feels like a comfort problem.

One idea i had was to tilt the camera down a bit, i.e., have a lower angle. I even experimented a bit with having an almost over-the-shoulder view. Unfortunately but expectedly the game looks rather bad this way, as it's been designed top-down from the very start. But I wanted to see.

After that, I realized the problem with a perspective view, and this applies even to first person games, could be summed up this way:

With a perspective view, the pixels in the middle of the screen are more important than those on the sides.

With a first person game, you are able to look around wherever you like to center what you want to see on the screen, so this naturally resolves itself. However, as soon as there is an over-the-shoulder view it becomes frustrating to the player, at least a little, because inevitably the player character is somewhere close to the center of the screen. It's worse if you can't move the view e.g., to look at the ceiling.

Anyway, what I wondered was, how would an ortho view look? Because there is no perspective divide, ortho view doesn't favour center pixels over ones at the side of the screen. It looks like this:



A large change but, you know, I sort of don't mind it.

I think going full-ortho will prove to be a bit extreme an option, but it made me realize that I will improve the things a lot by decreasing the perspective effect. This just means reducing the FOV and zooming the camera out, so I'll experiment a bit with this tomorrow.

I also added some placeholder art to the character creator. I need to make it so you can have turbans, sashes, and different decals on your shirt. Just the next thing on the list.

Other than that, I did some texture art last night and streamed it on Periscope, which was fun.

(233/1998)

[Q: Does anybody know, is imgur the way to do gifs here?]

Jay: thanks so much for the encouragement

Q: Does anybody know, is imgur the way to do gifs here?

The way I work through the spreadsheet is very methodical; I always start at the top of the list no matter what it is (there is a rudimentary priority field for it.) Right now the top of the list are missing game features, that is, more code-oriented things that have to be completed. They are at the top of the list since it creates more problems later on if they are put off-- relatively easy to use placeholder art when implementing a feature, but much harder to put final art into a feature that doesn't yet exist.

I will be at these game features for awhile; after that it's all (mostly) just content. But the order they are happening in is arbitrary, more or less alphabetical.

So today, top of my list was a bunch of items for the new damage model in for boats. The old one was too complex.

Basically, boats have two parameters that control their health:

- hit points (hp)
- flood points (fp)

Boats take damage a few ways:

- shot with a gun (usually another boat's cannon)
- rammed by another boat
- lit on fire
- splashed with a big wave (does flooding damage only)

Boat hit point damage is directional, and there are some formulas and tweakable parameters to control how much damage to take in various circumstances. There is front, back, side armour values, as well as values that control how much damage to take in collisions based on the incoming force (relating to the other boat's speed, mass, and collision vector, I mean.)

Boat flooding happens in response to hit point damage; so when a boat has less than N hit points it starts to flood; this flood rate accelerates as the boat takes more damage. As boats take on water, they lose bouyancy in the physics engine. Once a boat reaches it's flooding max, it sinks.

Objects in Paradise Never can be lit on fire. Fire itself is treated like an object that can attach to "fire anchors". So when modeling the boat, it's possible to add fire anchors to different places that can then light on fire. This works really well for buildings, and should be work fine for boats, too. Especially in the way that fire can spread automatically.

Finally, big waves can cause the boat to take on water. Boats have a "water splash" armour rating, so for instance some boats don't become waterlogged at all when they are splashed (army type ships) but others do more easily (fishing boats.) As well, boats have a maximum amount of water they can take on from splashing, this could be their maximum flooding points (so a big wave will swamp a fishing boat) but be something small, sort of analogous to how much water will flow into the hold vs airtight ballast areas or something like that.

Boats which are not flooded too badly will automatically empty of water via a special flooding pump rate. This doesn't seem to affect things very much right now, as boats flood very quickly, but I'm leaving it in. I might slow down the flooding rate overall.

What's missing in all this are a few things:

- there are no sources for water splashing; it's just a feature of the damage model right now
- to address the above, I will (in the future) modify the boat physics to create splash callbacks when the boat is submerged
- i haven't bothered testing fire, per se; however, fire works fine for buildings and other objects
- there should be some bubble effects when a boat sinks; again easy to do but I'm moving past this for now

Because I'm trying to move at some speed through the planning spreadsheet, I'm satisfied that the new damage model is in place and basically working. So I'll keep going and not worry about these other points; they have been added for future consideration.

(Note: on my progress tag below, the total number of items has gone down, this doesn't represent the items I've completed, it means I merged or removed a few items from the list without having to complete them, so there are 1995-226=1769 items left right now.)

(226/1995)

Some random musings...

When I started this project (in 2013) I wanted to keep it small.

I had the idea that I could build a small kernel of a game and then slowly grow everything around it. I would avoid what I saw was a trap, which was laying out too large of a plan. If you started with a simple almost prototype, it should be possible to grow it outwards.

At the time, and even still today, a lot of people say that you should work this way. Well, it's not going to do it for everyone

Late last year I took a short break from Paradise Never to gather feedback and finish getting The Real Texas on Steam. I wanted to release it with a new DLC. After putting together a fairly polished if short build of PN, I sat down and thought about the DLC.

Because there was very little pressure for the DLC, I decided to approach it differently than any previous project:

- I would work only with a small subset of the mechanics from TRT
- I would plan in detail absolutely everything before starting work

So I did this, and as antithetical as it might be to most advice you get (work iteratively) it actually turned out very well. In fact, I feel like Cellpop (the DLC for TRT) met a few goals:

- It was incredibly close to my original vision
- It worked out just fine; I had to adjust a few things afterwards, of course, but it wasn't too big of a deal
- It was incredibly stress-free to work on

Because I had a (massive, 2000-line) spreadsheet listing every single task, in miniscule detail, I always knew where I was at with it. Going through this entire process made me realize that this was, for whatever reason, a better way for me to work.

So that's the approach I am taking now that I'm pushing to finish Paradise Never.

Where I'm at right now (August 2, 2016) is I have broken down the game into a spreadsheet which is about 2000 lines. This spreadsheet will grow as I work, but if anything the tasks here are actually smaller than with Cellpop so I am hoping progress will be excellent from here on in.

I don't know what percentage of the game is totally finished, because I'm not sure how to measure the (extremely huge) amount of work I've done so far, but the spreadsheet is at about 10%.

So, what I'll do at the end of each post, from here on in, just for fun, is put a line, (N/M) where N is how many things are complete, and M is how many things are on the spreadsheet, just at the time of posting.

There are some other details I want to report about how the development is going to be completed, but this is what I wanted to write for now.

(201/2002)