"Gamedev-design" - making game-making more fun

In another thread I asked:

...and was encouraged to make a thread about it:

What do you think makes making games a more fun and rewarding experience and how do you think this would help or hinder progress on your projects?


Personally I think that there is a huge general issue with "the act of creation": You create something, it becomes a novel stimulus for your brain, you keep working on it with the intention to improve it, because it is no longer novel to you you get bored, you start changing it, rinse and repeat till you're absolutely sick of it and can't think of more ways to make it novel again.

I once heard a professional music composer say "It has come close to the point where I'm bored by anything that has notes in it". And another professional film music composer once told me "I don't listen to music privately anymore. I only ever do it out of professional interest, and then I quite often listen to super polished mainstream pop because there's so much to learn from their production techniques."

I've studied design and I've seen how it is a very typical trend for graphics designers to gravitate towards weirder and weirder things that start to fail at even their most basical intended purposes, like readability. Kurt Weidemann - a German typographer - once said something along the lines of "There is nothing new to discover in typography, just like in the kitchen or in the bedroom". And I think he has a point, at least to a degree. Though I'm not sure what exact lessons to draw from it and what strategies to apply to making games.

Ultimately I think good things take time and you can't really change that fact, and you'll never get entirely over the problem of getting bored by whatever you put hundreds or thousands of hours into. But maybe we can find strategies to mitigate the downsides, identify pitfalls more clearly and learn to avoid bad gamedev habits.

One thing I'm doing with my main project is: no audio till the game is basically finished. I know if I add audio now it would cost me hundreds of hours, and at the end of the whole dev cylce I'll absolutely hate the audio and will want to redo it all. If I keep audio for last, there's one cool novel thing I can still add as a final touch and then release it, hopefully at least not being totally sick of the audio yet, albeit everything else probably. As a bonus, if I never get the game part finished, I've saved a lot of time working on audio at all.

I'm currently thinking seriously over starting a side project. I've set a deadline of the end of the year where I want to decide whether I bury the side project idea or start executing it with the goal to finish that over the course of 2018. If I work on it, that would be my test-case for whatever conclusions we can reach in this discussion, and I'll be able to - at least to a degree - compare how development feels compared to what I've done so far on my main project.

 

Glad you made this.

It's an interesting topic. One wants to creative process to be as enjoyable as possible, which will sustain progress. But that's dependent on what you're building.

One thing to keep in mind is that it is of course a little different for everyone. However...

I imagine if one were to try to nail down the aspects which give positive feedback to a developer, the most effectual would be gameplay. Having something you can actually engage with yourself as you're building it is huge. This might include player actions or AI, and to lesser effect smaller changes like an inventory or something.

Then you probably have other elements like audio, or quality graphics, or story, or things like level design. Elements which can enhance a user experience in a directly observable way, but require skill to implement. This is one area where a lot of indies seem to stumble, likely because of the skill required.

Then there are the back-ends, the things that actually run your game. Be it multiplayer networking code, or the logic behind the scenes in a single-player game (in my case it's coming up with meaningful stat interactions between AI characters for my most recent project)

So I think there are two main factors: how observable the change is, and how much work it takes. In my case the second is probably a bit more daunting that the first, given my inexperience and lack of time to really focus on development.

I'm not sure what the solution is. One option, and one I've attempted to some extent, is to focus on adding an element completely to the place where it has an observable impact on the game. Because ultimately the majority of the work does, even if in and of itself it doesn't--it's building up to something greater.

As an example, I'm intending to implement competitive events in a project I'm working on. Things like races between AI creatures. So in my case I would want to do all of the work to get that working fully before moving on to anything else.

Another option might be to simply be aware (perhaps make note of it in your "to do" list for the game) of how observable the change will be after you've made it, and then bounce back and forth between the "observable" and "non-observable" elements to sustain the "positive feedback" loop before it does out.

I feel like the former option is the better one, but I struggle with it a bit. I have a tendency to always have two or three different things I want to be working on, and when I hit a wall in one area I just jump to another. This has an obvious problem: when I hit walls in multiple places, I feel even more stuck than I would if it were just one area. I have nowhere to turn but to these issues, and because I still have multiple of them I can jump back and forth without getting much done in one place.

I think if one can focus on one area (please note, with all of this talk I'm referring to larger overarching areas to work on - the straightforward list of tasks which can be completed in a day is definitely still needed), one can complete a section of work which one can look to in the future when feeling burnt out.

This reminds me a little of the proposed method for Star Citizen's development. I say "proposed" because we know they didn't really do this--they've been working on pretty much everything in tandem for years. This means that observable (to the end user at least) progress slows to a crawl as development progresses slowly in multiple areas, rather than moving quickly (like the Hanger Module initially, as well as Arena Commander) in a single specific area.

 

I'm way too tired to write a lot, so here are just some quick thoughts.

I like that, kind of like going on a mission that serves a higher purpose.

In an old project that I abandoned I had an autoplay mode where the game would just play itself and auto-click all buttons between missions. I found it weirdly fascinating to see that kind of self-test for the AI.

Most of the time I think I feel either stuck or too bored already to even start on a task. The channel of tasks that can still get me into a flow state seems to shrink over time.

What did they propose?



And some random thoughts I had today:

- Arbitrary limitations help feed creativity (that's why gamejams and contests usually have themes).

- If you don't have a strong vision and don't own strong IP to guide you, just pick a classic (ideally not a game) and see what you can transfer from it into your medium. E.g. 80's action film tropes inspired BroForce, and the Mad Max game had the movies to look at for guidance. Fallout 1 also had strong movie influences as far as I know.

- Consider ways to preserve some of the fleeting "novelty" of your game for yourself. E.g. when testing stuff like path-finding you might as well have some ugly-retro-post-fx on your cam to shave a couple dozen or hundreds of hours of the time you look at your intended final game graphics and aesthetics. I'm still looking for a kind of post fx stack that makes it more bearable for me to use untextured lowpoly placeholders because I really struggle with using placeholders, but I also procrastinate more on making 3D art assets than on almost all else.

- Prioritize chosing features and tasks that have easily quantifiable progress metrics over vague goals like "make the game more fun".

- Keep 80-20 rule in mind.

- Set only goals that you have control over yourself (bad goal: "make successful multiplayer game", good goal: "finish featurecomplete pong clone")

- Don't put off all "chore" tasks for last or you are likely to give up when no more fun stuff is left on the horizon.

 

Good stuff. Sorry, forgot to mention the Star Citizen thing in detail. But they intended to develop these small little independent modules which users could play, and then eventually stick them all together. They did at first with the Hanger module (you can look at your ship model in a modelled hanger), and the Arena Commander module (dogfighting gameplay), and kind of with the social module (where you could go to a game location with other players, though this never developed fully into it's own thing), but lately they've focused on sticking everything together into one experience and they keep slipping, slipping, slipping from their estimated release dates. For example, the "Alpha 3.0" was originally supposed to come out in December of last year...but it only recently got into the hands of the most "private" group of public testers (which means it will probably be released in December of this year, 1 year late).

 

I've struggled with this a lot lately. For me the fun in game design and development is seeing my creations in the wild, seeing real people's real reactions to my games. I haven't released anything in a long time, and that is the problem for me. So in future I'm adopting the release release fast, release often mantra.

 

Interesting. I don't seem to get much out of seeing people play something I made. I remember letting a friend play the mobile game I was working on and all she said was "can't they go faster?", and her boyfriend who is a programmer looked at me with an expression of "I feel your pain right now".
The only playtest I made with my current project was letting another programmer friend of mine play it. He asked what of the stuff that's happening on screen is stuff that I made and what Unity does for me, which is a smarter question to ask (he didn't mean it in the assetflipping sense, he just doesn't know Unity at all). I find the only metric worth tracking is how long people play till they stop on their own. In that regard it went better than I expected.

(As an aside I think it might be worth tracking the time between you showing someone you know something from your game the first time, and the next time when they are asking you if the game is playable yet. For me it won't work because I don't want that kind of questions and always tell everyone it's years away - if I even ever finish it. But it could be an interesting indicator of market interest. If no one ever gets back to you about it, it's probably not something the market wants. Oh, and fellow devs don't count because they might ask for other reasons.)

I think that's one of those things that look good on paper but might not work as expected in the real world. At least I know no example where that was really well handled and it actually helped.



In gamedesign I like clear goals with a very broad possibilityspace to get there and nuanced degrees of success for achieving that goal. Infiniminer is a great example. Or liberating outposts in any open world game with stealth elements. I like that kind of freedom with a clear objective.

In gamedev I more often than not find the possibilityspace too wide and daunting, and the ways by which to measure "degrees of success" too vague. That's one of the advantages that I see in taking something that exists already in popular culture and measure your game against achieving qualities of that thing. E.g. if you make a 2D plattformer you could pick Quake 1 as a reference and even though the genres are completely different you'll suddenly have a much better idea whether a certain element or change gets you closer to or further away from the essence of Quake 1. You could pick a movie or a book or a piece of music instead. I think any clear point of reference could be helpful.

 

At the same time however it's possible to have lesser interest or motivation there because it already exists.

Like, a month or two back I was really getting a hankering for a railroad sim like the Railroad Tycoon games from years ago. I was starting to get a look at how to build a train. However, a couple of weeks into it (I hadn't done much at all yet) I discovered this. And since something exists already, I don't really have any further motivation to work on that kind of thing.

Part of the problem might be that I'm simply a gamer before I'm a developer . That can be extended in other directions--broadly, I'm a consumer before I'm a creator. I'd rather experience something than create that experience.

I'm probably thinking of it wrongly. In reality the reason one consumes some product and the reason one creates the product are completely different, or should be. This might be a problem with these kinds of "games you want to play" projects like you mentioned in that other thread.


I suppose, to tie this rambling back into the thread topic, for a project where one is building something they want to play themselves, a very key part of keeping motivation would be to get something you can play and experience yourself, and focus on that aspect of the work. Have fun playtesting your own work, which would help you identify the changes you want to make to make the product more fun for yourself.

And for a project where you're making a game for others to experience, focus on getting it in the hands of players, to see what they think, to see if you're conveying Jesse Schell's "essential experience" like you want to.

 

Something very similar happened to me with Brigador. Had to make huge changes to my design to be able to continue working on it (that mech game is what I call my main project). It was even worse seeing that at release they were commercially really unsuccessful.
But there is nothing that can protect you from something like that happening. It happens all the time for youtube content creators too. CGP Grey once said he just stopped looking at what others in similar fields release because you're never gonna be the first nor the last one to make a certain thing.

Much of that is true for me too, but I can't go on forever without working on anything myself or I feel like I'm going crazy.


I wonder if on reasonably small and technically simple games any additional motivation can be derived from withholding extensive playtesting from yourself till you've reached a featurecomplete alpha state. At least to whatever extend is possible realistically without slowing down development too much.

It is for sure! Though the things I really wanna play are all hyper immersive AAA games that I can't make myself. All that I can make myself by its nature has only a small subset of overlap to what I like to play myself.

The two problems I see with that is that invariably the fun you have with a game diminishes over time, as does the reward value of positive feedback. Just like you'll get bored by your game you'll get jaded by getting praise for that game and will start to want praise for your other game.

Seemingly the answer to both would be: pick smaller scoped projects to finish quicker. But I haven't figured out how to do that yet. Lack of patience was what originally in my teen years made me think "It's unlikely I'll be happy as a programmer, I'll better train to become an artist where I get more direct feedback from what I work on". Little did I know that I would never really come to grips with the fact that "art" never feels "finished", and that I'll miss out on that sweet numerically quantifiable measurement of progress that some programming tasks have. Performance optimization probably is one of my favorite tasks in game dev, because at the end its faster by a clear percentage and there's no arguing about that. I can put 10 more hours into a painting or a piece of music, and someone I show both versions to might say "I liked it better before". Games are like art in that regard.

 

I find this interesting. If you're not interested in what others think of your game, why are you making it? Are you making it for yourself? That's cool if you are, but if you are making it for yourself then why are you making it if it's no fun to make?

 

When I was working on my first game (screenshot below) that was the first time in years that I felt my life has purpose and I was passionate again about something I make. I burned out on the project and ended up abandoning it for a number of reasons, and never wanted to touch mobile games again.
I'm still trying to find something that I can replicate that original passion with again. It's not so much that I enjoy all of the process of making games, I really don't sometimes, hence me making this thread. I feel like my life is pointless and wasted if I don't at least try to make games on my own. Even if I try to stop, I can't stop thinking about what could be my next project. I've invested obscene amounts of time into becoming a "jack of all trades" so that I can do art, coding, music, and sound, myself on a game project - if I don't at least try to make games now, that was a huge waste of time because it's time not spent specializing to get really good at one thing.
And it's not like I don't care one bit what anyone thinks of the end result, I still care about what some individuals would think of it when it's finished. Those that have my respect and where I know "if they like it, it means something".
I consider solo-gamedev the ultimate interdisciplinary challenge. If I ever manage to actually finish a game I hope that's something I could manage to be proud of, because I know how hard it is to do that on your own, and that the quota of people who give up along the way is enormous.

 

If making games is a career then the perspective is just completely different then a hobby. While I enjoy making games, it's not anything game related per say that motivates me. What motivates me the most is the quest to be the best in my area of expertise, and to stay ahead of the competition. Making games is just a very fun context to do that in.

When I was making games for a studio, a lot of them were not even games I would personally play. It was never really the games themselves, it was applying my art to the games and doing it well, and seeing it all work smoothly once released.

As an indie it's not much different. I get to choose the type of game I want to make, but it's still largely driven by strategic decisions more then this is a game I would want to play. And that's fine because as long as it's in an area where I can leverage my skillset well, then I'm in my happy zone.

Making games is hard enough that you just absolutely need motivation that is bigger then the game itself. When you ask yourself why am I doing this, you have to answer that in a way that drives you back to work. And I don't care how cool the game is, the game itself will never provide that.

 

That reminds me a lot of something that I remember Ian Bogost say in a talk: play or fun (can't remember which one) being essentially "doing something with a lot of attention and care". You've turned making games into a game it seems.

I think you're probably right on that one.


I'm glad you joined the discussion because I wanted to invite you to talk about something that you said in another thread:

This is something I would like to hear more about, because so far I not only always start with artwork very soon, the idea of a certain aesthetic or feeling is often what drives me to think about or work on a project in the first place. This is just how my brain is wired, probably comes from my primary work all being painting-related and that being what I spent the most time learning in my life. I would be very interested to hear your (and other's of course) thoughts on that "mathematical proof" you mention, and speculations about how to best implement such a workflow in general.

 

The math on that is really just the practice of just in time. Another way to look at it is decide as late as possible. This is especially true on complex projects. It's extremely difficult to predict how a change in A will effect B. And the more distance between them the more difficult it gets.

Now at the same time I always solve for the big challenges up front. But solve for here just means I run things forward in my head or on a whiteboard, the goal being to eliminate any surprises. I just want to know ok I can see how I would do that, so I can budget for it, or change my design if it's going to be a major issue.

In most games general art direction and style usually don't change much. And I do think you should have a fairly clear idea of what that looks like up front. But most of the technical art stuff is driven by design and mechanics, not the other way around. And given that the technical side of art can be very time consuming, it just pays to put that off as long as possible.

What makes this hard to do in a team is that the game itself is the point of reference everyone is using. I might have a detailed picture in my head of what the end result should be. But how can I express that to someone else without actually putting it all in the game?

I think this can actually be solved in a systematic way. And I hate to leave this hanging but it's late, I'll pick this up later

 

@Martin_H - Since @snacktime mentioned teams, have you considered joining a team? The challenge is to find the right team. Jacks-of-all-trades are usually highly appreciated, especially in small teams where everyone wears many hats. You can complete larger, more interesting projects in the same time that it would take a lone developer to make a smaller project. A good team carries its members over motivation humps, and members' different perspectives will challenge your assumptions in ways that you get can't on your own. And this happens continuously during the life of the project, in contrast to the echo chamber that occurs in solo dev.

I'm writing this from experience. I've been on after-hours teams where I get home from a long workday and don't even feel like booting up the computer. But I know the whole team's waiting for a script change, so I get cracking, and in a few minutes I'm back in the zone. Plus, the next morning I can wake up to see what cool things they've done with the new functionality that I wouldn't have come up with myself.

Autumn is game jam season. It's a good opportunity to try out some teams for very short time commitments.

 

All very good points, but I really want to stay entirely independant. Being tied to other people for hobby projects is a source of stress and anxiety that I don't want in my life. I know good things can come from it but I also know that if bad things come from it, they can get really bad really quick. I'm all but certain that there are more team projects that fail, than those that succeed. GameJams likely are different (who can't get their S*** together for 2 days?), but I'm not interested in those kinds of sprints at the moment.
And personally I have trouble feeling like something is "mine" if I didn't make as much of it as I possibly can. I've worked on dozens of team projects in my professional life. I've worked much more in teams than I have worked solo on things.

I'm looking forward to it! In case an example helps, let's pretend this was concept art for a game, how would you go from there?

 

Nothing is a waste of time, if you're learning things it's all good.

I'd say that having the courage to start a project and give it a real shot is something to be proud of in of itself. I know when I first gave it a shot, that's all I wanted to do. Give it a shot and see what happened. If it didn't work out then at least I wasn't left wondering what could have been.

Learning the skills to do everything yourself is a hard thing to do. I'd say it's the hardest part of the process and the most nebulous as you're never finished learning, you're never going to be perfect at any skill no matter how good you get because there is no such thing. So again, becoming a specialist isn't actually any better than being a jack of all trades in that regard. If anything being a specialist can limit your options and opportunities in the future. So I wouldn't say you've wasted time in learning a breadth of skills. Especially if those skills are at a level that can be applied to a commercial project in some capacity or used to help others learn and surpass your ability. Even if you're not directly applying those skills it's useful to know what others on a team do/need/want, it helps communication and makes everyone around you perform better.

As for finishing a game. It's not as hard as it feels. The hardest part is reigning in your own expectations of yourself. A game is really finished whenever you decide it is. You could release whatever it is you have in front of you right now and it would be "finished". So why not?

But then, what is "Finished"? I think game developers should through away that word. Nothing is finished it's only not currently being worked on. To classify something as "Finished" makes things a lot harder for yourself. Suddenly everything in the design needs to have a purpose and fit into the whole, it has to be perfect and you can't have any mistake anywhere or the whole things falls apart, your game balance has to be spot on because there's no way to fix it after it's "Finished"!

 

Thank you for your kind words, I think you have a very healthy attitude towards these things. I'll try to start seeing it this way too. You know the studies that say learing new languages or doing Sudokus helps protect against things like Alzheimer's disease? I yesterday heard in a podcast that any kind of learning has that effect and that there's just strong correlation between people that learn these kinds of things at an old age and people who keep learning new things in general. You're also right in so far that as a specialist I'd likely feel there are still just as many people who are better than me.

I very much like the idea of starting to think of games as not-finishable. The decision "what project do I want to work on right now?" seems a lot easier than "how do I get this game finished?". I just need to find a way to actually release something before I stop working on it for an indefinite amount of time. My own expectations are definitely the biggest thing that stands between me and "finished" games.

Yesterday I did a tiny bit of work on my main game again, after I came to the conclusion that in terms of gamedesign it just has more to offer, than what I could come up with for my side-project idea so far. Also it has orders of magnitude more room for explosions.

 

Even if you are the type of person who "works best alone", being part of a team, even a mediocre team, will still amplify your effectiveness more than going solo. Doing anything alone is really hard. It's easy to get caught up in your own head and lose perspective.

Although I am not working on a specific game project right now, just learning in general, I regularly explain what I am doing to my wife even though she doesn't care and gets annoyed. Why? Because talking to somebody else kind of changes the way I see my own work, and every once in awhile my wife will make a suggestion/comment that helps me immensely even though she doesn't know anything about the subject.

 

Oh, for sure! There are pros and cons to both approaches. I've done multi-month freelance art jobs alone and I've done contracts of the same size as part of a team. I couldn't even tell you which one I really "like" more. But I'm absolutely 100% certain that I don't want to team up on my hobby gamedev projects, for the same reasons that I wouldn't want to do a kickstarter without a finished game, or accept venture-capitalist investments. I want to stay free of obligations towards other people with this, for as long as I can.

I like that idea. Just make sure to never accidentally call her your rubber duck . ( https://en.wikipedia.org/wiki/Rubber_duck_debugging )
When I try to tell my girlfriend what I'm working on I have to keep it very brief, or else she will just fall asleep. But I have an artist friend who worked in gamedev to whom I can show what I'm working on and get good feedback in return.



I've listened to an episode of hello internet today and they touched on a concept that I had never heard of and seems quite relevant to gamedev: "brain crack"

(sorry can't find the exact timecode, should start around 30 - 35 minutes in or so.)

What they mean with brain crack is when you have an idea, and you spend too long thinking about how amazing it's gonna be, you are in danger of moving into a cycle where a) thinking about how amazing it's gonna be is more fun than actually working on it, and b) if you've dreamed about it for long enough it's actually impossible to get it into a shape where you feel like you've reached your goal because your dreaming always outpaces your making.

I feel like this is immensely relevant to me, but I don't know what to do with that information. On one hand I definitely struggle with the last part. I abandoned my first game in a state that far far exceeded my expectations at the end of the concept phase, while falling far far behind the expectations I had at the time I lost the will to continue working on it.

But I also need a feeling of "this is a worthwhile idea and it's going somewhere" for me to want to work on a thing at all. I don't have "faith" that things are gonna work out, if I don't have a relatively clear vision of how they're gonna work out exactly.

I wonder how one finds a balance between these things? How does one keep their own expectations in check?

 

Write down the idea immediately. From there, make sure to write down every planned change or addition.

That doesn't keep you from dreaming, but having it down on paper both allows you to go over it another time as you write it, and allows you to look at it later on when you're not in your "dreaming mode" and just making up stuff to make it seem awesome. From that point you're analyzing as much as dreaming.

Not saying that's a surefire way to do anything, but it's worth a shot. Plus it keeps you from forgetting things. So many ideas I've just straight up forgotten...and quite a few ideas I wrote down, forgot about, then came back to months later and continued (not talking about games, but music or writing).

 

That's definitely very important. I have a bunch of notebooks that I write into, one big document for general thoughts and ideas on gamedev and my various projects, and one todo list in my game's project folder that I only put very specific tasks into.

When going over stuff I've written down, sometimes I can't remember having had that idea. I've found a script for a short movie once and really wasn't entirely sure if I even had written it myself, but I must have, because I don't save other people's ideas as .txt files. So that really proves your point about forgetting things if you don't write them down.

What I really couldn't get behind yet is the thought of writing one big GDD at the beginning, and then treating it as law for the rest of the project. I feel like I'm way too inexperienced and my game concept way too experimental to not allow myself the freedom to make big changes as I keep working on it.

 

Yeah, treating it as law would be too far. But by limiting yourself somewhat you can make sure that you're focusing on the essentials, and not branching off into totally different directions.

That's another thing I didn't really address before. I'll sometimes be reading what I have and then think about some awesome idea. So I go to write it down, and look at what I have. And I discover it doesn't fit with what I currently have.

That doesn't mean I can't change things to make it fit. But it makes me aware that hey, I can't incorporate this "no combat" feature and this "end the game with the player being forced to kill everyone in combat" idea.

At the very least, it can keep a flow to your work.

 

@TonyLi: you've written this in another thread and I didn't want to derail it. Would you say it is worth it to go back to cubes-only on a project that is graphically way past the cubes stage, but isn't well thought out on the gamedesign end? I've never really managed to do anything entirely cubes-only, because I always get sidetracked into tweaking some art stuff. I wonder whether it's worth a try to downgrade all models I've made so far back to cubes, and remove all textures (except particles), and see if that helps me focus more on the gamedesign aspect.

 

I find you can't easily assess the feeling of a game until there are graphics. Maybe some people can, but I can't. Everyone has a different process. What I can say though is the more graphics you add and the more effects and things you add to each element in your game, the harder it becomes to change those things if a change is needed.

 

I agree. The thing is, I'm much more confident about my choices for what the feeling should be and how to achieve it, than I am with my choices about how the decisionmaking in the core gameplay loop should look like.

 

So I guess the answer is that it depends on a lot of things -- the designer, how important mechanics are to the game, etc. It probably wouldn't hurt to try going back to cubes. If it doesn't work out, put the art back in. If you dig around on gamasutra, you can find videos and stills of big, art-heavy AAA games like Mass Effect where the player's going through dialogue with an NPC that's still just a gray capsule even at that late stage in development. So it clearly works for some designers.

 

I bet those designers had really nice concept images and previs videos to help them imagine the final results though.

 

I think this is an important one to consider. I'm not sure I would have been able to go back to cubes without having had explored some of the visual aspects more in-depth. I did "decide" to go for cubes several times in the past, but I could never pull it off because I got sidetracked into adding better art assets anyway. I think there were just too many too interesting unknowns that I had to figure out to calm my mind on the questions whether and how those things even are possible.

I've made the downgrade and so far I think the benefits are numerous and partly unexpected. I feel like I can focus better on gamedesign, controls and other code-centric aspects now, and prototyping stuff will feel more like "trying something" and less like "making something that looks broken and terribly out of place". Also very interesting and un-expected was that going back to colored cubes gives a unique view on visual communication problems. It is much easier to tweak how the colors in a scene read if all you gotta do is tweak the albedo colors of a few different materials and all updates in realtime, compared to switching back and forth between substance painter and unity, always re-exporting and re-importing textures for every new attempt to get a proper color read. This could potentially lead to huge time savings in the asset-creation part of production. Finding the right sizes for assets will also be a lot easier this way, because no design is distracting from the size of things. E.g. I have some tanks that are a lot more sturdy than other enemies and looking at them as compounds of 3 scaled cubes made me realize that the stury ones need to either be a lot bigger or a lot less sturdy, or get a different color, because it's too hard to distinguish them right now and just "feels wrong".
Also like you said, graphics mask gamedesign and I feel like all the flaws instantly become more visible.

 

I haven't done anything on my game the last week but I've spent a lot of time on the forum. That probably would be better the other way around. I'll be taking a break from the forum for a short while (probably till some time in december). I doubt I'll do much more gamedev now, since I'm still feeling generally overworked and burnt out. I want to try out implementing a "getting things done" style todo list system to finally get on top of things again in general.

"Whatever results you're getting, your daily routine is perfectly fine-tuned to produce exactly those results. Trying harder never is the solution, systemic change is the only thing that ever will produce lasting improvements."

See you all soon!

 

Short iteration/sprints - with playable builds at the end of the sprints? This could help improve boredom, increase reward by providing short cycles and quick feedback, and make - making games more enjoyable. When a person can see the fruits of their labors - especially when the labors are shorter and the fruits are more often - that can only improve a developers desire to progress.
It can also reduce the negative effect of building something and trying it out only to find it doesn't work well. This could be a real difficult thing to overcome if the creation took more than a couple weeks and redoing it is going to take more time. If the iteration is shorter and having to redo something will also take the same amount of time or less, seeing flaws in a creation, when the creation was created in a short amount of time will not hit the developer in the gut as hard when it needs to be recreated or reworked.

Speculating here - is the answer presented here in the question? Scope!
I agree good things take time, and that goes for large good things and small good things. If creating a small good thing - the creation will take longer if the developer has a strong desire to make the 'thing' good, or releasable.
IMO - boredom comes from either not having enough motivation to proceed with a task because it is too daunting and will take too long and seeing the results will not equal positive feedback, OR not being 'in to' the thing you are creating. I don't know - if not into the thing being created, why would I be creating it?
Reduce scope so the build can be experienced quicker and new elements can be tested/iterated on faster.

Have you thought about using all replaceable placeholder audio? I'm not an audio guy and haven't messed with anything in game development related to audio but I would think some things kind of need audio queues to 'feel' correct, like a shift in tone when the scary monster is getting closer, or a audio-gasim when the victory is won. Using placeholder audio could provide this feedback and allow the audio systems to be implemented (temporarily/quick) while keeping the knowledge that it is all placeholder and will be replaced at the end of the development.

This is why I've chosen to develop for mobile/web initially before considering PC.

I checked out that game. Looks kinda fun and the feedback on steam seemed very positive. From steam spy roughly 200k copies sold. What makes this an unsuccessful release?
From my rough estimate from steamspy numbers they are taking home about 2.24million after cuts and taxes. Guessing the team is larger than 10 members? making the take home not so good, depending on how many years they worked on it.

Looking past that, seeing the results and knowing the game as you do - it seems you have a beneficial opportunity to gauge how/why the game was not successful, and what changes could be made to it - to make it a successful title.
Since you are intimate with that type of game - you could continue with your design, knowing what and how to side step the issues that led to that game not being successful.

Although art is a not essential for early development - it is needed for the reason snacktime mentioned. Additionally art developed early provides hype/marketing content. Even if a lot of content changes eventually throughout development, early art is essential for early promotion and ongoing marketing of the game.

 

For me, I basically don't have any motivation if I'm working solo, or with a teammate who isn't talkative/doesn't have design/story ideas. What's tremendously motivational for me is if I'm working with at least one writer or designer that I'm really interacting with to create something new. Even better if it's more than one person or if it's someone really enthusiastic or whose taste matches mine pretty well.

Another thing that is terrible for my motivation is starting a project with a sense of poverty and restriction - "oh we don't dare try and make that genre of game, it would be impossible for us." Being practical is one thing but I can't be creative and productive in a pessimistic or strict environment.

 

I've unsubscribed to notion of using cubes or no audio for blocking, with fairly strong feelings towards it.

There is of course a few exceptions as always, for instance if it's purely about gameplay and nothing else, or if you plan on outsourcing art, it's usually better to have them make first passes than spending time on it yourself.

Or if you have a very confident target goal (I never have for my projects, I have more like an angle and narrow it inn as I go).

But, I'll try to explain my reasons for stating this.
I believe good craftsmanship is primarily a result of many many iterations, and idle time passing between each iterations is an essential part of it.
This is why I want to have as much time iterating as possible, rather than dump all the work in the end and hope for the best.

What I think one should avoid at all cost, however, is polishing or spending too much time on specifics too early.


A few weeks ago I had to start on a new system my project, the very very first tests, looked like this


And while cubes can help you decipher if things are working as they should (or more often than not, not working as it should...), it gives me zero information to what kind of atmosphere or vibe I want to convey.

As soon as I had a very primitive sort-of-working system in place, I started making some very quick placeholder objects.

This took me about 3 hours to do and a few more to dump into Unity. And has probably been the most fun hours spent on the project yet, as my own barrier for quality at this point was zero.

It's absolutely not production ready, most of it has messed up pivots, non working UV's etc.
But I get a very basic starting point to work on. And I can turn my whitebox area into this

This is something I can look at, evaluate and iterate further on. It gives me an idea of where I'm heading and how much work I want to spend on more passes.

I know that publishers hate placeholders art that can be mistaken for not placeholders, and since this is my own thing I have the "luxury" not caring and iterate look/feel along with game play.

I should say, since this is a hobby for me, I always have the option of wasting all the time, putting the damn thing on the shelf and not feel bad about it.
But in my professional experience as well, I've found that there is a fine line between having too much detail in pre prod and too little detail.

 

I have found that it helps me a lot when making a character model to make it "complete" for each level of detail, rather than working one piece at a time to completion (or somewhat near completion).

For instance, I had a pretty high resolution sculpt of a female character for a long time before I gave it any hair. But just adding a blob of place holder hair helps me envision the character and make adjustments to other places much better.

 

I've watched dozens of youtube videos while I was gone and the closest to an "answer" I've come is this:

I found it well worth listening to about half a dozen times because it's very concise and can be reflected on from a number of different angles. I feel much the same when it comes to making music.

I haven't really done anything gamedev related, and I'm not sure I will again any time soon. I've grown up with an attitude of "I can learn anything I want", but gamedev might be the first thing I've hit that I just can't do. Referring back to the video I linked above, that sort of curious experimentation with creative things is how I've always approached painting and composing music. I can do both things without having any idea of what it's gonna end up as. Also music and paintings have very very low barrier to "being music" or "being a painting". You basically have to try really hard to F*** it up so bad that you can't listen to it once or look at a painting for a minute. With games I think it's much harder to get them to a level where they even "work", let alone be enjoyable enough for someone to play through it just because they like it. I don't think the kind of games that I care about can be made in that creative experimentation kind of way. That might work for tiny games like super hexagon, but I just have no interest in those and I'd rather not make games than make that kind of game.
The game "Strafe" also got me thinking. What they achieved is probably out of reach for me, but still, playing the game for a bit, I'm not sure I could have brought myself to release it. I think it's terribly flawed and could be so much better. I would have needed serious outside pressure to release it like this. I might just not have the right personality type to be successfull in gamedev.
And maybe I care both too little and too much about what others think. I care too little about making something for others to enjoy, I only would make a game that I would enjoy myself, but I care a lot about not wanting to expose others to a broken and flawed mess of a game. Those should ideally be not on those extremes of the spectrum.
There's a bunch of other reasons why I feel like just dropping gamedev for now. One big one is general decision fatigue. I think I just can't do this "on the side as a hobby" anymore.
And then... me making this kind of thread is probably already a major red flag. If someone would ask me "how can I make painting more fun?" I'd tell them "If it's not enough fun for you already then it's never gonna be, just do something else".

Your estimate is waaaay off because most of those sales where from humble monthly. You could see a very sharp jump in the owner stats of steamspy after the bundle hit, which made me deduce that there must be at least 100k to 200k humble monthly subscribers, and I estimate that a game like brigador gets 1$ or less for being in such a 12$ bundle because of humble's cut, VAT, fees, and the "public preorder" (visible a month in advance) games in the bundle likely get more than the others, because they generate more new sales than the surprise games.
Here are some articles that each link more articles if you're interested in Brigador:
http://www.takethis.org/2016/07/bri...the-mental-health-costs-of-indie-development/
https://steamed.kotaku.com/what-happens-after-an-indie-game-fails-1784062530
I think they were 2 guys working fulltime crunch for ~5 years, plus a few other contributors for music, sound, narrative etc.

Yeah, don't like the idea because that would still be a bunch of work and occupying space in my mind while then constantly distracting me during playtests because bad stuff bothers me a lot. I can't calm my mind with "it's just a placeholder", if I hear something that I could make better I want to make it better and I don't want to wait 2 years for it. I think I'm personally better off with no-audio if the genre allows it. Others may very well be different.

They had too little that makes you genuinely care, both in narrative and mechanical progression, too little ways to express yourself, too steep a learning curve in the controls, too much insistence in the beginning on not changing the controls (they later did change them), too poorly telegraphed insta-death situations that lead to frustration, too high difficulty maybe. I think mech games just sell poorly if they don't belong to a big franchise like Battletech. I don't think I could "just not make their mistakes". Quite the contrary, by design I'm bound to have a much higher barrier to entry in terms of controls and learning curve. It probably was just too niche of a game concept.

 

I feel ya - just 'releasing' the small simple demo build of FTtT I was a ball of nerves and hated the feeling, and loved it all the same - the difficulty and the struggle and the emotions. Truth be told - I was anxious about it because I was concerned people would not 'get it'. And I knew there were things I still needed to add that would help players get it easier - but I set a date and wanted - for once - to release when I said I would.
So - I get what you are saying - but I always try to find a solution to a problem.
Maybe a solution for you might be - creating one polished level of something. All the mechanics - all the dodads and all the polish you can muster - and release on all platforms other than steam. Gauge interest, collect feedback and go on from there.
To me - that game you referenced - Strafe - I could see you getting one solid polished level of that game released in 6-8 months. idk your schedule - but I think I know your ability - and I could see that as a do-able thing to accomplish. 1-2 levels. People either like it or not. If you do - it doesn't really matter what others think - as long as it is your game.
If people do like it - "awesome fun - but only 2 levels fail!" that says - build more levels. If people do like it - that is huge incentive to move forward, rework anything that needs it and progress on stuff that works well.
But - most everything that has a better enjoyable roi for the creator than game development - I think.
I've been watching 3Dcoat vids - well listening to them, and I'm saying to myself - why am I not sculpting all my models, and it is because I have set dates and I want to get them done and on to the next stage, but digital sculpting is so rewarding and cathartic - to me - if that is all I did for the rest of my time - for enjoyment I would be alright - but I still feel like we need to challenge ourselves internally and externally - to feel that fleeting sense of accomplishment that is not given but earned through hard hours and determination.
Not to say you already do not do this - just giving some positive words of encouragement.
Maybe music for you is the same as sculpting to me, but if the music is that easy for you (I can't even hum in tune) do you think that will provide what you need? If so - that is great, but I need to do more than sculpt. I can do that anytime - game dev is something that is difficult - and something I am constantly grasping for - cussing all the way!

I thought about that after I posted - I wonder if they had a humble bundle?
Thanks for the links - good stuff - though not good - but good for learning purposes.

 

After reading up more on Brigador I have some thoughts;
Game was out of scope for the first time developers - and the budget they didn't stick to. Though from the articles they seem to have given this thought, reducing burn rate as much as possible, but that didn't reflect in the duration it took to complete the game. Scope was too big.
Don't create your own engine from scratch unless you can afford it. Unity in 2011 was available and larger titles had been created using it. They had other options as well but decided to go the 'from scratch' route.
*If* the mech genre is as niche as stated - why spend 5 years developing a product for that tiny market? I don't think it is as niche as mentioned.
Those who love that genre seemed to dislike the awkward control scheme the developers choose, so they passed on the game - initially anyway.
Hindsight here - Should have reduced scope to make a game that is viable in less time for a niche market - to allow for use of a off the shelf engine that provides tools/features out of the box that can be incorporated today, instead of 6-12 months after development begins.
All assets were created from scratch. That takes 10x or more time than using readily available assets they could have used and populated environments with - today - not 3-6 months from the start of development. Stop signs, lamp posts, buildings and roadways are all peripheral content that will never be remembered, and can be edited with minimal effort, they do not have to be created from scratch.
EA seemed to be kind of tumultuous because they didn't offer a early adopter pricing/discount. Debatable.
They got more sales from this discussion on the steam boards about EA pricing than they did from any other marketing efforts.
PR agencies didn't seem to make any difference at all - early or late during development.
They also lost sales attempting to relate the 'effort' put into developing the game should equal a certain price point of the EA and final game. I don't believe this is a winnable discussion for any 'product'.
The game seems to have a modest long tail - driven by "we failed" promoting/marketing - for first time indie team with no other game ever developed.

Marketing material is kind of just there. It really doesn't sell the aspects of the game at all other than fully destructible world. What else is there? I don't think they sold/marketed the game well, but this is debatable.

They went humble bundle only one year after release. That might be too soon if they were still working on marketing the game, maybe updates, addon-DLC, extras - changing the control schemes. Seems too soon, maybe not. Humble is definitely something a developer should do - last, not within a year of release, unless sales were totally dead. Maybe they were. I think they probably jumped on humble too soon before exhausting all energy to continue marketing. They certainly got sales after the "we failed" publishing(s). But those were after the humble listing. Should have thought about that a little better, "we failed" while the game was at full price - or at a discounted price on steam, would have resulted in better sales, not after listing in the bundle.

Ultimately same mistake that 'can' be avoided - go all in on one product with financial support of savings and family. Not really a smart decision, but passion drives this decision and it can be a winner if the plan is strong. Knowing the audience, estimating accurately the budget and estimating how much game can be made in that budgeted time frame is crucial for success. I support there decision even if it was a failure.

I still believe the game was a success - regardless of the time it took the developers to make it. They made a solid product - from the looks of it, and sold a high number of copies. If they would have used Unity or other engine, and reduced scope, and purchased some asset packs of unimportant assets, that would have removed at least 2 years from the overall development time. It only failed commercially because it took 5 years to make.

Anyway - I'll pick up the game because it looks interesting enough to check out - when it is on sale - cause it's not my type of game!

Hope the dev's have recovered from what appears to be a 5 year grueling development. Though - how much time was spent watching indie game the movie in that appartment?

 

I'm glad it piqued your interest. But I doubt they would have saved time using Unity in 2011 to make a game that has a very special custom rendering pipeline. They render all their 3D assets down to sprites with both zdepth and normalmaps so that they can at runtime calculate shadowcasting and stuff from the depth rendered into the sprites. They likely would have had to fight Unity left, right, and center to make that work, and also slog through all Unity bugs in those years of development. They might have wasted time on tools and engine features they didn't strictly need while going all custom, but I doubt they would have gotten tangible savings from using Unity.
I also think if they hadn't used their own custom art and polished it up to such a high standard, they wouldn't have gotten into the humble monthly bundle in the first place. They may have made more assets than they really needed, but I'd rather recommend making less different assets for the game than throwing premade 3rd party assets in there.
It's always easy to look at a finished game and say "that shouldn't have taken x years", and I'm sure most of the devs of such games will say "well d'uh, tell me about it". Trying to make anything slightly more innovative than a clone of something takes huge amounts of time for experimentation and iteration, and polishing takes huge amounts of time too, but you can't just cut both out and still expect to have a polished and sellable game in the end. Imho down-scoping and not polishing so much would have just killed the game in a diferent way commercially. You can't expect it to not affect sales negatively if you subtract 2-3 years of work from a 5 year project.
Here's another mech game that has high production values and flopped:
http://steamspy.com/app/411540
I wouldn't recommend playing it, imho it's not a good game. Brigador plays much better. I think it's well possible that this difference in gameplay quality can only be achieved with years of iteration and refining, because Hybrid Wars must have had some pretty competent and experienced people working on it, since the developer is apparently like a small sub studio or something of the makers of World of Tanks. But they clearly haven't iterated on its gameplay design for years on end because its imho much too basic.

Iirc they knew well ahead of release that they will likely never break even on it, and they wanted to have at least the best game they could possibly make at the end of their soul crushing dev cycle, which I can understand. A good game opens door, both to things like crowd funding or investors, or to more regular gamdev jobs, both freelance and traditional employment.
Saying "they should have just made the exact same game in half the time" isn't really helpful for any project that failed commercially, because unless it was a grossly and incompetently missmanaged project, it's just not possible.

 

What value did this bring? What does shadowcasting do (genuine question, a brief look online didn't give any clear definition)?

I'm sure we're all aware at this point that a huge portion of game design is a series of tradeoffs based on questions like "is this fun" or "how much effort does this take for how much gain" and so on.

...which might get back to you, from how you've described yourself (as a perfectionist). You may sympathize with their perfectionist (gonna make our own engine! Gonna have all these fancy features that add nothing to the gameplay and barely impact enjoyment!) approach, but in reality it hinders their efforts in the grand scheme of things.

 

You're probably right.

Nostalgia triggering aesthetic (I originally wanted to go for prerendered sprites too like in old Fallout games) and you can draw tons of detail with fancy lighting on screen without worrying about the polycount of the models. The assetcreation also gets some time saving benefits because some things work well with solid colored highpoly meshes without any kind of UV unwrapping.
I'm not saying it was a great choice on the bottom line, just that it would likely have been hard to do with old Unity versions imho.

 

Agree a bit, but my point is scope was too great anyway - so is that really an important thing to work out - a special rendering pipeline? This is a small first time indie team. They over reached and should have at least considered scaling back. They didn't say such - but who knows maybe they did, maybe what they released is something already scaled back compared to what they originally planned.
This special rendering pipe is a good point that could have been reconsidered. From looking at the marketing material - the special renderer doesn't show much better - imo.

This would have fallen between 4.2-4.6 arguably one of the most solid build times ever for Unity. (my opinion)

Agree - this can't be disputed. Experimentation and iteration and polish take time x4!

This is where we don't agree. I think the scope of the game was too much for that team to successfully create, on the budget they had. Even if the game is complete and to an individual it is fun to play, commercially it was a failure because it took too long to create. Players have stated 60-80 hours of gameplay. That seems like it could have been scaled down drastically and still keep the same price point.
It just seems from reading all the accounts - the developers said "yes" to everything - instead of telling themselves no every now and then, starting with creating a custom engine from scratch.
But - hey - they went for it ALL in! That takes grande' balls and I would shake there hands for having the will to make that decision, and making a quality game -

I just believe full-time indie is not something everyone can do, more than half will fail - and that is alright as long as they learn and return to good health afterwards. Full time indie is something above the norm - imo - and not everyone can do it, because it's hard to make hard decisions about a lot of aspects of design, dev, and all the rest that goes into creating something that more than 10k people would pay money for.

Agree - they should have made half the game in half the time. This is coming from a guy who wants to make a 32 man roster for a tic-tac-toe game! Bahaahaa. Some of us (me) have to learn lessons the hard way.

 

General question to everyone: if you were to make a singleplayer game just for yourself, never to be played by anyone else... what would that change for you? How would you approach it?

 

Interesting question. It probably deserves its own thread, but I'll share my thoughts here. It wouldn't have an authored story or pregenerated levels, since as the designer I'd know everything beforehand. So it would be something procedural or emergent. Dwarf Fortress comes to mind.

 

The only single-player stuff I'd make for myself would probably be some kind of "tycoon" game, or rather several different kinds (along similar lines to TonyLi's statement--systems-driven stuff). There's a real paucity there in recent times.

However, I don't think that's a "fair" question. That's like asking a songwriter what kinds of songs he'll make if he shows them to no one else, or a writer what he'd write with no audience. We do it primarily for the audience. Without them we're kind of hanging in the wind.

In my case I DO have some stuff I don't think anyone will ever hear or read. While I do it partially for the audience, ultimately I can't help but create simply to express myself.

Such things (music and writing I have no intention of sharing) tend to be very depressing stuff. So in a sense the idea of a potential audience to create for helps me as much as my ideas may "help" them.

 

If a story driven game - story prompts from one 'game play' section to the other, I'd probably have some crappy static placeholder content - and never update it other than maybe onscreen text, because I have the story elements in my head, I don't need to present it so others understand the arcs.

The content generally would probably be less polished as well, because the vision in my head could fill in the details of that awesome 8k texture that is only 256x256 on screen.
I think most 'entertaining' visual and polish elements would take a back seat to functionality and mechanics. The game would play well on the core mechanics but probably very clunky in other elements, UI and such.

Hmm - maybe this is how all games should be developed, with this type of iteration in mind. No one will ever see this so I'm just going to work on the important functional elements.

I'd say mostly the core of any game type would be a solid, fun experience while all the extra elements that are commonly 'required' to have a publicly released title, would work but probably not great and look like crap.

 

I don't think it's anything anyone would specifically search for, so I'd rather keep it as a part of this meta-gamedev discussion because ultimately the question is born from the same musings that caused me to make this thread in the first place.

Gameplay designed around the possibility to surprise yourself sounds like a solid approach for this!

I don't think the question is "unfair", I think it's "interesting". If your answer is "none, I only would make games for an audience", then that's a perfectly valid answer.

I would probably still (over)polish some of the graphical aspects that I really care about if it is stuff that I find interesting to experiment and iterate on. But I could see myself replacing large parts of GUI with hotkeys or hardcoded settings in text files.

One key question to ask oneself would be whether the game or the act of creation is supposed to be the fun part (or both). Some might get the most enjoyment out of doing something complex like e.g. with neural nets, that for all intends and purposes isn't really a game on the playtest side. Or rather the game part is making and training the AI. Others might be happy to keep the coding very simple and focus on creating their own feedback loop of making small changes and seeing them reflected in the next playtest. I'm just curious what others would hope to get out of it, if they did it just for themselves.

Personally I don't know what I want. Like... at all. I'm just theorizing that I might be better off going all in on the "nobody would buy this" in a sense of trying to silence all the thoughts that revolve around issues with other people playing (or not wanting to play) my game. I'm a lot better at seeing upcoming issues than finding solutions for them, so just having "other people" or "the audience" be a part of my considerations feels really paralyzing.

I by no means want to imply all games should be made with such a mindset, that would be a really bad idea.

 

I suspect - most developers enjoy creating more than they do - play testing, which is rather odd right? We are supposed to be creating fun, enjoyable, engaging experiences. The game should be entertaining to play!
However on all the projects I've participated in, even my own - getting the developers (even me) to play test was like detention, like taking away the toys while they had to perform chores.
This seemed like a common theme - others might chime in with alternate views, but this was a consistent observation on several different types of projects. To be honest - I didn't enjoy play testing either, would rather be creating art instead.
On my own project - we were creating a playable build every Friday so I would play test several times, during the weekend, and then address the issues and progress with other tasks the following week. The play tests were just another weekly task to complete.

If you haven't - consider watching and listening to the Gunpoint developers GDC talk in its entirety. I think you will find it very relate-able and relevant to this entire discussion.

 

I have on occasion booted up Unity to just do a quick playtest and remind myself where I was. It never was that chore that I had to force myself to do. Most of the implementation tasks I probably find less fun than playtesting, unless they're fun challenges to tackle in and of themselves.

It's one of my favorite talks, I've watched and linked it here multiple times.

 

Hmm - yeah that is different type of play testing, more like prototype testing. The play testing I'm talking about is more along the lines of testing designed mechanics for feel and functionality, and bug testing. Also UX testing - blegh! but has to be done or suffer the wrath of bad UX.

 

I think it's a great feeling when you play your own game, and you're genuinely enjoying it.

 

I don't mean "unfair" in the sense that we tell a child "life isn't fair." Fair may have been a poor term to use. What I meant by it is...here's another example. It's like asking a scientist, "if your research would never be used to help the world, what would you research?" Maybe that's a bad analogy. But what I mean is that the thing you're taking away is a pretty fundamental part of the entire purpose behind the action in the first place. I hope that makes a little bit of sense.

The answer would definitely not be "I would only make games for an audience" for me. Most of my "art" has never been seen by another person, and probably never will. I create because I have to. But things get really funky and motivation suffers enormously in such a case.

I have well over 100 (probably closer to 150) songs written, but maybe 10 are set to music (and I have a bunch of mere ideas that have no words). At least half a dozen story or novel ideas. Only one is completed, and another is like half done (the others have barely any content). Probably a dozen game ideas (let's see: life sim, walking sim/dialogue game, catharsis game, animal raising sim, CA+Hangman game, 2D platformer demo, RPG, VN, third game in RPG+VN series, plus a couple other things I have absolutely zero content for). Only CA+Hangman is kind of complete, and the 2D platformer demo is basically placeholder "complete," but everything else has almost nothing to it.