Sign in to follow this  

Preventing overengeneering

This topic is 480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

While I'm at work I do not have this problem, but for some reason while I'm at home I just keep geoengineering things a lot.. let me put that in a perspective,

I worked as a game programmer for 1 year, during that time I worked on the UI and gameplay. The UI was done in an Embedded Flash and C++, the gameplay was i"mplemented" in Excel Spreadsheets and C++. I did exactly what I was asked for, I'm confident that i've deviled and everyone was on the team was satisfied with my work including me.

Later for some reason i've decided to change my job (i had 1 year of professional experience in total at that moment). My new job is to write plugins and tools (usually for 3ds Max and Maya) for 3D rendering(file IO, talking to other plugins, UI, scene conversion tool like that, almost nothing around the actual rendering).

 

 

At home I'm developing that mini-game engine that I lie to myself that is for educational purposes only, but deep inside me I really hope to quit my job one day and develop a game on my own(probably with that engine that i currently write). The problem is that It has been 3 years of writing after work and during the weekend (while mixing real life).

The development goes extremely slow. For those 3 years I wrote:
- D3D11/OpenGL3+ - wrapper that misses some features

- A shading language (Vertex and Pixel shaders only) that translates to HLSL/GLSL @ feature level of ~ShaderModel 2.

- A flexible 3D models file format with import export. (and a small CPU skinning for that)
- a bunch of other small things (base64, DDS texture IO, Linux support maintaining).

 

And that's it for 3 years of work. It's just too slow and currently I blame over engineering:
 

Let me give you and example: for the last ~2 months I'm trying to design and program:
- a general purpose "entity system" (just a small set of features that i think are need my most of the games).
- a basic editor around that "entity system". an example would be a world editor, value tweakers.

- a Undo/Redo system for that editor.

That thing above itself is complex enough for me, but additionally I'm carrying the burden of over engendering. I'm going to give my most renascent example:

IF TL;DR start here:

 

For my level editor nodes I've implemented a very small structure:

struct Node
{
   string name;
   std::map<string, int> int_attributes;
   std::map<string, float> float_attributes.
};

I imagine that everything on the level is going to be represented by that stricture in the editor(the game would have a different implementation). So far so good, but I remembered that for the 3D Models file format I've implemented a class that holds an "animated value" :

struct Parameter
{
   int data_type; // int float, vec3f ect...
   void* default_data;
   std::vector<animated> data; // basically a set of [animation name, {key-values}]
};

So literally after 5 seconds I've decided that I must use that stricture for the level editor as I may want in the future to have animated parameters for my game objects! But as I think about it how often do you have animated values for your game objects.. Using that "Parameter"

 class will sure make thing a bit more flexible, but the code is going to be a bit more complicated and slower(well 3ds Max and Maya aren't that slow and their implementation of ParamBlocks and Attributes is a lot more complicated than mine).  And basically I cannot decide. My lack of experience is playing thick on me.

 

Now imagine doing this ON EVERYTHING YOU WRITE! I literally do it....

 

In addition to that i needed ~3 weeks to come up with an idea how to implement those features together (I have 0 lines of code on the topic so far), this itself made me super lazy, because the task seems really hard and for some reason I stayed away form Visual Studio and instead I wasted my time playing WoW.

Now I finally somehow recovered form that laziness, but I'm hitting that over engeneering wall...

So my questions are:

 - How do you handle complex task and avoid laziness and lack of motivation?
 - How do you deal with over engineering?

 - Do you think that an average programmer would do more for those 3 years?

 - Any thing you wanna add? personal experience and suggestions.


Sorry for the long post and my bad grimmer and spelling, here is a <potato>.

 

Edited by imoogiBG

Share this post


Link to post
Share on other sites

1- How do you handle complex task and avoid laziness and lack of motivation?

 
Keep it simple.  
 
 
Most critically, remember the scale of work is radically different:
 
At work you are part of a team. Hopefully each team member is working on areas they are confident and experienced with.  If you are used to working on a team of 20, they may produce in one week what would take you 30 or 40 weeks full time at home.
 
Second, remember you are not working on it full time. What might take you one week full time will probably take two or three weeks at home.
 
Combine the two, and realize that it may take you three or four years as an individual to do what your professional group does in a single week.
 
Your development speed at home is radically different from your development speed at work. I keep things simple be tracking my own speed at home and remembering it is completely unrelated to my speed at work.

2 - How do you deal with over engineering?


As above, I remember that I do not have time to get everything working polished and to my work standards. I can accomplish something minimal that gets the job done, and that is all the time I have for a hobby project. Always think small, then think smaller again.

3 - Do you think that an average programmer would do more for those 3 years?


Everyone's pace is unique. Doing something you are comfortable with should be much faster than doing something that requires learning.

I think in the grand scheme of things, people's skill at programming is a similar normal curve to any other skill. Most people who do the job day to day form a giant bell curve. There will be some who are faster, some who are slower. There are some who will be terrible and struggle to work professionally. And there will be the outliers at the top, the Michael Jordans, Magic Johnsons, Larry Birds, and Kobe Bryants out there who produce more than two or five normal people combined.

I've always thought it was funny how much emphasis many headhunters place on trying to land those rare superstars. They exist, but the effort (and high salaries) of trying to put together a team of actual superstars is off the charts. It is great to aim as far to the right of the bell curve as you can, the best people you can reasonably find, but expecting everyone to be in the top 1% is unrealistic. Most people are near the center of the bell curve. Some tasks they may perform better, some worse, but it all averages out in the end.

What you worked on is what you worked on. Don't compare yourself to superstars, don't compare yourself to domain experts working in their expert domains.

4 - Any thing you wanna add? personal experience and suggestions.


Scope smaller. Always think smaller. As an individual your time is exceedingly rare. Think about not doing the thing entirely, and if you decide to do it, figure out the minimum that meets the standards.


If you're still not sure what you can do in a month, work on a challenge of doing exactly one month of development. Build something in exactly one month, then put it away. Build something else the next month, then put it away.

The first few months you will produce things that are incomplete and maybe unusable. That's okay. After a few months you'll get better at figuring out how to scope your own personal projects into something that can be done in a reasonable time.

Share this post


Link to post
Share on other sites

I stmbled on opposite problem, I always overengineered mine stuff, when started to working due to impossible deadlines I started writing spaghetti code,

This bitten me later but not so much, in exchange I started too see the few places where a non-spaghetti code was better, few MVC there, a state machine over there and a decorator in one place and voilà, ship awesome features in  no time. Now I'm gradually strarting writing non spaghetti code at almost same spped (if not faster).

The problem is that as your own manager you know where you maybe want a change and you start overthinking, at work the requisites are not your decision so you stop overthinking, the solution is to not longer decide the requisites for your stuff, instead let a friend (or girlfriend) to decide features (you should give a visible result or cut it.)

In the current game I'm developing requisites come from another society and are changing several times a week, so even well coded scripts had to be dropped sometimes, if the game designer/ project manager started ith definitive requisites the game probably had to be already complete, instead the time I did'nt loss in overengineering was better used to apply on the fly the changes wanted by the designers/managers.

The most important stuff was to decouple visual from logic, since usually only 1 changed and rarely both.

Edited by DemonDar

Share this post


Link to post
Share on other sites

I solve the problem by writing what need to be done. If later requirements come along that mean I need to refactor then refactor. There is no need to think about future usage etc, as long as your code is structured well it will be easy to pull apart and put back together to take the new requirement into account

Share this post


Link to post
Share on other sites

If you are working by yourself and/or on a small team then you need to be brutal with scope-creep.  

If it is not necessary for the game then cut it.  

e.g. You do not need to support D3D if you have an OGL renderer.

Edited by Shannon Barber

Share this post


Link to post
Share on other sites

- How do you handle complex task and avoid laziness and lack of motivation?

Focus.

 

There is only one problem, namely the next smallest possible step. I often find the smallest next step is actually too big, and I need something else first. In that case, the thing to do first becomes the only problem that I have in the world.

 

Those steps are always things I actually need. I do a little look-ahead of tomorrows needs, but only for concrete needs that exist today. That  is an under-approximation of course, but I'll refactor the code to new needs when that need becomes concrete.

 

 

I can't really work on the same stuff for too long (at work I can, but it's very boring and annoying), so I usually have several spots in the same project where work needs to be done where I switch between. What also may help is aiming for something you can show to your future users, eg in a blog. "Foo is working now!"

 

The trap where I fell into was not having an overall plan. At a birds-eye view, have an understanding of the big pieces and the core mechanics, I was focussed too much on the next thing to add. I did learn refectoring though!  :)

 

 

- How do you deal with over engineering?

I realized there is no upper limit on how complicated you can make things. You can forever add additional software layers, and extend for the future in every possible direction.

 

 

Anything you add but that you don't need however, is not progress. In fact, it's the reverse. You spend time on making the extra thing, and from now until forever you have to deal with that additional layer that doesn't help you as well, which also costs time. This starts at a level of setters and getters, and gets worse as you go up in additional layers.

 

The Python language opened my eyes for that. It doesn't have private and protected, it doesn't do getters and setters. It's terribly scary at first, but it works by using some additional rules.

 

 

- Do you think that an average programmer would do more for those 3 years?

Sorry, I have no idea what an average programmer does. It also is totally irrelevant. This is what you can achieve today. You won't get any faster or slower knowing how others can do.

 

 

What I did learn throughout the years though is that picking the right solution is 2/3 of the problem. If you make a bad choice, life is difficult and complicated. If you make a right choice, coding is simple and fast. Thinking is therefore at least as important as writing code, although the former doesn't really feel as progress, often, especially when all the solutions you come up fail due to some flaw somewhere.

 

The best solutions are often simple. For performance, aim for nice scaling of the things you expect to get really big. All other stuff is irrelevant until counter-proof exists.

 

 

- Any thing you wanna add? personal experience and suggestions.

I read that you want to make a game, yet I also read you work on a game engine. These things don't add up for me. You can work for quite a few centuries on a game engine, and still not be done with it. Make a decision here would by my suggestion. Focus what you aim for.

Edited by Alberth

Share this post


Link to post
Share on other sites

Michael Jordans, Magic Johnsons, Larry Birds, and Kobe Bryants
 

Highly unrelated, but this made me realize you can probably guess someone's rough age by have them list famous sports people and see which generation they belong to.

Share this post


Link to post
Share on other sites

So my questions are:

 - How do you handle complex task and avoid laziness and lack of motivation?
 - How do you deal with over engineering?

 - Do you think that an average programmer would do more for those 3 years?

 - Any thing you wanna add? personal experience and suggestions.

 

  1. By keeping it small so you get a sense of reward for every goal you finished. It's a long project, so having some breaks from computer (and games!) for a few days or a week could help.
     
  2. I think from the things you wrote the last 3 years you haven't really mentioned anything related to your game other than just satisfying the lust of coding.
    Why do you need D3D11/OpenGL 3+? What kind of features do you need from those graphics API? tessellation? instancing? You want the game to be Windows 7 only and above? Why do you need flexible 3D formats? Do you really have to program with various 3D format and 3D tools? Why Linux support? Are you making the game for Linux? Do you have a Linux fanbase? Your tools are only in Linux? Do you really need a world editor? Does it has to be drag-n-drop? Does it has to be C++? etc.
    If you take these questions to the smallest bit, you can calculate how big your project is, and so you know what you need to do.

    Over-engineering is like when you put ::normalize() on your Vector2D class when you don't need direction at all.

    As many others have said here many times I think, don't make an engine, make things you need for the game. Hint, in-house tools aren't always pretty. ;)
     
  3. Depends on you and your project. Could be some parts of your project are too big to handle alone. If you are making a Final Fantasy XV from scratch, you should definitely know it takes hundreds of years to build by you alone.
    I think That Dust: An Elysian Tail game, a 2D sidescroller game, using XNA framework, by an animator, takes 3.5 years to develop alone. So you can have a hint on how long your game could take.
     
  4. My opinion is your project is probably too big. If in 3 years and you ask these questions, most likely you're out of track and forgot the size of your project. If you know that the project takes 8 years then you know it will take that long. I suggest you stop coding and re-read your game design and your project goals, then redefine feasible plan from now to finish, then start developing again.

    Put small tasks with short deadlines keeps you at pace. Have someone to be your boss if it's hard for you (mentor? friend? parents? wife/husband? children?). If you already master how to be your own boss, that's even better.

    Extremely beware of ideas in the middle of your journey. Always stick with your first scope of work. if you work alone, it's reallly easy for you to fall on filling ideas every second.

Share this post


Link to post
Share on other sites

I deal with over-engineering by making games, not engines. I also deal with it by not re-writing things that other people have already written unless there is clearly something they failed to implement, and which I also need.

Share this post


Link to post
Share on other sites

I can only speak based on my own experience. I tend to overengineer the code. Especially that I find working on the tech side more fun than working on the actual gameplay. This always gets me to the point where I can't complete single game by myself because I get stuck on improving the engine. There's always something that can be done better and better. At my daily job, this problem doesn't exist due to the management and because I'm working in R&D hence, I have a lot of freedom ( and sometimes overengineering is the right thing to do ;) ). However, when I work on my own projects I tend to focus on details and instead of pushing the project forward, I get stuck on tweaking not really important things just to make it looking perfect in my eyes. Also, my motivation graph would look like a sine function :) The motivation sometimes is there, sometimes it's not. So how do I deal with it?

 

1. I'm scheduling my own tasks and deadlines - it helps to see where I am with the project.

 

2. Motivation comes mostly from the progress. No progress - no motivation to continue.

 

3. I do try to make any progress. If any of the tasks seems to be taking longer than I have planned then it's a good idea to take it on hold ( or sometimes even to abandon it ) and try something else. There's always a number of areas to work on. Switching to something else lets me breathe and very often short break gives me a new point of view on the old task ( the way: "how could I not see that?" ).

 

4. Documenting own work. Planning etc. It may sound like not necessary if you're the only person who's involved but the truth is that writing things down will let you seeing the scope of your work better. You will see bottlenecks of your solutions, you will find which corners you may cut etc. Having no plan is plays role of a demotivating factor. Always try to write down what you've done and planning to do. I simply use GitHub wiki for that ( with the Asciio tool to make ASCII diagrams etc. ).

 

5. Use GitHub tools which analyze your progress. See for example, at what times you're the most productive. See when your productiveness drops. It is a really useful tool to learn about own working patterns. For instance, I found out that I can't be productive during the weekend. Sounds crazy, right? After all, it's a free time and I should be using it for my own work. But GitHub says something else. I learnt not to plan any work for the weekend. If weekends don't work for me I don't use them. Instead, it's better to have decent relax and rest which will power me up for other times when I'm actually more productive.

 

6. Don't force yourself to do any work. If you can't concentrate just let it go. You may be experiencing a "programmer's block" ;) Then focus on something else, do not code. This is what I use my weekends for ( see 5. ).

 

I know that what works for me not necessarily will work for you, but don't stress yourself too much. Own projects always move forward with a pace of a snail :)

Edited by j_uk_dev

Share this post


Link to post
Share on other sites

While I'm at work I do not have this problem, but for some reason while I'm at home I just keep geoengineering things a lot..
 

 

 

Well, that's because no one is there to tell you that there is a deadline.

Share this post


Link to post
Share on other sites

Over-engineering appears to be cathartic to a sizable population of engineers. Making things that feel more elegant to you can be satisfying, even if it doesn't actually meaningfully improve the project.

Share this post


Link to post
Share on other sites

ImboogiBG, I'm like you. And I believe we're not the only ones (hopefully).

 

If you like what you are doing, if you want to fulfill something, even if that goes nowhere, just do it. For personal reasons, just because you'll feal far better than if you spend time watching TV instead... And if you secretly hope that you can do something with it, that you can live with this later, so continue. Even if that will never happen.

 

When you do things alone, specially now, this is not easy. And you cannot be very good for every thing. So do it your best. Don't hesitate to learn. And if some mathematics or physics look difficult, spend more time. Generally it worth's it.

 

I also have to maintain an engine, have to maintain the editor, keep all things working together... If I improve the engine, I need to make the editor to follow... If one of my dependencies change or update, I need to do it. This is a never-ending process, and that's in some way good. Because you learn all the time. Even if that's not easy, even if you can 'lose' a lot of time for something little...

 

Hope that could help.

Share this post


Link to post
Share on other sites

Thank you all for the suggestions everyone! (every opinion is still welcome)

All of you basically ask me the question that I'm asking myself: "What is your game!?" 

To be honest there is no game, I have a few ideas that fly in my head for a game, but I don't feel that any if them is the way to go for some reason(mostly because they are a rip-off of other games with(which should be OK now that I think about it, but still...)).

Probably the technologies I'm using(as said above I'm writing a general "purpose engine" in C++) are slowing me down, because there is actually no excuse why I haven't developed a prototype for any of these games.

The reason for that I think is that I really prefer to write everything myself, I know it is a stupid idea(and again at work I really don't mind using libs), as every person I like to be familiar with every line of code in my project. The good thing about writing everything yourself is the ability to "change and twist" the library. For example I cannot imagine replacing my d3d/gl wrapper with BGFX. I really do not like it, mine is theoretically better, just not as mature as BGFX...

But as asked above why supporting both d3d/gl?

Again as someone said above "just satisfying the lust of coding"... The idea is to be able to support as many platforms as I can, so I've started writing OpenGL for Linux, I was tempted to support Linux because ... hmm the reasons now sound a bit stupid but here there are:

- Eventually I want to be able to use all the valgrind and memory sanitizes (and i really doubt how often I will benefit form these, and if is going to be beneficial)

- It is a way be prepared one day for other platforms like MacOS, iOS, Andorid or even the big guys Xbox and PS, nintendos and ect - I always new that preparing for Xbox and PS4 is a stupid idea - (I actually never had any of these systems)
- for some reason I fell comfortable when my code compiles under gcc and clang

- a friend encouraged me to do so (lame...)

 

But for some reason being able to compile under Linux make me feel good, it is no longer an issue (except that I have to maintain the OpenGL port(and i really hate OpenGL).

 

Maybe I should swallow my pride and learn a new tool that will help me prototype those few games that I have in mind. I really know that this is the right thing to do, but as a programmer I want to write these myself...

 

I have to reevaluate my priorities, unfortunately I'm biased to write everything(ok not everything but...) myself in C++.
Knowing all that I feel pretty stupid.

.

 

 



 

Edited by imoogiBG

Share this post


Link to post
Share on other sites

My creative needs have led me to code my projects in, I would call it, "put aside all not vital stuff".

 

Thus I found myself quite loosing OOP code, and maximizing modular aproach.

Instead of objects being able to for example interpolate by 4 sample themselfs, I have a large library that accepts certain objects and does it for them with some function of it.

 

So I ended up with pretty tiny objects, and a big module skycraper that works with them. It seems for me that structure of my projects got much simpler and very happy to play with- factor, or try'n'see inspections.

 

Also I got much safer in memory unmanaged languages if porting such solutions.

Share this post


Link to post
Share on other sites

This topic is 480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this