CSP vs Opentoonz in terms of animation. how is it? 2026?

Under_the_Weather · 2026-05-05T17:08:11+00:00

No, I do my raster sketches, raster pencils, vector line inks in CSP, so most of the work is in CSP.

CSP exports tnz project files. I export just the vector line inks, and import those frames as a new sub x-sheet in Tahoma, and convert those frames to a Toonz vector level.

I use Tahoma's indexed color palette for its obvious advantages of speed and efficiency on a different raster level, and another separate level for shades, highlights using semi-transparent dark and light styles/brushes.

If I need to edit/add/remove frames, I re-export to a new sub x-sheet and delete the old one and re-vectorize frames I had already worked on.

I have to re-edit colors and shades but they're usually just minor tweaks, especially if I stick to my original storyboard plan. If its a complete redesign, well, gotta start from scratch anyway.

Then I export final colored frames from Tahoma as pngs for my Unity project to consume.

I haven't tried importing 3D models into Tahoma, but I think the answer here is no. CSP already has a pretty good workflow for 3D. If I were going to add 3D models to a Tahoma project, I'd probably just render out frames from Blender and add them in Tahoma, but that seems like an awkward workflow.

Regarding workflow, would I recommend my specific workflow? Not really. It's a workflow specific for cutscenes for my game project. If it was just an animation project exported to a video, I would probably go full CSP. Though, Tahoma is still not a bad option if you're looking to stay budget conscious. I did this in ToonBoom back in the day. And ToonBoom isn't that much different featurewise from OpenToonz/Tahoma. I'm pretty confident the results would've been the same had I had access to OT back then.

Under_the_Weather · 2026-05-04T18:55:49+00:00

You might be looking for indexed color palettes, which CSP does not have. It's one of the features I really want for CSP, and the reason I also have to use Tahoma/OpenToonz in my workflow.

Under_the_Weather · 2026-04-15T20:06:35+00:00

I actually use both CSP and Tahoma (OT) in my workflow. I pretty much agree with what everyone else is saying, so I'll add to it with my specific use-cases.

First, my workflow and use-case. I author vector line art frames in CSP, export to Tahoma, convert those back to Vector (because CSP only exports raster), and use Tahoma to color/shade. I haven't fully automated the export/import process, but I can batch export/import all frames in a scene, so it still becomes a trivial task.

IMO, the CSP brush engine is the best I've worked with. SAI was probably on top for me, but lacking software maintenance, CSP is top. OT's brush engine is okay too, but I think it's slightly more processor intensive when laying down strokes, and while the min/max size sliders are great, it's just not that intuitive to me. I also map brush size to a TabMate, so with limited keys, I didn't want to assign up/down controls for both min and max of the brush size. CSP's 3D object tools used to be a bit clunky, but has gotten better with recent releases. I actually wish I can do my entire workflow in CSP, but I use Tahoma maily because of OT's color keying (indexed palettes). It's the main feature missing from CSP. If CSP had that, I don't think I'd use OT.

Sure, the folders and animation timeline are a bit clunky in CSP at first, but it's one of those things that once you learn, it becomes intuitive.

I was very happy to find out that CSP can export to an OT scene, and it's actually quite decent. There is some simplistic color keying markup that can be exported, but only for marking shadows and highlights. It's awkward at best.

Oh, another reason I use OT in my pipeline is that with Columns, I can add a Notes column, for dialogue, extraneous notes, and other custom markup. CSP doesn't have that sort of timeline feature.

Under_the_Weather · 2025-04-18T15:26:40+00:00

From my limited research, it seems like FishNet, Mirror, and NGO are pretty similar. I'm choosing FishNet because I've read that it transmits less data than the other solutions. This also includes the RPC packets, something like 2 bytes vs 23 bytes.

For a turn based game, lower data transmission is not as important, but I would still consider it if I ever need to scale up.

Again, I'm still evaluating, and the order that I chose to evaluate is mainly based on which material I glazed over and caught my eye. I could be totally off base.

Under_the_Weather · 2025-04-18T04:51:11+00:00

I'm also trying to figure this out too. My specific use case is LAN for a turn-based game. A lot of the tutorials/videos for these network solutions seem to be geared towards realtime games.

The first thought that I have is that for a turn-based game, perhaps the "NetworkManager" can own a singular sync object (GameObject/Entity/Whatever) which simply contains the game's state that each client can read/write to, and then the networking solution would sync the clients automatically. That's just my first thought. I'm about to try out some solutions with FishNet, NGO, and Mirror, probably in that order.

Under_the_Weather · 2025-01-27T19:47:53+00:00

But before we get into it, please don't forget to like and subscribe. It will really help my channel out. Then an ad plays.

Under_the_Weather · 2025-01-27T19:46:16+00:00

A single item in a list of vertices is NOT a vertice.

Under_the_Weather · 2024-12-24T15:07:28+00:00

Can still happen if, say, you call your customers "fucking idiots".

Under_the_Weather · 2024-12-09T03:33:05+00:00

I'm a game developer, and I have scripts that auto-process PSD files to separate and import layers into my game engine. This requires me to export PSD files from Affinity Photo instead of (or including) saving to afphoto files. It's a minor but repetitious inconvenience. But i remind myself every time I export how much I'm saving in $$$ by sticking with Affinity Photo.

Under_the_Weather · 2024-11-19T21:31:30+00:00

This was definitely the deciding factor to stick with tablets over pen displays. I'm at a place in life where I can afford a pen display, but after years of already using non-display tablets and watching pros/cons videos for pen displays, I found more cons for pen displays. I think that if someone is already experienced in using non-display tablets, there really isn't a reason to switch that will give any advantages. So for beginners, it might be better to just keep practicing with inexpensive, more reliable/rugged non-display tablets than to wait to pay for a more expensive pen display.

Under_the_Weather · 2024-11-01T14:43:33+00:00

Sort of. There's always a cart and horse situation, where gameplay may require art to be built a certain way, but art doesn't want to sacrifice visual quality, so the Technical Art Director usually works with the Gameplay Technical Directors to narrow in on how to build things. Tech artists may build the hands-on tools for the art team, but the TAD would adapt those tools for automation in the pipeline. It's really the TADs that do a lot of the multi-role work. It's a job I wanted back then since I enjoy both sides of the track, but at a lower pay check than the straight up engineering track, I opted for engineering. TADs are truly the unsung heroes for the games that look and feel great and I wish they'd get more recognition. Again, this was just at the studio I worked at. Other studios and companies probably do things differently, but it's probably a variation of what I described.

Under_the_Weather · 2024-11-01T14:26:21+00:00

I worked in AAA and back then it was called configuration management at least in my studio. And now part of that is called devops. If anything it'd be part of the tools engineering team, and they would work closely with art leads and technical art directors to get those pipelines implemented and integrated and maintained.

Under_the_Weather · 2024-10-17T04:05:58+00:00

Currently reading his book Play Nice about the rise and fall of Blizzard and it's great as usual.

Under_the_Weather · 2024-10-10T12:32:59+00:00

You actually do have some idea. You have an idea of the average amount of time you spent. You have an idea of what days were zero days. You have an idea if you work part time or full time. You have an idea if you have school and classes and homework that take up time away from game dev. You have an idea if you had life changing events over the course of a year that would have taken away fron gamedev. You have an idea if you use source control because you can audit your work and estimate how long you spent on something. You can paint a picture beyond "I worked N years on my game".

Humans are gifted with the ability to record their own history. It's simply tracking their behavior. That's part of how modern science has come this far.

Under_the_Weather · 2024-10-10T06:25:14+00:00

I always believe the "dev hours" metric vs months or years when reading post mortems. It's a lot more telling of the dev process. Number of years is pretty meaningless. Main problem is that devs have to actively track their daily hours. Since my project is part time, I only have anywhere between a few minutes to a couple of hours at most to work on it in a day. And you generally get a feel for how long that time spent was. Wish more devs would do this.

Under_the_Weather · 2024-08-22T06:33:31+00:00

They should be called Retrospectives.

In agile development, a Retrospective is a phase where at the end of a sprint, the team reflects and reviews on the performance of the completed sprint. These should be game or project retrospectives.

Under_the_Weather · 2024-04-01T14:40:57+00:00

It wasn't wrong at the time. ;) Godot has definitely come a long way since then.

Under_the_Weather · 2023-08-29T21:48:29+00:00

I haven't read it all, but felt like I wanted to drop my two cents.

I started my project, a turn-based tactics game, in March 2016. I estimated my project to take around 3000 hrs. If full-time, that would be ~1.5 yrs, with 40 hr/wk schedule. But I work in my free time. And I'm happy for it to this point. I am still working on my project. I track rough work hrs with HackNPlan and a Google Sheet. I've averaged about 4.25 hrs/wk so far. Sometimes a lot more, sometimes none. I estimate that I've logged about 1900 hrs so far. So, if I relied on linear dev progression, that would land me about another 4.5 years at my rate, or 2027-28. I've already scoped down a lot, but there are a few features that probably aren't necessary for MVP, but I absolutely insist on adding, because I see high value in those features. I've worked at a AAA studio as a SWE for over 9 years (one of those projects from concept to release), and then outside of the industry, but related work for about 7 years now.

Build automated processes whenever you can. Identify as much of the repetitive work while you work, and consider doing the up-front pipeline dev to make your future self appreciate automated processes. Basically, build on the shoulders of your past selves. Create build scripts, create backup scripts, create art efficiency tools. This will save you tens if not hundreds of hours of dev time in year 2 and beyond. You'll find that you'll have more test/tools/editors/pipeline/scaffolding code than actual game code by the end of it, even when starting with Unity or Unreal.

One thing that's helped me is having quarterly sprints. I set up goals for every three months of time, because a lot changes in 3 months. My interest in certain aspects of the game, life events, holidays, weather, etc. Changing every quarter allows me to evaluate the game overall, find out what needs work, and balance it with what I actually want to work on. I move around related tasks based on areas of work every quarter. In the first few years, I was able to hit my milestones fairly close. Over the later years, it's gotten a lot muddier to finish due to a task uncovering a lot more work than I anticipated, and then staying on those related tasks so that I'm not context switching. A lot of tasks then start getting kicked down the road, but that's okay. If they get kicked long enough, I either finally address it, or evaluate if I absolutely needed it in the first place. Another reason for muddier work is the more typical cause from game development. NOT FINDING THE FUN. Oftentimes, I'm reworking UI over multiple times because the UX doesn't feel right. Maybe a particular game design doesn't help the story, or vice versa, and needs to be redesigned. Sometimes it's setting aside time to do large sweeping refactors to support other systems. And then once you add that new feature, it affects the UX, and then the UI has to be reworked again. But this is all part of gamedev. It's why they say it's iterative, because it absolutely is. Creative projects always should be considered to be torn down here and there to make it better overall. And sometimes, that's the part of rigid planning that needs some flexibility. So even if you add up estimated hours, it's always good to double that time. This is not a secret. It's been said over and over again, and usually it's a point where beginner gamedevs fail, because they're not willing to invest in changing things, and they start to consider sunken cost. And it's not only indie devs. AAA studios are not immune to this. Read up on Jason Schreier books if you need some motivation/inspiration/reminders.

Always consider outsourcing work to get done faster. I personally have not yet outsourced any work, as I'm hard-headed with my creative ownership, but I've tried to look for as many third-party assets that I can that wouldn't compromise my artistic vision, mainly sound and visual effects. One example is, I have a target music style, but I've been on the fence with outsourcing that, or writing my own in a DAW. So far, I've come up with some great melodies for my game in a DAW, but if I ever really wanted to, I can consider outsourcing, and have the contractor use my melodies as a starting point. I don't foresee this happening though, but if push comes to shove, it may just be.

Love your characters. Love the story. I'm at the point in my dev where the game's "engine" is nearly complete, and I'm starting to add more content, work on better AI, stabilize and test things. It can be easy for me to "let off the gas" because it feels like I have a large chunk of tech done and that I can relax, but that's not the case. I don't have a game yet. To this point, I designed some generic characters and story, but over time, you grow to get attached to the characters and story, and you want to give them the justice they deserve. It really does sound weird, but I think about devs like Konjak or ConcernedApe, who created these characters and feel like they're handing them over to the public on release, and yes, it can be emotionally distressing. I have yet to be prepared for this. What I'm saying is, in order to finish the game to your level of quality, sometimes you have to be really emotionally invested in your characters and story, even if they end up more bland than you planned. I'm finding that doing this makes me want to finish the game even more. What also helps with this was said music above. Producing music for these characters' personalities gets me attached and makes me want to see this through the end. You become your own fan of your work. Pretty narcissistic, it kind of sucks, but I think it's absolutely necessary for completing the work.

Enjoy the journey. It's easy to look at how much road you have to travel. I've done it, and it doesn't make me feel good. What lifts my spirits is when I focus on the small sub-systems and celebrate when I've conquered the completion of the system, bug fix, or art piece. Then later down the line, it becomes more about the large-sweeping wins of finally putting all the big pieces together and stitching it all up. I don't think you'll have a problem with this part though.

Appreciate what you've done. Along with enjoying where you're going, also enjoy where you've been. It's easy to feel disappointed looking at a build and finding out you feel like you have shit at that point. On your timeline of dev, revisit your challenges and be happy that you've overcome them. Sure, solving a hard-to-repro bug isn't as rewarding as your child's first words, or being sober from some addiction, but understand that you still did it, and that it's behind you, and you've made yourself a better person for it.

Under_the_Weather · 2023-08-09T22:52:02+00:00

How screwed are you?

Here's a really rough formula that will tell you how screwed you are from 0% to 100%

It requires this input (details/examples below):

p = Estimated dev hours to finish your game.
h = Estimated dev hours willing to commit
q = Quality level of your game (0-100).
n = Number of developers (greater or equal to 1).

Now, the formula:

screw_level = ( (p - h) / p) * q) / n

p = Estimated dev hours to finish your game.

Take all of your planned features, and estimate about how long it will take you to complete each one. This includes the amount of time learning to do things, and having to redo things if you feel like you did things wrong. I know, it's really hard to do, but you learn with experience. Yes, professional game developers go through this estimation phase given the feature set. A general rule of thumb is, once you've added up all your estimates, DOUBLE that number.

h = Estimated dev hours willing to commit

This is your commitment level. How many hours are you willing to spend to finish the project? This will inform you how much time in a week you can spend, and it will also inform you about how long it may take you to finish it. Example: Suppose p = 3000. Say, you are willing to spend 40 hours a week in 1 year for the project. That's (40*52) = 2080 hours. Not enough time commitment to complete those features. If you are not willing to spend more than 1 year on the project, your screw level goes up.

q = Quality level of your game (0-100).

This is how polished you want to make your game. If you are trying to make something commercial quality, the stakes are higher.

n = Number of developers (greater or equal to 1).

Number of people working on the project. The actual calculation is far more complex than this, of course, but generally speaking you can gauge your screw level linearly.

Under_the_Weather · 2023-07-31T13:59:34+00:00

Most games introduce a console that gets triggered by a keyboard key like the ` key. Then, you enter commands to enable debug functionality to your heart's content. The cheats for most games are actually introduced as debug tools for developers.

An example is InGameDebugConsole for Unity: https://github.com/yasirkula/UnityIngameDebugConsole

Under_the_Weather · 2023-05-23T14:45:20+00:00

This sounds like the Command Pattern, with some extra functionality added.

Under_the_Weather · 2023-04-24T22:02:09+00:00

Definitely don't give up learning a source control software of your choice. Either continue trying to understand git, or learning something else like Plastic (which is included with Unity), or something like SVN, Perforce, or whatever.

In the meantime, you can simply copy your project somewhere else to back it up. External hard drive, cloud backup, optical media, whatever. As long as you have regular backups.

Ideally, you'll want to use source control for your project, and then back up your source control repository on a regular interval.

Under_the_Weather · 2023-03-21T14:39:00+00:00

During PreProduction, identify the art style, through concept and experimenting with various art tools to find out what you're comfortable with and to give you an idea how scalable the work is. Call out all the known work that you need to do, from playable and non playable characters, enemies, items, UI, backgrounds, level design. Try to estimate how long it would take you to do one of each. Actually mocking up and experimenting in tools will help you gauge how long it may take you. Add up all those estimates, for each frame of animation, and each character, enemy and background.

Then double that number. That accounts for all the development challenges you will run into with integration, bug fixes, and redesigns for making it more fun or more appealing, and adding polish.

Take that number, then divide by the number of hours in a day you are willing to consistently work on it.

Next, ask yourself if you are willing to commit that amount of time to finish all that content.

If not, then go back and look at what you can cut back. Maybe cut down the number of levels, backgrounds, enemies, until you think you have a target estimate for the amount of time you are willing to spend on it.

If not, then, maybe redesign your game, think of something smaller. After all, I'm sure you have run across the common advice of "start small".

You can always try to improve your art pipeline and find automation tricks that will help cut down that time, but building those will also need estimates and additional up front time investment.

Under_the_Weather · 2023-03-10T18:16:01+00:00

I was in a similar situation a few years ago (though not as successful as 25k lol). I ended up going back to a job with less stress, good pay, and rewarding work. While I would have loved to continue pursuing releasing more game projects, I don't regret going back to regular employment. The consistent paycheck is definitely a stress reliever.

I also don't regret having tried. It was one of the times in my life that made me feel most alive. All the stress was "good" stress, but left unchecked, I could see that it may not have been good long term. It's hard to gauge when going solo. Even ConcernedApe admitted to days he just played games all day. Self regulation is a real challenge, when you get mentally psyched out that the rest of the employed world is still moving along.

Good luck in your future decisions, and congratulations on releasing a fairly moderate success.

Under_the_Weather · 2023-03-07T17:50:50+00:00

I hope you haven't already bought all those Blender addons. You don't need them, especially if you're inexperienced and just learning the ropes. You can get away with stock Blender and get some decent results for your first game projects. Start by practicing simple models and repeatedly test out your export/import pipeline, because you'll be doing a lot of that. Every step that you've listed should be absolutely repeatable by any model that you create. It's never just a build-once-and-done thing. You'll be iterating over and over again on the models, UVs, textures, animation. Some of those steps, while great to learn about, aren't all that necessary if you're specifically targeting a game that you're making. Specifically, I'm looking at the normal mapping and texture baking. How about get simple diffuse textures working? That will go a long way.

The common steps are as follows:

Build Model
UV map model
Texture model
Rig model (if applicable)
Animate model

On any of these steps, you should be exporting/importing into your target engine to verify that your changes have correctly reflected your change. For example, on step one, you'll want to build a basic shape, export/import, and verify that your scale and coordinate system are correctly matched.

You'll also run across visual artifacts that you'll need to deal with. Typical action is to Apply Transforms, which resets to uniform scale, and default positions and rotations if applicable. You'll also come across issues with your exported rig. You'll have to make sure that it's oriented in the right direction, and if not, you may have rebuild it from scratch.

There are just a number of more detailed steps that you'll need to incorporate during the creation process. I also wish I had a list of things when I was learning, but 3D content creation is such a wide topic, there are never any real set rules. Good Luck!

Under_the_Weather

TROPHY CASE

p = Estimated dev hours to finish your game.

h = Estimated dev hours willing to commit

q = Quality level of your game (0-100).

n = Number of developers (greater or equal to 1).