You are currently viewing our site as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today!

If you have any problems with the registration process or your account login, please contact contact us.

Fan GamesA forum for discussion of any demos and fan games being made.
Not for discussion of Modifications.

Small exclusive update here to check if anybody reading my posts So we are almost month after TD2. I cannot say that everything going as I want: Game is still not working, I finding more issues with my existing stuff, I'm also getting somehow tired and on top of that I was half week sick. So I lost some of my precious time.

From good news I'm healthy again, have more than 500 test to validate that everything works fine and will work in future. Finally stuff I do moving forward.

The last point should be soon visible because on top of improving management of map I also improved rendering of sea and now I working on new better terrain system. But this are just biggest point from stuff I done. There is really a lot of smaller ones I do here and there in meantime.

I know that all of this are just words and for now I don't have too much to support this but hey I'm working on this alone ... and for free.

Well kind of yes :P but generally I think it is worth it. I know that this logic may not holding together to well right now but I believe that soon it should become more clear where I going with all this changes.

Nice write up. You must be spending so much time on this project... Not to mention writing your blog on top of it.
Kudos on all that hard work!

What you’re saying about complexity is interesting. It’s a subject I’ve been thinking about for quite a few years. Particularly the difference between inherent and accidental complexity, and how accidental complexity hurts so many software projects, and makes the experience of writing software painful sometimes.

Thanks, it taking some time :/ generally I don't want to count how bit part of my life I spend on this project.

Quote:

Originally Posted by Lupin

What you’re saying about complexity is interesting. It’s a subject I’ve been thinking about for quite a few years. Particularly the difference between inherent and accidental complexity, and how accidental complexity hurts so many software projects, and makes the experience of writing software painful sometimes.

I also think that this is really interesting problem and I don't know if you will agree with me but we are really not prepare for.

In theory universities should be place where we should learn how to work with projects. But most of projects are like half year and most of the time they started from scratch and are relatively small. Then you end in company where you work on stuff that are developed for the years by multiple people. Most of the time each project have it own variation of ways how to dealing with this complexity. They may exist better but we use stuff we know and that is why I think we should discuss not only achievements but problems so we could share/find solutions that works better.

When you work on project longer I don't think you can avoid complexity. I can even claim that complexity is not something bad and it is needed if you want to do more advance stuff. Problem is that we expand code and then worrying about it negative effects somewhere in future. Then it is really sometimes hard fix stuff that are already broken.

That is why I try all kind of improvement to my workflow: More modularised code, easy to use stuff that often hide complex problems beneath that you don't necessarily need to know about when you use it, testing and generally designing everything. This is not only because I wanted this way, I doing it because I don't have choice. I wouldn't be able to get so far without it.

Thanks, it taking some time :/ generally I don't want to count how bit part of my life I spend on this project.

I also think that this is really interesting problem and I don't know if you will agree with me but we are really not prepare for.

In theory universities should be place where we should learn how to work with projects. But most of projects are like half year and most of the time they started from scratch and are relatively small. Then you end in company where you work on stuff that are developed for the years by multiple people. Most of the time each project have it own variation of ways how to dealing with this complexity. They may exist better but we use stuff we know and that is why I think we should discuss not only achievements but problems so we could share/find solutions that works better.

When you work on project longer I don't think you can avoid complexity. I can even claim that complexity is not something bad and it is needed if you want to do more advance stuff. Problem is that we expand code and then worrying about it negative effects somewhere in future. Then it is really sometimes hard fix stuff that are already broken.

That is why I try all kind of improvement to my workflow: More modularised code, easy to use stuff that often hide complex problems beneath that you don't necessarily need to know about when you use it, testing and generally designing everything. This is not only because I wanted this way, I doing it because I don't have choice. I wouldn't be able to get so far without it.

Oh, I agree that people are usually not well prepared to deal with the kind of complexity that comes with large scale projects. I think it’s even worse than that, most programmers never actually ever learn to deal with it efficiently.

People learn to mitigate things, and postpone the moment where it becomes overwhelming, but OOP modularization and design patterns only take you this far until hidden exponential complexity catches you up and burns you out.

I think most large software project actually either fail or end up being big piles of unmanageable code full of bugs and incapable of growing any larger/better after a certain point.

My recipe for dealing with it in the past few years (both in my day job and on our LBA2 reimplementation project) has been to look at alternative programming paradigms, functional programming in particular, instead of the dominant OOP / imperative religion. It’s proven quite efficient in reducing tight-coupling and unfathomable program state interdependencies. I’m not saying it’s a silver bullet, but it’s been a great help in thinking about things differently and avoid many headaches.

I’m pretty happy with the code on the LBA2 remake project, the complexity is pretty much kept local and doesn’t compound into an unworkable mess.

Refactoring early and often helps a lot too. Initial designs are inevitably proven wrong by confrontation with reality (assuming you actually have a design, some programmers don’t even go through that phase). So it’s a healthy habit to redesign as soon as you notice there’s a mismatch between intended design and actual code.

I checked the links and in my opinion this getting really low level programming stuff. This is in my experience most cleanest part of most codebases. Thing starting messy higher when all this "religion" take place (f.ex:OOP, programming patterns believers).

I think to get pass this mess we first need to understand two things : "use tools that fit your needs" and "There is no tools that are for everything". C++ have it's place just like C#, Python, Perl, Java or functional programming languages. Don't force language to do stuff that they are not made for (not talking about project where this is whole purpose of it).

When you understand this you need to learn that inspiration can be found anywhere. I personally using Micro Kernel Operating Systems as reference to build structure of my engine. I really like Black Berry OS design and using few concept from it (https://developer.blackberry.com/nat...hitecture.html). Other things I love to do is talking about my problems with people which not necessarily share exactly the same area of interest.

f.ex. I found recently pretty big issue with resource system. I couldn't figure out way to fix it nicely. But then one of my programmer friend that never wrote any game engine gave me answer to this complex problem in 15 min. I couldn't imagine that I didn't thought about it myself but I didn't and he did.

That is why I thing in coding being open on unknown, always searching for new way of solving complex problem and finding source of inspiration is great. Often then you start noticing that the same complex problem approached from different perspective may be trivial. Sadly experimenting with stuff create some inconsistency in code. Then I fully agree with you:

Quote:

Originally Posted by Lupin

Refactoring early and often helps a lot too. Initial designs are inevitably proven wrong by confrontation with reality (assuming you actually have a design, some programmers don’t even go through that phase). So it’s a healthy habit to redesign as soon as you notice there’s a mismatch between intended design and actual code.

This is just sometimes needed to preserve your sanity. Sadly in some companies there is just no time to some of stuff we talk about or just any of them. You need to ship product and this resulting in:

Quote:

Originally Posted by Lupin

People learn to mitigate things, and postpone the moment where it becomes overwhelming, but OOP modularization and design patterns only take you this far until hidden exponential complexity catches you up and burns you out.

Experienced people try to avoid this early on but here come question what really mean: experienced? I wouldn't call this myself. I have some experience but it is limited and there still plenty of things that I would love to learn about.

It took me some time to came out with what you seen. This is not easy task to do something that look more modern and still work with L.B.A. :/

This is in the fact interesting topic that when I'm working on remaking original content I'm often "limited" by original game :/ Any of you there that drawing or 3d modeling have similar problem or this is just me?

Oh yeah, for sure it's always been an issue. My approach was always to look at the concept art, and what they tried to achieve, but where too limited to do, look at what their inspirations where, and try to extrapolate from that with modern techniques.

I doing the same but even the concept arts were pretty simple because they knew limitation. Extrapolation didn't worked for me so well also :/ still landing to close to retro look of original game.

Recently I try different approach where I try to make stuff that have LBA mood and make you feel like they belong to this universe but they are kind of loosely connected to it's original counterparts. I doing this because otherwise I cannot escape this old game feel of stuff.

Wow, that artwork looks great.
I'm impressed at how you manage to be skilled both at drawing and programming at the same time, those require really different skillsets. I wish I could draw like you do.

About the article: well, you managed to keep steadily working on this for so many years, so I guess those doubts are not such a big problem. I think it's healthy to have doubts, as long as they don't stop you.

I know it's a popular thing to say these days: "Use an existing game engine and ship a complete game instead of endlessly working on your own unfinished game engine", but I think it's important that at least some people do roll their own (ok, I admit I'm saying this partly because I follow a similar approach on my own project), game development is a creative process, and if we all settled for established solutions, creativity would suffer. As long as you learn something and enjoy the process, I think it's worth pursuing those efforts.

Thanks but this is tries and errors + having friend who is artist and have time to give you some tips what you do wrong. Rest is just time and not giving up.

Regards technology I think this is depend what you want. If this is game then I wouldn't go into tech because there is a lot of extra works which is not interesting to everybody and when people say:

"Use an existing game engine and ship a complete game instead of endlessly working on your own unfinished game engine"

They don't mentioning that shipping complete game is really challenging. Using existing game engine will not guaranty that this will happen but it will help a lot. Look at it as tool which is use in crafting. Good one can help you a lot but without skills and persistence you may never create piece of art.