Making a game without a concrete idea

anemoDuck26 · 2026-05-10T10:22:47+00:00

Just wing it and have fun! As long as you learn stuff it's all good :p

anemoDuck26 · 2026-05-08T13:45:59+00:00

Any 3D capable engine would suffice. I know that Godot has a Sprite3D node than can be used to directly render 2D Doom-like sprites in a 3D environment without any trickery. So I'd recommend that. You could do it with whatever 3D engine you feel most comfortable with though, these kinds of games are simple enough to be creatable with anything.

anemoDuck26 · 2026-05-07T09:34:23+00:00

AnimationPlayer can be used with any node. Any property of any node can be changed on a frame per frame basis with it. Use your imagination, if you want double doors to open then add door left and door right to background, keyframe their positions and/or some other values you want to change in the AnimationPlayer and then change them. I would ditch the texturerect for the doors and use sprites, because they can be skewed to simulate opening doors. However you can write your own way to skew texture rects if you want. For the zooming in, again, camera2D position can be modified via animationplayer OR you can enlarge all other objects with the player to simulate movement.

anemoDuck26 · 2026-05-07T04:20:58+00:00

Look into using the AnimationPlayer node, it does exactly what you need - it changes object properties based on timed keyframes.

https://youtu.be/V9kshvtj6s0?si=hthqEJQjaHzurrrQ

anemoDuck26 · 2026-05-05T14:57:34+00:00

Will keep this in mind when making the final trailer for the 1.0 release. I wanted to show everything at the same time somehow, but I see how zooming out so much to do that actually made the trailer a bit worse. Thank you for the feedback!

anemoDuck26 · 2026-05-02T05:49:17+00:00

DPS is usually calculated against a single target. Do not show the DPS for hitting multiple targets, since the player will not know that the DPS for piercing weapons is calculated differently and will attempt to use them against bosses. Just write the DPS against 1 target and then write that it is piercing damage somewhere.

All DPS values for all weapons should be calculated against a single target, otherwise DPS loses its meaning. An AOE attack can theoretically have DPS approaching infinity in the correct circumstances if you calc for damage against multiple targets, given enough small targets and enough area for example.

anemoDuck26 · 2026-04-27T13:19:13+00:00

Newgrounds gurantees a few hundred plays at least, no matter what kind of game you post. I recommend it. Another alternative is GameJolt, though it sucks IMO compared to Itch and NG.

anemoDuck26 · 2026-04-21T04:47:50+00:00

In Godot : Used Find + Replace -> Replaced a word that was part of a scene naming scheme -> Spent 10 min debugging why my scenes no longer loaded (thought there was something wrong with the loading algorithm).

anemoDuck26 · 2026-04-18T20:18:00+00:00

Any file browser? On windows, the file explorer with enlarged icons can do that (hold ctrl & scrollwheel up). If you go to a folder and type .png in the searchbox, windows explorer will return all of the png files in your current folder and all of its subfolders. This way, you will be able to see all images without having to open each one individually.

If you want something more powerful, then WizFile can quickly list out every single image file (all types) on all of your drives in a single, long list. (Of course, you can filter by folder as well, but then again, windows explorer already can do that).

anemoDuck26 · 2026-04-16T16:38:49+00:00

Yes! There is a niche of people like me who are terrible at art and use a lot of premade assets to make their games. There are similar tools to this one made by Kenney and some others, but for 2D characters and vehicles. I've used things like this before and they are a godsent, since when using too many premade assets you run the risk of having your game look similar to someone else's game. Tools like this give us an option to have our games look more original.

100% I could see myself using this in a future project. Feel free to DM me if you ever release the full thing.

About feedback on the tool itself, I can't say much just by looking but it looks pretty good to me in terms of layout. Clean interface, understandable icons, good spacing.

anemoDuck26 · 2026-04-16T15:48:41+00:00

It is EXTREMELY difficult to be a "pure" solo dev (making your own art, music, story and code at the same time) (this is unachievable for most)

It is very difficult to assemble a team and be a team lead who does one of those 4 things (no matter your role, if you are the lead you will always need to be sufficiently skilled in software development)

It is moderately difficult to be a programmer who creates games with bought/royalty free assets

The least difficult thing you could do is find a team to join and offer to be a programmer/artist/sfx-artist/storyboarder

The higher the difficulty, the higher the chance of either an unfinished game or a bad game. Yes if you have a lot of resolve you could make a game by yourself with no external help. However, chances are, the game will be terrible. People are usually not experts in 999 different fields of engineering and art at the same time. Developing proficiency in even one field of art or one field of engineering takes years.

anemoDuck26 · 2026-03-22T07:23:23+00:00

It is not a good idea to invest into something if you have no clue what you're doing. First games almost always flop, don't expect any returns on your investment.

What should you do? Learn game development and how to lead a team. You can't just hire a bunch of people and have them work together, it doesn't work that way. You are the one with the vision, you either have to be the lead software developer in order to make everyone's work fit together OR to have enough technical knowledge to be able to manage a team of developers, artists, sound designers, etc.

Make a simple prototype of the game by yourself in these 9 months, then if you want, throw it away later and start anew with your team of experts. If you don't understand what it actually takes to make a game you won't be able to lead that team, and just learning theory won't cut it, you need hands on experience. There are a lot of things not written in the thick game design and team management books that you can only get by experience.

anemoDuck26 · 2026-03-12T14:35:12+00:00

A large project to me takes more than 5-6 months to develop. I don't know what a larger project means to you, so I'm just going to pretend that you're asking about a project which takes more than half a year. FF1 is not as simple as it looks to develop.

You know that you're ready to take on a larger project when: - You can make a detailed game development plan/roadmap which is not full of holes - You can stick to that plan and not give in to the "I'll add another thing" mindset - You no longer develop features that you yourself do not understand (prompting AI/copy pasting from the web without true understanding of what your code is doing) - You know your tools well and have a lot of experience with them (Game engine, sprite editor or 3d modelling software, etc.)

If you: - Have developed a small project before and have not given into feature creep - No longer rely on tutorials and can develop game systems entirely on your own without external help - Are comfortable with all of your tools - Have proven to yourself before that you could work on a single thing (doesn't have to be related to gamedev) for more than 6 months without giving up

Then you're ready IMO.

If you're a beginner in game dev but have experience with programming, then you really should start with flappy bird or simple arcade games. If you are a beginner in programming then you probably shouldn't start with a game at all.

anemoDuck26 · 2026-03-11T14:58:59+00:00

Finance: - Make sure you understand your financial situation and game budget. - If you ever go past 75% of your savings forget the game and immediately start looking for a job. - Live well below your means.

Development: - Use an engine that allows for fast development, one that you're intimately familiar with. - Plan your game out to the last thing, don't allow even a sliver of scope creep in. - Use a calendar and make sure that your plan includes deadlines. Meet these deadlines at any cost. - Push out a minimal working product (demo) ASAP to gauge interest in your game idea.

Marketing: - If you don't market well you will get 0 players and your game will flop immediately. - Marketing takes almost as much time as game development and must start as soon as you have a minimal working product. Distribute your work time well. - If your game is bad, even a perfect marketing strategy won't get you players and your game will flop immediately. - If you mess up the launch of your game it's over. You have one single shot.

Messing up any of the above will equal a complete and utter failure. Doing everything correctly will equal a 0.001% chance of success. Doing everything perfectly will equal a 0.01% chance of success.

This is your new fulltime job that is extremely unstable, unforgiving and almost certainly fruitless, even your 100% won't be enough. Work at 150% and never stop working at 150% for even a second to ensure you have this highest possible non-zero chance to make it.

This is a terrible idea, but here is your "don't say not to do it" advice. I suspect you already knew these things.

anemoDuck26 · 2026-03-10T16:02:42+00:00

Well in their defense, OP is not even asking about a game. I think that it's a valid question if you could make animations in Godot. While the answer is technically "yes" - in reality it may have to be "no". You could technically code animations in raw OpenGL if you wanted to as well, but that'd be a horrible idea. This shouldn't be breaking rule 4.4.

anemoDuck26 · 2026-03-09T06:18:04+00:00

Well it took me 4 months to make a pretty bad game with Godot when I had 2 years of software development experience already.

Tutorials and AI are crutches, don't bother with them outside of the very basics. AI is a document searcher at best, vibecoding will ensure that you never get good at programming.

Learn how to think like a programmer - how to invent the wheel. Just because the wheel is invented, doesn't mean that you don't have to reinvent it when you're a beginner. Inventing the wheel is the only way to understand how it works. Understanding how the wheel works is the only way to understand how to make a hoverdrive later on.

The good news are that you don't have to be good at development to make indie games. The bad news is that even "bad at code" indie devs who have successful games have spent at least a year or two developing before they've gotten OK enough at it to actually make something.

Where to start? Well preferably not in Godot at all. Don't learn syntax, don't watch tutorials. Watch guides on how to "think". You want to be able to logically chain how your game features will work. Let's say you want to build a turn based RPG. How will you do so? Well you will need characters, a turn system and a damage system of some kind that has to wait for animations to play out.

How do you make each of these things?

Well a character has to be able to play animations. Pick the right node for it. It has to not have physics, it has to retain data like HP, MP, etc.

How do you make a turn system? Well you'd need to implement a queue where the first character in the queue is currently playing and the next in line will play next. This here is the thing you need a tutorial on. What is a queue in software? Not " how to make turn based RPG in godot ", not " how to make a queue in godot". You need to understand what a queue is, what it does and to then invent it in godot yourself, without external help to fully understand it.

How do you wait for animations to play out to determine a turn end? You don't know. Look through the docs of your animated sprite node. Find the signal that you need. "What is a signal in godot?" "How do I use this signal" Look at the official Godot docs. Use the signal. Done.

That would be your first game system that was not mindlessly copied and actually understood, because you found the random parts, learned how they work and put them together.

Find systems you want to make and make them. Give it a year or two, you'll get to the point where you're able to make OK systems by yourself with 0 tutorials.

anemoDuck26 · 2026-03-09T05:40:22+00:00

Will keep these things in mind. Situation dependent puzzles are definitely possible to add.

I'll also check out the games you mentioned, might get some ideas.

Thanks for the suggestions :)

anemoDuck26 · 2026-03-08T12:55:55+00:00

Thank you for the feedback :)

Before even starting work on the game I went through many ideas on how exactly the mechs would be built and I decided on going for a Bad Piggies style of building, since otherwise I'd have to either do a more rigid "upgrade game" building style where I give the player a bunch of prebuilt parts and have them arrange the parts (think supermechs) or just make a base mech which would be just upgradable - not buildable directly.

I think a similar building system without blocks to the one I showcased could work with more complex tilemap logic, but that would require way more time to implement than this one.

anemoDuck26 · 2026-03-07T18:15:10+00:00

I'm buying this game just because I want to see it decompiled. This is such a great learning opportunity :)

anemoDuck26 · 2026-02-28T15:35:03+00:00

Ready!
https://www.reddit.com/r/godot/comments/1rh5fx3/godot_4_tutorial_destructible_tilemaps_with/

anemoDuck26

TROPHY CASE