Is your complex gamemode keeping you up at night w/ maintenance?
#1

Put everything pawn/samp related down, right now, and walk away from it for 4 years*. After that come back, and look at your shit....MY GAWD. So so so many terrible mistakes, idiotic timer/loop voodoo, and hacking of INCLUDE FILES to make your stuff work.

If you have a bunch of timers, you are doing it wrong. If you get it in your head to combine all of those little timers into one-big timer, and you don't even consider looking at what your new timer has to put up with and trim stuff back accordingly...you're doing it wrong.

If you have to severely hack includes to make your script compile, if you need to cast spells on your script to get it to run right in a production instance...just stop. Walk away for just a week even and see what happens. It could be good medicine for your script...coming back w/ a clear mind and fresh eyes and all that.

Just my opinion






*Okay maybe you don't have to walk away for THAT long...
Reply
#2

This is why coding cleanly and efficiently is important and why it should be stressed so much to people who are creating big gamemodes with big aspirations of keeping it going for a long time. The more you code inefficiently, the messier it gets and eventually it's going to be impossible to keep up with all of it.

It also is a good idea to put some comments in there if you plan on stopping the process of committing code to your project for a while, so you can remember why you put something where you did and what it means.

That also ties into using proper naming methodology and being consistent in your naming conventions.

When you have enough experience you'll be able to spot inefficiently quite swiftly and if you're thinking to yourself "there must be a better way of doing this", there probably is.
Reply
#3

Alright then... I will walk away for 4 years because I can't get my npc's to stop walking through buildings '-' .

:P screw that, maybe one more night
Reply
#4

Quote:
Originally Posted by JaTochNietDan
View Post
This is why coding cleanly and efficiently is important and why it should be stressed so much to people who are creating big gamemodes with big aspirations of keeping it going for a long time. The more you code inefficiently, the messier it gets and eventually it's going to be impossible to keep up with all of it.

It also is a good idea to put some comments in there if you plan on stopping the process of committing code to your project for a while, so you can remember why you put something where you did and what it means.

That also ties into using proper naming methodology and being consistent in your naming conventions.

When you have enough experience you'll be able to spot inefficiently quite swiftly and if you're thinking to yourself "there must be a better way of doing this", there probably is.
^^THIS!!!!
Reply
#5

I generally write hacky code to get something working, then optimise the hell out of it. If I try to do something nice and maintainable the first time, I find myself taking much longer to get a result (no fun there), and skipping the optimisation step, which is probably still necessary once the code is actually functional.

IMO:
1. Get it working.
2. Optimise.
3. Prettify.
Reply
#6

You forgot 4: KEEP it working
Reply
#7

Quote:
Originally Posted by spookie
View Post
I generally write hacky code to get something working, then optimise the hell out of it. If I try to do something nice and maintainable the first time, I find myself taking much longer to get a result (no fun there), and skipping the optimisation step, which is probably still necessary once the code is actually functional.

IMO:
1. Get it working.
2. Optimise.
3. Prettify.
That doesn't work too well in my experience most of the time. The issue with that is in the past I would've tended to just say ah well, I'll move on and optimize it later. Then that stuff builds up swiftly.

I tend to plan ahead myself these days though and optimize as I'm going along rather than get it working first, I personally find it easier and more efficient instead of going back. I like to spend a lot of time thinking before actually doing it, making a plan in my head of how I'm going to do it.
Reply
#8

Welcome back.

I looked back at a GM I started working on in 2008, holy mother of god it's all over the place!
Reply
#9

Quote:
Originally Posted by Y_Less
Посмотреть сообщение
You could PLAN AHEAD! Instead of using a whole throw-away implementation of your mode to get your head around what you want and what the mode will do - write it down and plan it out. Much simpler.

And DO make sure you comment, even if you are the only scripter. YSI is full of comments now and I still struggle to work out what some bits do...
Cause I'm boss
Reply
#10

Seriously?

What is all this "Get the code working, then optimize it?"

1. If your coding a script blindly, you need to start from scratch, because efficiency is structural.
2. Why would you code something, then hesitate to optimize it?(Which should be part of the the 1st step?)
3. You get to a stage where, your imagination is the limit, why are you guys making it sound so hard? that you have to hesitate to FINISH the code?

-.-
Reply
#11

Scripting everything 100% efficiently the first time is generally more difficult than coding the basic structure then building on it.
Reply
#12

Quote:
Originally Posted by MP2
Посмотреть сообщение
Scripting everything 100% efficiently the first time is generally more difficult than coding the basic structure then building on it.
Please explain how?

pawn coding samp servers is pretty simple, your making it sound like it takes months to code something, when infact it can take you a couple of lines and a few minutes, if your not optimizing you code as your coding it, you wasting your time, why double handle code?
Reply
#13

I suggest you read this paper by one of the most respected computer scientists in the WORLD::

http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf

This is the source of the very famous quote:

Quote:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

And coding a mode from scratch is the WORST way to optimise! I say this over and over and over again - use libraries! They tend to be written by people with more knowledge in a small area than you and are probably better written that you could do quickly because they've spent more time on them. You write some "OnPlayerEnterArea" code and you make the loop very small and very fast. Then you look and find that a library for this has ten times more code than yours does, yet runs ten times faster because the implementor used an entirely different algorithm. THAT is where speedups come from! Not using "++" instead of "+=1" on some lines - that's a trivial optimisation and frankly I'm ashamed that I ever wrote my large topic on code optimisations as I had no idea what I was on about back then for promoting those sorts of "optimisations".

Consider this code to count the number of bits set in a cell:

pawn Код:
new count = 0;
for (new i = 0; i != 32; ++i)
{
    if (input & (1 << i)) count += 1;
}
You could "optimise" this using the methods most people use:

pawn Код:
new count = 0;
for (new i = 1; i; i <<= 1)
{
    if (input & i) ++count;
}
And people will tell you that their code is better, and produce extensive timing results to prove it, and they're probably right - that still takes 32 loops to complete, but is 0.1% faster so their code is better and they just spent 2 mintues saving 0.000001ms run time! Or you can use a better ALGORITHM:

pawn Код:
input = input - ((input >>> 1) & 0x55555555);
input = (input & 0x33333333) + ((input >>> 2) & 0x33333333);
new count = ((input + (input >>> 4) & 0xF0F0F0F) * 0x1010101) >>> 24;
I'm not going to explain this, but it's vastly faster (if you want the technical terminology, it's O(1), not O(N)).

But you wouldn't know those sorts of things without extensive research that you just don't have time to do for one small part of your mode. But again, when someone writes a library, that IS their focus and what they research, hence why they can be better (when they are well written anyway, some just suck).

Edit: Changed a statement about "O(log N)" to the correct "O(1)".
Reply
#14

Quote:
Originally Posted by MP2
Посмотреть сообщение
Scripting everything 100% efficiently the first time is generally more difficult than coding the basic structure then building on it.
So true. I have one large function - about 300 lines - which shows different textdraws depending on the 6 parameters. I had to revise it numerous times before I was satisfied with the result.

And Y_Less: I blatantly refuse to use lots of different libraries together. They're all coded in a different scripting style, and finding a mistake in one of these may be very hard. I may be stubborn if I want to start from scratch, but at least I have full control over MY code and I won't have to worry about copyright, credits and stuff. I consider myself experienced enough to write efficient functions. Yes, I know it takes longer, but frankly I don't care.
Reply
#15

Quote:
Originally Posted by Vince
Посмотреть сообщение
So true. I have one large function - about 300 lines - which shows different textdraws depending on the 6 parameters. I had to revise it numerous times before I was satisfied with the result.

And Y_Less: I blatantly refuse to use lots of different libraries together. They're all coded in a different scripting style, and finding a mistake in one of these may be very hard. I may be stubborn if I want to start from scratch, but at least I have full control over MY code and I won't have to worry about copyright, credits and stuff. I consider myself experienced enough to write efficient functions. Yes, I know it takes longer, but frankly I don't care.
Which is exactly why I wrote YSI (lots of different libraries in the same style) and released it under MPL (so you can use it without worry of credits etc). And as I say, it's not about experience, it's about focus - yes anyone CAN write all that code, but I truly don't understand why you would want to spend months writing and debugging a user system when you could download one and move on to writing and debugging your amazing unique server feature. This is where most servers fall down - they have some amazing idea (at least they think they do) but never implement it because they spend months re-implementing things that have been done hundreds of times before for no good reason...
Reply
#16

Quote:
Originally Posted by warcodes_
Посмотреть сообщение
Please explain how?

pawn coding samp servers is pretty simple, your making it sound like it takes months to code something, when infact it can take you a couple of lines and a few minutes, if your not optimizing you code as your coding it, you wasting your time, why double handle code?
Well sometimes when you do the basics you can have a better understanding of what parts will be re-used, sometimes (often for me) it'll be things you overlooked in the planning stages.
Also doing basics first allows a better understanding of how your plan will turn out and will allow you to change things around without too much effort or time consumption.

This really reminds me of doing art when I was younger, I use to be focused on detailing as I drew and would often draw all the detail in as I went along and by the time I'd finish I'd realize I've done some parts too large or small and then the whole drawing would be ruined, yes individually different parts of the drawing might be really well done but over all it would be bad.
Then I learned to draw basics first, the general size of a head, the position of the eyes, the length of the eyes, and once all the basics were in I'd then go into detailing and the pictures would turn out much better.
Reply
#17

No, not really. (Topic title)

I tend to try to code things as efficiently as possible the first time around. Although that statement makes it seem like everything I code is 100% optimized, that's just not the truth. I really don't think half an MS of runtime really makes THAT big of a difference. If I'm wrong, feel free to correct me.

Besides, this is the internet. There's new innovations all the time. People figuring out how to further optimize things, trying to bring about a new age of development. That's just how it works.
Reply
#18

well I kinda agree with you y_less, using libraries is important
But sometimes these libraries are too complex, and when something mess's up
we cant fix them/our code as we really not sure how this library works.

I was making a mode from scratch using some libraries, YSI was one of them,
I ran into trouble in that mode for a few reasons,
I'm not experienced enough yet with PAWN,
I'm not experienced enough yet with YSI,

So for me remaking my user system to use sqlite instead of uvars
helped me keep control of my saving/loading. But I still use a large portion of YSI,
I know uvars should be auto saving, but I somehow broke them.

I always try to think about what I'm gonna write before i write it.
I make a text file with as many details as I think I want and try to
keep crossing off my list until its empty.

Once I have my system I go back over it looking for more efficient ways
to code that portion. I generally write more code than I need and have to off some of it,
but thats just the way it is.

I also spend allot of time just formatting my code so I can understand it better.
I do try to write it in a nice format so that I dont have to go back over every line
to make it pretty.

But I spend the most time reading/researching like y_less said,
It might take a hole day of reading to improve a small section of code.

And then I find a better way and redo it again!
Its very slow for me. I'm used to oop languages which
is allot easier to keep clean and neat.


What I don't try todo is make code in 5 mins and release it,
that is the worst! and worthless!

I sometimes see Game modes that say, Made in 5 mins..
And these people expect me to download that? NEVER.

I can tell you in 5 mins I haven't even typed 1 line of code,
I'm still brain storming and drinking my coffee. I brainstorm even when not at my keyboard,
This is where most of my ideas come up, when i cant write them down and end up forgetting some of them.

anyways I could go on and on here (IM a long winded person)
but Im off to work guys!
Reply
#19

Another good way of keeping code manageable is keeping different systems in different files, and calling them from the main script.

For example if you have a race system and a game system in your mode, I think it's much better to give the race and game system their own file (.inc) And just call the functions from the GM. That way when it comes to finding and killing bugs you know where to look. Instead of looking through a 10k+ lines GM to find a bug in the race system. In the GM I've been writing i have about 20 includes (designed for the GM nothing else) and i have to say that is much more manageable than having it all in one file. Makes maintenance a lot easier too. I do also use other peoples libs too.
Reply
#20

Quote:
Originally Posted by iggy1
Посмотреть сообщение
Another good way of keeping code manageable is keeping different systems in different files, and calling them from the main script.
This. People tend to create every single piece of code into the gamemode. Which is making it harder to maintain
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)