If an account gets locked then you can't log in to it for 24 hours. I've forgotten the password to one of my alts and gotten it locked sooo many times because I just keep retrying the same passwords over and over again and forget to note down which ones don't work.

Some of the replies in this thread are proof that everyone is a fuckin' game development expert when they want to clown on somebody for the sake of...what? memes? being edgy/toxic/etc.? showing how "funny" you are? Take that shit to General, oh wait, it got shut down, womp womp. Go get mommy's credit card and shitpost in the Supporter Party forum if you really want to.

As others have said, asking how to make a game "for women" is probably asking the wrong question. It's kinda like asking "how do I make a popular game" because it's very vague -- there's several factors that contribute to a game having a particular demographic, and I don't think anybody really fully knows them either. Hell, I don't think anyone could've predicted that Friday Night Funkin' would be popular amongst kids - not even teens, mind you, kids - and it's probably easier to see in hindsight? But hindsight is just that, 20/20. In the moment, you can't say that your game will attract a given audience even if you attempt to target them.

That being said, it's not impossible to create a game that is geared towards women...but I'd be hesitant of the effectiveness of whatever strategies are used to do so. It's far easier to decide what type of game you want to make and then decide what you can do to market it to women more effectively. Societal and several other factors shape the end result, and as a result it's far more difficult -- but not impossible -- to make some games easier for women to play, even if you can't market them outright.

But if you want a "good chance" of targeting a primarily female audience, then you can look at Quantic Foundry's analyses on this topic for more information.

Granted that otome games are one suggestion that have been mentioned -- and it makes sense, given the success of erotic novellas like 50 Shades of Grey -- but making one doesn't guarantee a female audience for the same reason that adding a "female" character option in a game doesn't mean that only women will choose it (with probably far more men doing so instead).

Then in that case I have no idea how they manage to do it.

Apologies for necrobumping this thread, but this relevant xkcd almost perfectly encapsulates the idea behind my earlier statement:

There's a lot of problems that occur when people try to do what they need to do using Excel spreadsheets instead of a dedicated e.g. database, etc. but the point still remains: COTS (commercial off-the-shelf software) is popular because it allows you to hit the ground running as fast as possible, which sometimes can make or break a business. I'm not advocating for people to build their business around Excel, but if your program can be done trivially using it, it's probably worth some introspection: are you holding a hammer looking for nails, or are you trying to solve a problem the right way™?

Writing code and building systems yourself allows you to handle edge cases, scalability and several other factors that a "no-code" solution just won't provide, and at the end of the day, that's why those tools aren't more widely used: they don't allow for handling the complexities of the real world most of the time. But when there are clearly defined boundaries that can be handled by existing solutions, sometimes the best course of action is to just use whatever exists. That is the kind of software enlightenment that we should strive to achieve like Cueball.

Reinvent the wheel if you want for the sake of knowledge -- sometimes doing something yourself can help reinforce how it really works -- but if you don't have any need for coding (building a career, making what you desire, cooperating with others to build things that are needed, etc.) then you probably don't need to put yourself through the headache.

You could try LibreSprite's tiled mode, which I believe* allows you to create tiled patterns easily.

*I haven't used LibreSprite myself, but I believe it should be similar to Aseprite's tiled mode, since it is a FOSS fork of Aseprite.

No worries! I mentioned that bit mainly because it felt like I'd written about pass-by-value and pass-by-reference at some point in the past, but wasn't sure whether it was towards someone else or even on this site lol.

From what I recall of the last time that a similar topic came up, I believe that Geometry Dash retrieves songs from a server that the author set up. So it's not querying newgrounds directly.

Hmm...I'm not sure how the Advent Calendar game retrieved the art portal's images, but I do know that you can't stream the music from the audio portal.

Your intuition is correct! However, you need to modify the function just a little bit, to return the new calculated value:

var veggieCommence:Boolean = false;
var veggieProg:Number = 0;
var veggieTick:Number = 1;

var meatsCommence:Boolean = false;
var meatsProg:Number = 0;
var meatsTick:Number = 1;

function commenceProgress(booby:Boolean, proggy:Number, ticky:Number):Void {
  if(booby) {
    proggy += ticky;
  }
  return proggy; // returns new value if `booby == true`, else returns old value directly
}

onEnterFrame = function() {
  veggieProg = commenceProgress(veggieCommence, veggieProg, veggieTick);
  meatsProg = commenceProgress(meatsCommence, meatsProg, meatsTick);
}

This is because, like in several high-level languages, there are two different ways of passing variables - by reference and by value. Numbers (int, uint, Number in as3), strings, booleans are primitive types whereas generic objects, class instances, and most everything else is not a primitive. Primitive types are passed by value, whereas non-primitives are passed by reference.

(If you already know how pass-by-value and pass-by-reference works, feel free to skip this section)

In short, when you pass primitives, their value is copied and the copy is modified within the function. It doesn't modify the original variable that you passed into it. If you need to change the original variable, you'll have to do that manually through an assignment.

When you pass non-primitives, their value is passed directly -- that is, the function parameter holds the same variable and this allows you to change the properties of that variable and have it be reflected in the original calling function / everywhere else that variable is used. For example:

// declare an object, which is a non-primitive type in as2
var obj = { a: 1, b: 2 };
function modifyProps( someObj ) {
    someObj.a = 34;
}
trace(obj.a) // 1
modifyProps(obj)
trace(obj.a) // 34

However, note that reassigning the variable in the function doesn't change the value of the calling variable outside it. That is, you cannot do the following and expect it to work:

var obj = { a: 1, b: 2 };
function modifyObj ( someObj ) {
    someObj = { y: 5, z: 10 }; // a and be should be undefined, if this works
}
trace(obj.a) // 1
modifyObj(obj)
trace(obj.a) // 1 -- still exists!
trace(obj.y) // undefined -- does not exist!

That's because reassigning the variable someObj within the function modifyObj only causes you to modify whatever you now have assigned to that variable. The original variable still remains intact, because it is just a reference. I'm struggling to think of analogies at the moment, but there should be plenty if you search elsewhere for how pass-by-reference works.

Basically what the other replies in this thread have said, but with the added caveat that you have to find out which method works best for you. Does learning top-down (goals-based, making a game and learning on the fly), or bottom-up (fundamentals-based, making a game based on what you know) work for you better? This is something you'll have to find out through experimentation. For me, the former worked initially (because in the beginning I really wanted to make platformers and 'life simulators' apparently, looking at my submissions) but later on I just began futzing about with the engine (flash, but the point still stands) and juust moving enough out of my comfort zone to incorporate something "new" if I felt like it, or if it was necessary.

Above all, try to have fun through the process. I know it's easier said than done, but try to take joy in the little things - hell, I was proud of making a "dyno car" game (a la the kind in Need For Speed) where you literally just pressed the up key, and there was no other point to it at all. The reason I was proud of it? It "looked" 3D! Even though it wasn't! It was fucking terrible by any objective standards (and I ultimately pulled it off the portal for being too low rated lol) but I had fun building the thing, and that kept me motivated to get more familiar with the engine.

Granted, I was like 10 years old at the time, so you could've probably jangled some keys in front of me and I'd've been amazed. The point being, when you're having fun with the engine you'll find out what works best for you. And that'll make you continue pushing the bounds of your knowledge, and ultimately becoming comfortable with the engine.

In short? Try to have fun, and don't criticize your works especially at the outset. There's some ways to ignore that self-critical impulse, or riff on it outright in a fun way, but that's not the main point of this thread.

Yeah, at this point it's more or less unfortunately become something like "it is what it is". Technical interviewers like it because it's easy for them to "evaluate" a candidate, and interviewees also prefer it because it's something they can do during the interview itself -- as opposed to take-home projects which can take upwards of a week to finish in some cases -- so there's really no incentive to change the practice on either side. That still doesn't change the fact that they're IMO just glorified riddles, like asking someone how many bathtubs there are in new york city or something.

Seriously, with riddles, it becomes dead simple to answer if you've seen it before, but if you haven't then it can probably take a helluva long time to solve, if at all. And at no point does any of this have a bearing on the person's intelligence or competence, because an utter fool could look up the answer to a complex riddle and "answer" (read: parrot) it the next time around.

One example that opened my eyes to this was someone else pointing this out -- one example of an interview question (or at least, used to be) was:

• How do you detect a cycle in a linked list?

That is, suppose you had a linked list of the form

A -> B -> C <-------+
          |         |
          v         |
          D -> E -> F 

has no end (instead of stopping at F, it just keeps looping from F -> C ---> F again), how would you tell?

Feel free to think up of a solution before proceeding (assuming you don't already know the answer).

Assuming you don't already know how it works, how long did it take you to find out the solution?

One elegant (but "naive") method is Floyd's cycle-finding ("tortoise and the hare") algorithm which was first described in 1967. I don't know when it was first invented but the fact that it wasn't immediately obvious when graphs were invented, is probably enough to say that it's not something that someone can just think up on the fly unless they've seen it before. And if you've come across this problem for the first time in an interview, then you're fucked unless you're exceptionally talented and can reason through it all while facing the time pressure of an interview.

Thankfully, all hope is not lost; interviewers probably know that their interviewing methods are somewhat bogus, insofar as when a candidate doesn't know how to proceed, they can and most likely will provide hints to them. At the end of the day, what they're looking for is not whether they know the answer, but rather how they reason about it. It's still rather flawed in my opinion because that's also something you can memorize and not necessarily draw upon experience for.

In short, coding interviews like these at their extremes are the programming equivalent of a lie detector test - an innocent person most likely passes one, but sometimes they can fail them as well. Liars may fail them, but they can also be trained to "pass" them, and a lot of the time the person conducting the test is just looking for signs that hint to whether they're lying or not -- there's nothing concrete at the end of the day.

So if you have a case where people train exclusively to pass these lie detector tests, you really only filter out the ones who are just so terrible that they can't meet that bar, along with those who also are just terrible at test taking, even if they are wonderful in all other aspects of the task.

But I'm sure that there'll be others who insist that it's a great way of interviewing people, and they may very well be right, I don't know. Maybe I might change my tune once I start interviewing others. Maybe there really are so many candidates who just can't meet the minimum bar for being considered anywhere near a "competent" developer. Maybe all those horror stories of people not even knowing what a variable is are true. I don't know.

As for system design, it's mainly for when you're in the middle of your career, or are looking to progress as a senior -- I don't think it's typically asked at the new grad level. I need to learn how to (I suspect I already have some idea of it through exposure, but I haven't formalized it myself) too, and there's plenty of books and resources on how to do that. If you're just starting off in your career, I don't think it's necessary to learn, but it's never a bad idea to know either.

Here's one such resource, if you are interested. I don't think Anki's the best way to start learning something, but it sure is (among) the best for retaining knowledge.

No worries!

Practically speaking, if your web server is too slow, then either scale horizontally or vertically. Most of the time you don't need to rewrite your code to use a different web server because people smarter than you and I long figured out how to do it the "best" way already.

But who gives a fuck about that! Pragmatism stifles creativity; if you want to create your own web server entirely using a custom userland TCP/IP stack, then go nuts! It's how we got TempleOS, SerenityOS and other such stuff that'll in all reality never see practical use, but are worth appreciating in their own right, after all.

I assume codewars is a competitive programming site like project euler, leetcode and such? It's definitely helpful for brushing up on the fundamentals -- especially since they require you to place a lot of emphasis on performance -- but they don't accurately represent the complexities that come with building (and more importantly, maintaining) projects. Quite often you can fall into the pit of "this code is fuckin ugly but it's faster than the elegant method so screw it". I don't think it'll come back to bite you later since you'll be aware of those occasions, but it certainly wouldn't help you build good habits in those lines either.

(There's a long rant to be had about how hiring interviews use competitive programming questions as the basis to judge how good a candidate's technical ability is, but that's a rant to be had for another day...)

In short, working on projects is probably a more realistic representation of the type of work that you'll be doing on a day to day basis (give or take, given the scale of the project you work on at the workplace) than competitive programming, which could maybe train you to focus on microbenchmarks and performance rather than maintainability and organization.

But this isn't an either/or, in practice. Competitive programming takes far less time than working on a project. If it keeps you motivated to continue programming for practice, then by all means go ahead. I ought to get back to competitive programming again, because projects just take way too long for way too little payoff. Meanwhile, the instant gratification of solving a competitive programming question is admittedly, now that I think about it, an allure that's a little hard to resist.

Addendum: I think this is probably a moot point, but beyond a certain stage in one's career, creating (and more importantly, grokking an existing) system design becomes (or should become) more important than raw coding skill. That's not really a skill that competitive programming can provide, but that doesn't mean that projects automatically do either. Most personal projects never reach the sort of scales that require intense knowledge of system design, so it's tempting to take the "easy route" out where possible. Studying system design is probably another activity altogether which I'm not sure where to place.

Working on open source projects that are already to some extent "big" are probably your next best bet, but -- at least to me -- it's so dang demotivating to try and contribute to an open source project when 1) it's a huge complex beast of a codebase and 2) your fixes may or may not ever see the light of day. For better or for worse, I have things I find more interesting these days than to work on a large project -- smaller ones are where it's at for me.

Remake a (small) game that you played in the past. This could be something classic ranging from Tetris to something like a short point-n'-click (e.g. Submachine) or even an RPG (although this would be on the "intermediate" or "hard" end of the spectrum)

Don't bother spending time on assets; since you're recreating the game, you might as well rip the assets or just use placeholder ones instead. (Don't publish the game, obviously)

Probably not Full Sail, they have had quite a bad reputation in the past for being overpriced, overspecialized, overintensive and not fully accredited (so transferring credits would be a major pain in the ass if not impossible). Perhaps things might've changed since then, but if there are any alternatives, perhaps prefer those first.

A couple changes/suggestions/questions I noticed...

var depth:int = Math.floor(obj.y);

Calling Math.floor() on something that'll anyways be stored as an int is probably unnecessary; since calling static methods is slow, best avoid it unless there's a good reason to.

I guess you're implementing this as a function that can be called by any movieclip that you want to be stacked by Y? That is, if you have 3 objects that need to be stacked by Y, then they should all have DepthY somewhere in the inheritance chain (e.g. X extends DepthY)?

If that's the case, it's probably much better to make the parent container manage its children rather than have the children manage themselves. This way, rather than calling updateDepths once per object in the container, it can be called just once -- by the parent container.

That's not to say that you can't have the child movieclips manage themselves -- it's possible to have your cake here and eat it too. By adding a custom Event listener (e.g. "REARRANGE" or something) to the parent container, you can have the child movieclips dispatch these events whenever they move, for example. Then, the parent container will call updateDepths in the next ENTER_FRAME (and immediately remove the ENTER_FRAME listener so that it doesn't need to be called when nothing's changed).

The benefit of this method is that even if there are 200 objects in the parent container, you'll only call updateDepths once, because all the REARRANGE event would do is to tell the container to eventually call updateDepths. Furthermore, you'll be achieving the same outcome in a more modular manner - you won't be bound to inheriting from DepthY in this case - so it'll work even with e.g. Sprite or Shape derived objects (although for the latter you'll have to create an EventDispatcher instance since Shape doesn't have one by itself).

The downside is that each of the downstream classes (e.g. asClass) will need to have code to dispatch the REARRANGE event, but I don't really see how that's too different from the current method, as you will anyways need to know when to update the depths.

The only reason I use AS2 these days (if I do) is because I want to make something that is compatible with ruffle. The moment ruffle support for AS3 is full, I'm ditching AS2 ASAP. I don't have any legacy projects in it that I still maintain, and AS3 is superior in all regards. Back in the day I used AS2 because I didn't feel like transitioning to AS3, but once I did, my god did working with AS2 feel like pulling teeth.

You'll need to:

1. set a flag (e.g. running) to true if the player is pressing either the left or the right key
2. if the running flag is true, and if the space key is pressed, then play the animation (i.e. go to a frame)
3. if and only if the above conditions are not satisfied, then check whether the left/right/space key is pressed and play the animation for those keys respectively.

I didn't know that universities offered courses on esports until I looked it up just now. It appears that this is indeed a thing? But it seems to (understandably) focus on the business side of esports -- such as managing a team and such. It's most likely not going to teach you how to git gud at league lol

But as to your question, I don't know which universities would be considered "good" for this sort of thing, especially since it sounds rather new. Feel free to look at the link above, or ask Bing Chat for more information, but these seem to be more about degrees in esports management rather than individual courses, so I wouldn't necessarily take stock in them. Not to mention that specialized degrees are a great way for you to pigeonhole yourself unnecessarily - a business based degree at one of those universities with an elective in esports might be a better choice, if they offer that.

In my opinion, though, I don't think I'd pick any colleges that offer esports programs...way I see it, offering a "new" or "unique" degree program is one way that subpar universities attempt to stand out from the rest, so by dint of having the degree program being offered, calling it "good" might be an oxymoron.

It's been a helluva long time since I used DVDs, but IIRC DVD-R discs are writable only once, and become readonly after that point. DVD-RW disks are usually rewritable.

In the past I used Nero, or CyberLink PowerDVD to burn discs. Not sure if they still offer those or not. There's bound to be some FOSS or otherwise free variant available with some searching too (for example, InfraRecorder...but that was last updated in 2011 or thereabouts, so not sure if it still works or not).

I guess you may be able to try your luck with extracting them as an archive and seeing what happens, I haven't tried doing that for Flash 8/MX formats so far.

I don't know much about reverse engineering, I've tried my hand at it for some game saves I had and I just about gave up because it's so tedious. You could try taking a blank FLA, analysing it, then add an image, and compare it with the blank version and see what changes. But if the entire thing is encoded in such a way that small changes are reflected through the whole file (e.g. with some basic cipher) then you're probably SOL unless you try and decompile the Flash executable itself. At that point shit becomes way too complicated.

I had to do the same thing even in uni for some tests. It was stupid and it absolutely won't work these days for anything other than simple, scope-limited programs, but it forces you to plan things out correctly.

Or at the very least, to bring your own pencil and eraser.

From what I understand, it's the latter -- drawing everything from scratch

You might find some more information here:

binary - Is there an unofficial Flash .FLA spec? - Stack Overflow

The FLA format | benjaminwolsey.de (archive.org)

Unfortunately, the older versions are pretty much closed formats. If you want to create CS5+ files, those are much easier as it's basically a zip file.

Indeed. When I was briefly trying something out for the flash forward jam a couple years ago, I was using a lot of huge vectors in my prototype, and it was basically as fast as blitting (because my guess is that's what Ruffle was doing under the hood).

Kids these days have it so easy. now get off my lawn!

Holy shit what the fuck. This came out of nowhere. I used to talk quite a bit with him in the past (at least, until a year or two ago). Can't say we always saw eye to eye but this is fucking terrible, RIP

Indeed. I think this was also what I did before making the plunge to FlashDevelop. Roughly, the transition in my experience was:

Timeline scripting for several frames -> Only one frame, timeline scripting on that frame + classes -> No code on any timelines, just use the Document Class feature to add all code -> Use FlashDevelop. It helped that I switched completely from vector-based graphics to using blitting because it was too slow to use vectors, the rest came naturally thereafter (because I could just blit onto empty Sprites using code, instead of Symbols in the timeline)

I switched from Flash CS to FlashDevelop ages ago and it's legit the best decision I could make, because although Flash CS is very convenient, it can force you into non-standard programming patterns (e.g. timeline scripting).

They don't call it a programming language for nothing. It's nowhere near as complex as human language but they share similar problems, and often with similar solutions.

1. For example...tons of people never learn how to speak because they feel scared or embarrassed about others misunderstanding them, or the words not coming to their mind. Likewise, quite a few people I used to tutor in the past were afraid of having the compiler blow up on them, and would either utterly shut down when a compiler error occurred -- to the point that even if the exact location of the error and the fix for it was written in the compiler error, they'd still ignore it and pretend the error was unsolvable.
2. People also forget words all the time...as do programmers, who forget syntax of languages they haven't used in a while. Thankfully, since programming is never real-time unlike language (well...unless you need to stop someone from hacking your public firewall) you can always look things up at leisure.
3. Leave things like design patterns and all that jazz for much later. Someone learning basic greetings in English doesn't need to be able to -- nor is expected to -- dish out tomes full of complex prose. Similarly, your one-man project doesn't need to become Enterprise™ ready. That said, you should eventually (and I really do mean eventually, like years later) be aware of it, and maybe even look it up.
4. Not all languages are the same difficulty, and programming languages are no exception. As mentioned in the original post, you may find some languages just vibe with you better than others -- although Scratch is (these days) commonly suggested because it's visual and so it doesn't require you to learn text-based syntax, in my experience I've never had success with those, and AS2 was where I was first able to work with it long-term. And I've tried a helluva lot of languages in the past...CeeBot, ALICE, fucking Phrogram anyone? The good news is that unlike human languages, most programming languages are more or less the same under the hood -- think less English vs French and more American vs British english. Once you've learnt a given language, it becomes muuuch easier to jump to another one, oftentimes the differences (on surface level at least) being syntax alone. This is why starting from Scratch and moving to text-based programming languages makes sense, but at the same time, don't be discouraged if Scratch doesn't work for you. Pick another one and try that, you may find it works for you. Even if it's some relatively esoteric engine-bound language like ShiVaScript, it's still going to be close enough to another language that you can branch off eventually.

---

Lastly, when it comes to learning something -- be it a language, a game or any dang skill -- you've got to love it or need it. The ideal situation for learning how to code is if you want to do something with the coding skills you acquire -- be it making a game, or kickstarting a career. Or if you're in a CS program and you need to learn how to in order to do an assignment, or in a bootcamp that you need to pass, or you're being paid by an employer to learn X language to work on Y project. You need to learn; there's no option not to. Well, not without consequences anyways. Money tends to be a big motivator for many for a reason.

On the other hand, if you're doing it as a hobby, and you don't yet have anything to work on while you learn how to code, or if you're learning how to code because you want to be able to use it at some point in the future, then you've really got to want to learn how to code, and put in the time and effort in order to do so even when the going gets tough. Especially when it gets tough.

And if you don't have any tasks that would benefit from being automated, any ideas being actualized with code, and if everything that exists (programs, games, whatever) currently is more than sufficient for your purposes, wants, desires...

...then why learn how to code?

You need a server to synchronize all of the players, and then the trouble only increases from there.

Multiplayer games are hell.