What I Would Suggest to Another New Developer Like Myself

  • To start, this is from personal experience and if you disagree please let me know why! Curious as to what others think, as this is coming fro little experience but just what I've found.

    Basically my suggestion is that you start with a slower paced game. I feel like fast games are much harder to design well, moving smoothly and having the right flow. First, lets take lag for an example. Someone new to scripting may not know the most efficient way to do things. For a slower game, this isn't the best, but it seems as though this isn't as big of a deal as it is in a fast game. In a faster game, if people experience even a little bit of lag, that could be the difference between winning or losing, or maybe life or death in the game. A faster game also often has more moving parts, which again may not be a big deal for someone whos experienced, but for someone new who may not know how to do everything in the most efficient way, it can make a big difference.

    On top of normal lag making a big difference, pacing of the game is also so important. For a fast game, you have to make sure you design it so people stay intrigued, and have to make sure people's attention aren't lost. In slower games, this can still be an issue. However the expectation of a fast game isn't there, which in my opinion makes this issue more lenient with the slower games.

    So like I said you may totally disagree with me on this, but this is just what I've found so far with my little bit of experience. Thoughts?

  • @ari462

    Someone new to scripting may not know the most efficient way to do things.

    Pretty subjective imo, and are you seriously going to benchmark every single thing you do just to get the better result. Also why should a beginner be worrying about efficiency in the beginning of the development process. This is to be dealt with afterwards. Letting efficiencies and performances decide how you should be programming before is premature optimization.

    "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
    - Donald Knuth

Log in to reply

Looks like your connection to Scripting Helpers was lost, please wait while we try to reconnect.