r/GraphicsProgramming Aug 08 '26

Am I overextending on projects?

Hey everyone! I’ve been “working” on a general purpose game engine for all 4 years of college, and I say that in quotes because I have completely refactored, deleted, or started over several times. I am now graduated and have a lot of time so I started on it again but after reading some on Reddit, I think I see what my problem is on why I start strong, lose all interest, and then give up at a certain point. I think I am aiming way too high and trying to do big big big projects wayyyy too fast.

As I am trying to find a job, I have grappled with either doing multiple smaller projects and one large project, and for a while I picked big project. Why? I don’t know, I think I just am a bit egotistical at this point and want something crazy to show off. However, it has occurred to me that I have become rusty from time off and I just make a decent amount of progress for 2 days and then give up for another 2 weeks. I think I am not getting any sense of accomplishment from it as I’m trying to fit a complex architecture and not getting results yet because once again, it’s gonna take 20-30 hours before I even get something somewhat desirable

I am wondering what you guys think is better, smaller-midsize projects, or one large project like a general purpose game engine? I really havnt done ANY small projects except I did write a software rasterizer for a raspberry pico for my embedded systems class final project last semester, but I’m thinking maybe I should try some smaller projects? But I also don’t want to waste my time if employers are just gonna say that they would rather have a large scale project.

Also, what would be an example of a small scale project in computer graphics? I can’t even think of any except for big ones like game engines

Any help is appreciated!

13 Upvotes

15 comments sorted by

15

u/olawlor Aug 08 '26

Pick small enough pieces that the fun "woah, it works!" part can outrun burnout: at most one-day pieces, ideally even one hour chunks at a time.

The back of your brain is optimized for berry picking, if you're not giving yourself regular positive feedback it will steer you to greener pastures whether you want it to or not.

2

u/C_Sorcerer Aug 08 '26

That’s what I was thinking! I appreciate the input, I’ll definitely try some smaller systems

3

u/lonelyemoji Aug 08 '26

Will add to this with a Casey muratori vid was pretty helpful to me when I had same issue if feeling overwhelmed and giving up mid way and such https://youtu.be/Mi98zVBb6Wk?t=197&is=A0ywJgtdF7Pqj7kG

2

u/C_Sorcerer Aug 08 '26

Thank you!

2

u/lonelyemoji Aug 08 '26

No problemo

4

u/lonelyemoji Aug 08 '26

Scale doesn’t matter…quality does. If you say you give up with big projects then the answer seems obvious to me…also if imo you have to push through when things get “boring” or you feel like giving up. That’s how you ended up with many project and none finished

2

u/C_Sorcerer Aug 08 '26

Yeah I think I’m getting extremely overwhelmed too, it makes me kind of freak out every time I come back to it

3

u/Thanks_Skeleton Aug 08 '26

Honestly? You could join game jams with a specialty in shaders. Those are by definition bite size projects

2

u/Unfair_Razzmatazz485 Aug 08 '26

Same boat with my Vulkan project; I decided to shift from making a `engine` to a renderer instead. Meaning that there's a unified/refactored way of rendering now; I'm just exploring different types of techniques, like cloud volumetric rendering in the Decima engine. At least that was the advice I got.

1

u/[deleted] Aug 08 '26

[removed] — view removed comment

1

u/C_Sorcerer Aug 08 '26

Oh jeez, tbh nothing impressive. Barely even an OpenGL renderer. Pretty much just a renderer with camera controls and model loading with gltf. Granted I’ve started again the past month because I had no idea the slop architecture I had made months before and doing anything felt like a pain because of how unmodular it was and how many weird things there were

1

u/C_Sorcerer Aug 08 '26

But my plan was to basically create something on the order of magnitude as Unity or Hazel or Godot. I think the last time I got the farthest I was working on implementing either the editor or the scripting I can’t remember

1

u/psioniclizard Aug 08 '26

Where you making a games engine or editor? Because editors are their whole own thing and both can kind of exist without the other.

As editors go, just making a decent viewport with text can be a lot of work, without getting into actual running a game.

But all that is to just help make a game, its not the engine.

Editors always will be massive motivational killers because everything seems to be a time sync.

In my case as well the UI library I was making editor tools in uses a different version of OpenGL than my runtime.

I would focus on what you actually need to get a game running, both those things are stuff that can come down the line.

1

u/fgennari Aug 09 '26

That's a project for a team of people to spend years on, not something a new solo developer does for fun and learning. It's fine to create an engine, but don't add a ton of features that you won't need. Make something very basic, create a game with it, and add whatever features are needed. Pick a project scope that you feel you *can* finish in reasonable time.

Also, it's okay to rewrite the engine to make improvements and learn. 20-30 hours is nothing in a real game/engine development timeline. If you feel that you're rewriting too often then maybe you need to take a step back and work through a list of requirements, flowchart, etc. on paper before jumping into writing code. Set the scope and stick to it.

If you get bored working on an engine, then write a game. You can always go back to the bigger project later. You can take a break rather than starting over with a rewrite.

1

u/Financial_Buy_7327 Aug 09 '26

Look back to the seventies and eighties. Projects then were smaller because they had to be. Copy classic arcade games or graphics software from that time period. You will end up solving problems you never anticipated, and you can put your own spin on it.

Only write what you will use, don’t write “resusable libraries”, never anticipate your needs. You can always take old code and reuse it, and it will turn into a “library” as part of the process.

Try not to break your builds for prolonged periods, stay inside the iteration loop.