Game Maker uses its own language. There is some appeal to trying a thing that could apply to more than one engine. My work also deals with alot of PHP and Javascript (I'm not a dev, so I dont deal with it directly) but I want to start gaining skills that help me perceive what's happening in our code.
So, I guess I need to break down "personality test" into its different, logical problems, and then try to find how to do that in C# or Java?
Yeah, then I say C#, because it, PHP and Javascript all have syntax derived from ye olde C. Code will look very very similar in all three.
edit: bowen is correct in that javascript does things differently, though.
For you vagrant users, how do you deal with SSH inside your VM? Do you have a vagrant provisioning step that pulls in your .ssh directory? Do you plop it in manually? Do you exit the VM to push from host?
I was tending toward the provision step pulling .ssh from the host to the VM, but I can imagine that if someone outside the immediate team of 2 tried to use it, they'd be upset at their SSH keys getting copied.
Game Maker uses its own language. There is some appeal to trying a thing that could apply to more than one engine. My work also deals with alot of PHP and Javascript (I'm not a dev, so I dont deal with it directly) but I want to start gaining skills that help me perceive what's happening in our code.
So, I guess I need to break down "personality test" into its different, logical problems, and then try to find how to do that in C# or Java?
Java and Javascript are different though, so keep that in mind!
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Policheck is dumb as bricks. Dumb as bricks. For example, the word "entities"? More like "en***ies". It will also do things like flag substrings in hashes or flag curse words in open source dependencies that you have no control over.
Oh, this reminds me of a story of a former coworker.
My division was a startup back in the early to mid 2000s before it got acquired a few months after I started working here a few years back and like many startups a large chunk of the code base was created by one very talented engineer working late into the night fueled by caffeine and a sardonic sense of humor. My division's software reads in analyzes what are often non-standardized documents from the client which means that we've needed a variety of methods to escape or scrub control characters from what we frequently get that would mess up parsing of the data. More on that in a bit.
One of our QA engineers that was hired about a year into my tenure was a middle aged woman who had grown up in Pakistan. She ultimately didn't work out as we need a pretty significant set of skills from our QA people given the small size of our teams handling a wide variety of tasks. Nothing that others haven't been able to learn o the job from a good foundation, but this one had been more of a click stuff and run a script to test QA person at her previous jobs and I guess we had been pretty desperate for anyone that we relaxed hiring standards for a bit (we'd had at least 2 openings at the time IIRC). She often had to google pretty basic stuff she couldn't remember which is perfectly fine except that she couldn't differentiate between what was industry standard stuff you could look up and what was proprietary stuff that wouldn't return anything useful.
One day she came into the dev cubicles mortified after trying to look stuff up. It turned out she'd been trying to google some of our proprietary methods to escape, scrub, and strip control characters . . . one of which was named "nasty stripper" and another of which is named "super nasty stripper." She was not happy about having done that at work.
Game Maker uses its own language. There is some appeal to trying a thing that could apply to more than one engine. My work also deals with alot of PHP and Javascript (I'm not a dev, so I dont deal with it directly) but I want to start gaining skills that help me perceive what's happening in our code.
So, I guess I need to break down "personality test" into its different, logical problems, and then try to find how to do that in C# or Java?
To be really explicit about what your app's different logical problems are, try to make a list of all the things it'll do, but make that list specific and granular. Stuff like "store a list of questions," "display questions on the screen in order," "store answers to questions," stuff like that. One of the biggest hurdles that novice programmers make is to have a single component try to do multiple jobs. That results in a lot of unintended complication, bugs, and other assorted problems which can be avoided simply be separating the stuff that does X from the stuff that does Y.
C# or Java would be good choices, but you can actually do something like this directly in javascript as well if you'd like to jump right into where it'll be most relevant.
Also think a bit about what kind of structure you want for the data bit. Something like:
App has multiple tests
A test has multiple questions
A question has multiple answers
To just do something really basic.
+1
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Something with a Read, Eval, Print Loop (REPL) is quite handy for prototyping things like this. But it's by no means a requirement, it just can make your life easier.
Javascript is capable of this (though it has a number of extremely irritating gotchas). Java doesn't (it has a different set of gotchas, but is much more likely to catch certain classes of errors at compile time or runtime, where Javascript will just carry on about its business until you do something completely illegal--you'll just get garbage out). Python is wonderfully easy to use for the basic cases (you don't need to do the complicated stuff if you don't want to, and its libraries are huge), but since it's not on your list, don't feel like you need to use it.
But anyway, yeah, one useful way to think about it is in terms of data flow. What is the data going in, what transformations are done to it, and what is the data coming out? Then you look at the part doing transformations and try to see if you can break it up into different parts that all have their own data flow. This way you can swap out various layers while still using the same code for the important bits. This also lets you test the lower-level bits in isolation with automated tests, which is helpful.
That's a key to doing well at any job, though. Break it into logical and small components that can be done easily, then plug them together.
It is but it can a tough concept for newer programmers to get their head around if they haven't seen the benefits of it first hand from working with code someone else wrote. Anything that studied this stuff in college would be exposed to it but stuff like Game Maker is exposing a lot of people without that background to development.
For you vagrant users, how do you deal with SSH inside your VM? Do you have a vagrant provisioning step that pulls in your .ssh directory? Do you plop it in manually? Do you exit the VM to push from host?
I was tending toward the provision step pulling .ssh from the host to the VM, but I can imagine that if someone outside the immediate team of 2 tried to use it, they'd be upset at their SSH keys getting copied.
What is your use case, because I get a feeling you are doing something wrong or I am misreading your question. If your goal is to use your private key from another host, ssh-agent forward to the vagrant host, don't move keys around.
The rule of ssh is the private key never leaves the machine it was generated on.
If I am misreading your question and you just want to provision pub keys, the answer is ansible, but then, that's the answer to everything.
I recently even moved my dotfiles to ansible.
I figure I'll probably make a lot of dumb mistakes, but hope that personality tests are simple enough for me to understand what needs to be accomplished, but complicated enough that I'll need to learn different things to get to my end goal. Getting started is the hard part.
I'm okay at looking at a bunch of code and figuring out what it does enough to modify it a bit, but writing something from scratch seems very daunting.
I figure I'll probably make a lot of dumb mistakes, but hope that personality tests are simple enough for me to understand what needs to be accomplished, but complicated enough that I'll need to learn different things to get to my end goal. Getting started is the hard part.
I'm okay at looking at a bunch of code and figuring out what it does enough to modify it a bit, but writing something from scratch seems very daunting.
Yeah, that's a big hurdle when doing programming self-studies from scratch - where the heck do you start?
+1
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
I figure I'll probably make a lot of dumb mistakes, but hope that personality tests are simple enough for me to understand what needs to be accomplished, but complicated enough that I'll need to learn different things to get to my end goal. Getting started is the hard part.
I'm okay at looking at a bunch of code and figuring out what it does enough to modify it a bit, but writing something from scratch seems very daunting.
There are two reasonable ways to go at this: top down, and bottom up. If you have a very good idea of what needs to happen at the bottom, start there. E.g. let's say your personality test takes a sequence of weights, sums them up, thresholds them, and spits out an ID corresponding to a personality. You can write the part that does that first, and then think about what the inputs and outputs of that need to be to start turning it into a usable program.
If not, start at the top and work your way down. Maybe you decide "Well first, I need to be able to display questions and collect answers", so you start with repeatedly collecting data from the user. Then you start figuring out what to do with it. And so on.
Chances are, first time through the architecture is going to suck. That's fine and expected. You don't know how to write something until you've done it at least 3 times. And as you gain more experience, you'll see more opportunities to break things apart into smaller, more self-contained and understandable bits.
Programming is just writing a detailed recipe for an idiot that does exactly what they're told, even if they're told that the next step is to cut off their hand.
I figure I'll probably make a lot of dumb mistakes, but hope that personality tests are simple enough for me to understand what needs to be accomplished, but complicated enough that I'll need to learn different things to get to my end goal. Getting started is the hard part.
I'm okay at looking at a bunch of code and figuring out what it does enough to modify it a bit, but writing something from scratch seems very daunting.
so if you're doing a compiled language, you're going to end up with a console program almost always (they're also much easier to work with)
but if you don't like dealing with the command prompt in windows, it's going to annoy you
So figuring out how you want to deal with UI will often determine what kind of language you start with. If you're okay with the console programs, any language works, but it's usually C based like C/C++/C#/Java. If you want drop a file onto your desktop and double click it and run it in chrome or something, then it's almost always going to be HTML and JavaScript.
If you have a webserver set up, and want something between the console and the HTML stuff, that's where PHP would come in.
If you want a full fledged UI program, you can do it with C#, Java, and VB, but they're a bit of work further than the console stuff.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I have started working with powershell to interact with github for work, and run a local version of some stuff. It's slow and annoying but that's mostly because I need to be very careful to not fuck things up at work, where I can break my own projects.
My end goal is for sure to work in something like Unity and hopefully let it do some of the work for me, rather than trying to build an app from the ground up. But its early enough where I dont fully understand what that means.
I figure looking at building a complex dialog tree build to work with a unity game (like a dating sim) is probably pretty close to what I need, but since what I want to build is not so linear, I figure the structure is probably not quite correct. Not enough to say, take an example game and just outfit it to what I need.
I have started working with powershell to interact with github for work, and run a local version of some stuff. It's slow and annoying but that's mostly because I need to be very careful to not fuck things up at work, where I can break my own projects.
My end goal is for sure to work in something like Unity and hopefully let it do some of the work for me, rather than trying to build an app from the ground up. But its early enough where I dont fully understand what that means.
I figure looking at building a complex dialog tree build to work with a unity game (like a dating sim) is probably pretty close to what I need, but since what I want to build is not so linear, I figure the structure is probably not quite correct. Not enough to say, take an example game and just outfit it to what I need.
The best way I've seen it explained is that Unity is for people who are already programming, whereas GameMaker is for people who want to get right into designing.
My experience with the two seems to bear that out. My recent work has been to really dive into how the editor works, as opposed to just getting games to work in the engine. By creating custom assets, custom "inspector" displays, and separating game logic classes from presentation and editor classes, I've found you can really flex Unity into an editor for your particular game type. This means that I (programmer) work with the designer to figure out what we'll need to do in the editor, and I can actually make the editor behave how I want before designers get to it.
GameMaker seems to be more about getting 2D games up and running in a convenient default interface, even if I'm not sure I agree with the architecture. I'm much less conversant in GM, though, so I'm open to correction.
Okay, I got distracted while writing, so I should clarify that I was trying to talk to the point of "let it do some of the work for me", which is absolutely what you should do. If you can separate your game logic from presentation, you can work on that before even putting it into an engine, but I find GameMaker is best for getting you right into things that way.
I prefer Unity for myself, but I enjoy the software architecture aspect of making custom asset files and custom inspectors.
I would say that if your goal is to make unity games then focusing on unity would probably be a fine idea. If what you want to do is learn programming then I think you are better off trying to make some c# command line programs first and then try to adapt one of those to work with a user interface after you have done some ui tutorials.
Learning Unity would be a great asset to the part of me that still wants to make/work in games, so it has some appeal. Ideally I would use this exercise to both get better at programming but also make more really stupid apps in the future. Since this is hobby level for me, the main goal is to "do some programming" without a very lofty qualifier for how useful it might be in the long run.
advice from someone who actually does game development
don't use games as your programming starting point unless you can be incredibly disciplined. You'll be constantly sidetracked by things like asset creation and game design.
Learning Unity would be a great asset to the part of me that still wants to make/work in games, so it has some appeal. Ideally I would use this exercise to both get better at programming but also make more really stupid apps in the future. Since this is hobby level for me, the main goal is to "do some programming" without a very lofty qualifier for how useful it might be in the long run.
Don't use unity then. If you sit down and apply yourself and learn unity, what is going to happen is that you are going to learn unity. That's great if that's your goal, but it's not so great if what you really want is to learn programming.
There are two main aspects to programming. Logic and structure. Logic is the 'how do I tell the computer to do what I want', the recipe for idiots that Orca mentioned earlier. Logic is the easy part. Once you lean it it's with you for life. It rarely gets more complicated (although there are exceptions). Structure is the hard part. Structure is the shape of each part and how all of the different parts of a program or app or game or whatever actually fit together. Structure is how you design your own parts to fit with each other, how you integrate other people's parts into your own projects (be they parts written by a peer you are working with or ones designed by a third party like the .net or Java ui libraries).
Unity will handle a little bit of the logic for you, some of the repetitive or common logic that needs to exist for nearly any game. Most of it you'll get to write yourself. That's ok. Unity will handle almost all of the structure. What little structure isn't abstracted behind the curtain is going to be explicitly dictated, basically auto-filled for you. This is not ok, and will lead to a deficiency in knowledge and experience.
The reason why I recommend making a graphic ui app by making a command line app first and then adapting it to use a proper ui library is because it's going to encourage you to make mistakes. Mistakes you're going to learn a whole lot from as you find out all the ways your original design doesn't fit cleanly with the new ui library. Mistakes that the next time you make a program will have you thinking about structure before you make the first keystroke.
Right now my current plan is to learn the programming language to make my thing as a basic thing (because the test itself requires no assets) and then try to take that to unity to apply assets to it. My thought is that, something really simple like arranging data is probably a good thing to do in C#, but once I want to outfit it with art I can either go down the longer road of making my program work to grab a bunch of assets, or I can just take my underlying structure to something like unity, and learn a bit of both as I go. That seems like a reasonable conclusion to me, unless I'm wrong?
It's important to note that if I was ever to Get Good™ at something, it's drawing/painting, so creating a proof of concept something or other is still a reasonable conclusion of all this, I'm unlikely to come out of this the next hot developer. So I want to learn things, but I'm not concerned with setting myself up for a long career in programming either.
@LD50 ah thanks for the explanation! I'll keep that in mind.
I found some C# books on kindle unlimited, so I'm just going to start fucking around, and seeing what I can make. I think it'll be a good side exercise, I really want to keep flexing my left-brain skills.
I think I might try and build some very small versions of the program (like, just a few questions, and a few results) and make a few iterations on it before I try and build the larger app I have in mind. Along the way I'll try and document and plan for the end goal personality app, and hopefully after a program or three, I'll feel like I can leap into it.
We're also here if you need help, so, there's also that.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
+4
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
Hey, hey now, Bowen. What's with this help for free thing, Bowen? This is our chance. This ain't no draw thread! The shoe's on the other foot now. Iruka will have to beg us for critiques this time. Ah hahahahahaha!
Hmm, but then again, she's already a mod. She's probably already familiar with suffering as the basis for learning...
My question is, really, what language should I look into, and what's the best sort of tutorials to teach me how to work on this particular structure? I'm guessing there are multiple solutions to solve my problem, but I thought someone might have a good example program to try building to give me an idea of how it could work.
Unity is brutal overkill for what you're trying to do. Delzhand's point about being sidetracked is an important one. As a beginner, it's very easy to conflate the aesthetic and the logical, leading to horrendous code and a poor learning experience.
There has never been a platform that invites this behavior more than Unity.
Orca's suggestions are good. If you're serious about learning, you should try to write this code as a formless console application. Then after it works, concern yourself with how you want to get it into Android.
By going with Javascript, you give yourself way more options over C#
When I come back to this thread with what is the programming equivalent of a shitty anime drawing, I expect nothing but deviant art level praise.
don't you tempt me
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
The Escape Goatincorrigible ruminantthey/themRegistered Userregular
when I got this job I didn't actually know it would involve web dev at all but good thing I got that IT minor to learn javascript in college, huh? ah well, as not-excited as I am to do a bunch of javascript stuff it's still better than digging into the low-level proprietary languages they have lying around the office
plus apparently they're also going to be putting me on the test automation team as well, which like, I'm not super excited for conceptually (I moved halfway across the country to avoid the purely test position in my hometown) but it'll be nice to do something in Java again
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
edited February 2017
Tying yourself to a game engine as a start doesn't really help you if you're interested in programming. You need the freedom to structure things as you see fit, make mistakes, and figure out how to fix them. Unity or Gamemaker have a structure you'll be fitting awkwardly within--not really ideal IMO unless you already know what you're getting into.
Instead, I would start with a console application as has been said above. Given you work with Javascript and PHP, I would start with Javascript if you want it directly applicable to work. Or use Python. (PHP is IMO a loaded gun aimed at your foot; you can avoid problems, but it's not going to make it easy for you, and there are an unfortunate number of extremely outdated tutorials out there that teach worst practices instead of best practices).
If the endgame is a graphical app, Javascript probably makes the most sense for you: it's directly applicable to work, and all you need to run the app is a web browser. Throw it on a server somewhere for $5 a month and off you go if you decide to go that route. And if you want people to actually use it, chances are they'll be uninterested in downloading and running an app.
Longer term perhaps consider running the app on a server and storing the data in a database, which would allow you to collect statistics.
But that's all for later. Start with the simple, especially if you haven't done this before. You'll work your way up with time.
edit: Also, it's easy to get bogged down in 56 different frameworks with front-end work. I would ignore all that. It has the same problem that Unity has in that it all imposes structure on you and forces you to code their way. All you need is a text editor and a browser to start working with javascript. Worry about all the other bullshit later.
Orca on
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Chances are, first time through the architecture is going to suck. That's fine and expected. You don't know how to write something until you've done it at least 3 times.
Hell, I ran into this today.
I had a pair of complicated operations I needed to perform using a non-obvious iteration through an array.
My first solution used three separate classes and four functions. All so I could avoid duplicating the code for the iteration. I finished it, stepped back and went "that's way too complicated".
Then I figured out a much more straightforward way of doing the iteration and repeated the code of the iteration and just did the operations inline.
Half the vertical space, and easier to understand.
Now if only one of the constants I needed to get my hands on was a compile-time constant so I could do all the computation at compile time instead of runtime, my night would have been complete.
When you hit a certain point is it recommended to continue building applications with a command line GUI or to just move straight to using actual GUIs/APIs, etc?
FI've started teaching myself a lot of programming lately and I have an intermediate level of Python I'd say where the main difficulty I'm having right now is working with REST and the requests package. For example I was able to build a program in a tkinter GUI that searches through googlebooks for the right information and then puts that information in an excel spreadsheet; next is to use it with an SQL database. I'm finding more often that the logic for what I want to do is rather straightforward, but it requires understanding how to make a request to an API and what not.
Also when I said front-end I meant HTML. I fucking hate HTML. I enjoy UX design quite a lot actually, but HTML is the devil's bane and I hate coding with it.
you dont need to build every application without any GUI at all, but you need to know how to.
for me, in development, I will use GUI early in development if it aids my productivity. like a button that can spawn mock objects for me, or, as is very common on iPhone, there's some piece of functionality that requires a UI to determine if its working (such as a framework-supplied view)
tangential rant:
in iPhone applications in particular, sometimes greater than half of your codebase is View/Controller related anyway, so you inevitably find yourself needing to break it out early. Unity is the same way. You can't get very far before you have to start asking serious questions about your View layer.. knowing how to ask/answer those questions in a way that doesn't muddy your project takes tons of experience.
'tis why you want to avoid these environments initially, because if your work comes to be defined by your view layer, you'll end up just courting StackOverflow all day for how to wiggle Unity's various knobs until the thing you want happens, and the part of your brain that is for authoring logic will atrophy. i've seen it in people who've worked for me. its ugly
I'm slowly realizing that acquiring and cleaning data files is the...most extensive...part of data analytics.
Particularly when using APIs to acquire the data.
Oh, Bureau of Labor Statistics, that seriesID doesn't have data for 2000-2016 except for 2015 cause y'all aren't bothering to actually maintain a catalog of data? Well fuck you[/] then.
I'm slowly realizing that acquiring and cleaning data files is the...most extensive...part of data analytics.
Particularly when using APIs to acquire the data.
Oh, Bureau of Labor Statistics, that seriesID doesn't have data for 2000-2016 except for 2015 cause y'all aren't bothering to actually maintain a catalog of data? Well fuck you[/] then.
My wife does data science for a place full of librarians and cartographers, and I was astonished at how none of the very official sources they pull from give any fucks about their data.
Edit: she had to figure out how to screen scrape some very tabular data hidden in nested divs behind some JavaScript UI. Because WEB TWO POINT OH!
Posts
Yeah, then I say C#, because it, PHP and Javascript all have syntax derived from ye olde C. Code will look very very similar in all three.
edit: bowen is correct in that javascript does things differently, though.
I was tending toward the provision step pulling .ssh from the host to the VM, but I can imagine that if someone outside the immediate team of 2 tried to use it, they'd be upset at their SSH keys getting copied.
Java and Javascript are different though, so keep that in mind!
Oh, this reminds me of a story of a former coworker.
My division was a startup back in the early to mid 2000s before it got acquired a few months after I started working here a few years back and like many startups a large chunk of the code base was created by one very talented engineer working late into the night fueled by caffeine and a sardonic sense of humor. My division's software reads in analyzes what are often non-standardized documents from the client which means that we've needed a variety of methods to escape or scrub control characters from what we frequently get that would mess up parsing of the data. More on that in a bit.
One of our QA engineers that was hired about a year into my tenure was a middle aged woman who had grown up in Pakistan. She ultimately didn't work out as we need a pretty significant set of skills from our QA people given the small size of our teams handling a wide variety of tasks. Nothing that others haven't been able to learn o the job from a good foundation, but this one had been more of a click stuff and run a script to test QA person at her previous jobs and I guess we had been pretty desperate for anyone that we relaxed hiring standards for a bit (we'd had at least 2 openings at the time IIRC). She often had to google pretty basic stuff she couldn't remember which is perfectly fine except that she couldn't differentiate between what was industry standard stuff you could look up and what was proprietary stuff that wouldn't return anything useful.
One day she came into the dev cubicles mortified after trying to look stuff up. It turned out she'd been trying to google some of our proprietary methods to escape, scrub, and strip control characters . . . one of which was named "nasty stripper" and another of which is named "super nasty stripper." She was not happy about having done that at work.
Steam Profile
3DS: 3454-0268-5595 Battle.net: SteelAngel#1772
To be really explicit about what your app's different logical problems are, try to make a list of all the things it'll do, but make that list specific and granular. Stuff like "store a list of questions," "display questions on the screen in order," "store answers to questions," stuff like that. One of the biggest hurdles that novice programmers make is to have a single component try to do multiple jobs. That results in a lot of unintended complication, bugs, and other assorted problems which can be avoided simply be separating the stuff that does X from the stuff that does Y.
C# or Java would be good choices, but you can actually do something like this directly in javascript as well if you'd like to jump right into where it'll be most relevant.
To just do something really basic.
Javascript is capable of this (though it has a number of extremely irritating gotchas). Java doesn't (it has a different set of gotchas, but is much more likely to catch certain classes of errors at compile time or runtime, where Javascript will just carry on about its business until you do something completely illegal--you'll just get garbage out). Python is wonderfully easy to use for the basic cases (you don't need to do the complicated stuff if you don't want to, and its libraries are huge), but since it's not on your list, don't feel like you need to use it.
But anyway, yeah, one useful way to think about it is in terms of data flow. What is the data going in, what transformations are done to it, and what is the data coming out? Then you look at the part doing transformations and try to see if you can break it up into different parts that all have their own data flow. This way you can swap out various layers while still using the same code for the important bits. This also lets you test the lower-level bits in isolation with automated tests, which is helpful.
It is but it can a tough concept for newer programmers to get their head around if they haven't seen the benefits of it first hand from working with code someone else wrote. Anything that studied this stuff in college would be exposed to it but stuff like Game Maker is exposing a lot of people without that background to development.
Steam Profile
3DS: 3454-0268-5595 Battle.net: SteelAngel#1772
What is your use case, because I get a feeling you are doing something wrong or I am misreading your question. If your goal is to use your private key from another host, ssh-agent forward to the vagrant host, don't move keys around.
The rule of ssh is the private key never leaves the machine it was generated on.
If I am misreading your question and you just want to provision pub keys, the answer is ansible, but then, that's the answer to everything.
I recently even moved my dotfiles to ansible.
I'm okay at looking at a bunch of code and figuring out what it does enough to modify it a bit, but writing something from scratch seems very daunting.
Yeah, that's a big hurdle when doing programming self-studies from scratch - where the heck do you start?
There are two reasonable ways to go at this: top down, and bottom up. If you have a very good idea of what needs to happen at the bottom, start there. E.g. let's say your personality test takes a sequence of weights, sums them up, thresholds them, and spits out an ID corresponding to a personality. You can write the part that does that first, and then think about what the inputs and outputs of that need to be to start turning it into a usable program.
If not, start at the top and work your way down. Maybe you decide "Well first, I need to be able to display questions and collect answers", so you start with repeatedly collecting data from the user. Then you start figuring out what to do with it. And so on.
Chances are, first time through the architecture is going to suck. That's fine and expected. You don't know how to write something until you've done it at least 3 times.
Programming is just writing a detailed recipe for an idiot that does exactly what they're told, even if they're told that the next step is to cut off their hand.
so if you're doing a compiled language, you're going to end up with a console program almost always (they're also much easier to work with)
but if you don't like dealing with the command prompt in windows, it's going to annoy you
So figuring out how you want to deal with UI will often determine what kind of language you start with. If you're okay with the console programs, any language works, but it's usually C based like C/C++/C#/Java. If you want drop a file onto your desktop and double click it and run it in chrome or something, then it's almost always going to be HTML and JavaScript.
If you have a webserver set up, and want something between the console and the HTML stuff, that's where PHP would come in.
If you want a full fledged UI program, you can do it with C#, Java, and VB, but they're a bit of work further than the console stuff.
My end goal is for sure to work in something like Unity and hopefully let it do some of the work for me, rather than trying to build an app from the ground up. But its early enough where I dont fully understand what that means.
I figure looking at building a complex dialog tree build to work with a unity game (like a dating sim) is probably pretty close to what I need, but since what I want to build is not so linear, I figure the structure is probably not quite correct. Not enough to say, take an example game and just outfit it to what I need.
The best way I've seen it explained is that Unity is for people who are already programming, whereas GameMaker is for people who want to get right into designing.
My experience with the two seems to bear that out. My recent work has been to really dive into how the editor works, as opposed to just getting games to work in the engine. By creating custom assets, custom "inspector" displays, and separating game logic classes from presentation and editor classes, I've found you can really flex Unity into an editor for your particular game type. This means that I (programmer) work with the designer to figure out what we'll need to do in the editor, and I can actually make the editor behave how I want before designers get to it.
GameMaker seems to be more about getting 2D games up and running in a convenient default interface, even if I'm not sure I agree with the architecture. I'm much less conversant in GM, though, so I'm open to correction.
I prefer Unity for myself, but I enjoy the software architecture aspect of making custom asset files and custom inspectors.
I try to pick up things in my free time and it's like
eh
nah
I'm not getting paid and I'd rather watch netflix
don't use games as your programming starting point unless you can be incredibly disciplined. You'll be constantly sidetracked by things like asset creation and game design.
Don't use unity then. If you sit down and apply yourself and learn unity, what is going to happen is that you are going to learn unity. That's great if that's your goal, but it's not so great if what you really want is to learn programming.
There are two main aspects to programming. Logic and structure. Logic is the 'how do I tell the computer to do what I want', the recipe for idiots that Orca mentioned earlier. Logic is the easy part. Once you lean it it's with you for life. It rarely gets more complicated (although there are exceptions). Structure is the hard part. Structure is the shape of each part and how all of the different parts of a program or app or game or whatever actually fit together. Structure is how you design your own parts to fit with each other, how you integrate other people's parts into your own projects (be they parts written by a peer you are working with or ones designed by a third party like the .net or Java ui libraries).
Unity will handle a little bit of the logic for you, some of the repetitive or common logic that needs to exist for nearly any game. Most of it you'll get to write yourself. That's ok. Unity will handle almost all of the structure. What little structure isn't abstracted behind the curtain is going to be explicitly dictated, basically auto-filled for you. This is not ok, and will lead to a deficiency in knowledge and experience.
The reason why I recommend making a graphic ui app by making a command line app first and then adapting it to use a proper ui library is because it's going to encourage you to make mistakes. Mistakes you're going to learn a whole lot from as you find out all the ways your original design doesn't fit cleanly with the new ui library. Mistakes that the next time you make a program will have you thinking about structure before you make the first keystroke.
It's important to note that if I was ever to Get Good™ at something, it's drawing/painting, so creating a proof of concept something or other is still a reasonable conclusion of all this, I'm unlikely to come out of this the next hot developer. So I want to learn things, but I'm not concerned with setting myself up for a long career in programming either.
I found some C# books on kindle unlimited, so I'm just going to start fucking around, and seeing what I can make. I think it'll be a good side exercise, I really want to keep flexing my left-brain skills.
I think I might try and build some very small versions of the program (like, just a few questions, and a few results) and make a few iterations on it before I try and build the larger app I have in mind. Along the way I'll try and document and plan for the end goal personality app, and hopefully after a program or three, I'll feel like I can leap into it.
Hmm, but then again, she's already a mod. She's probably already familiar with suffering as the basis for learning...
Unity is brutal overkill for what you're trying to do. Delzhand's point about being sidetracked is an important one. As a beginner, it's very easy to conflate the aesthetic and the logical, leading to horrendous code and a poor learning experience.
There has never been a platform that invites this behavior more than Unity.
Orca's suggestions are good. If you're serious about learning, you should try to write this code as a formless console application. Then after it works, concern yourself with how you want to get it into Android.
By going with Javascript, you give yourself way more options over C#
don't you tempt me
plus apparently they're also going to be putting me on the test automation team as well, which like, I'm not super excited for conceptually (I moved halfway across the country to avoid the purely test position in my hometown) but it'll be nice to do something in Java again
Instead, I would start with a console application as has been said above. Given you work with Javascript and PHP, I would start with Javascript if you want it directly applicable to work. Or use Python. (PHP is IMO a loaded gun aimed at your foot; you can avoid problems, but it's not going to make it easy for you, and there are an unfortunate number of extremely outdated tutorials out there that teach worst practices instead of best practices).
If the endgame is a graphical app, Javascript probably makes the most sense for you: it's directly applicable to work, and all you need to run the app is a web browser. Throw it on a server somewhere for $5 a month and off you go if you decide to go that route. And if you want people to actually use it, chances are they'll be uninterested in downloading and running an app.
Longer term perhaps consider running the app on a server and storing the data in a database, which would allow you to collect statistics.
But that's all for later. Start with the simple, especially if you haven't done this before. You'll work your way up with time.
edit: Also, it's easy to get bogged down in 56 different frameworks with front-end work. I would ignore all that. It has the same problem that Unity has in that it all imposes structure on you and forces you to code their way. All you need is a text editor and a browser to start working with javascript. Worry about all the other bullshit later.
Hell, I ran into this today.
I had a pair of complicated operations I needed to perform using a non-obvious iteration through an array.
My first solution used three separate classes and four functions. All so I could avoid duplicating the code for the iteration. I finished it, stepped back and went "that's way too complicated".
Then I figured out a much more straightforward way of doing the iteration and repeated the code of the iteration and just did the operations inline.
Half the vertical space, and easier to understand.
Now if only one of the constants I needed to get my hands on was a compile-time constant so I could do all the computation at compile time instead of runtime, my night would have been complete.
FI've started teaching myself a lot of programming lately and I have an intermediate level of Python I'd say where the main difficulty I'm having right now is working with REST and the requests package. For example I was able to build a program in a tkinter GUI that searches through googlebooks for the right information and then puts that information in an excel spreadsheet; next is to use it with an SQL database. I'm finding more often that the logic for what I want to do is rather straightforward, but it requires understanding how to make a request to an API and what not.
Also when I said front-end I meant HTML. I fucking hate HTML. I enjoy UX design quite a lot actually, but HTML is the devil's bane and I hate coding with it.
for me, in development, I will use GUI early in development if it aids my productivity. like a button that can spawn mock objects for me, or, as is very common on iPhone, there's some piece of functionality that requires a UI to determine if its working (such as a framework-supplied view)
tangential rant:
in iPhone applications in particular, sometimes greater than half of your codebase is View/Controller related anyway, so you inevitably find yourself needing to break it out early. Unity is the same way. You can't get very far before you have to start asking serious questions about your View layer.. knowing how to ask/answer those questions in a way that doesn't muddy your project takes tons of experience.
'tis why you want to avoid these environments initially, because if your work comes to be defined by your view layer, you'll end up just courting StackOverflow all day for how to wiggle Unity's various knobs until the thing you want happens, and the part of your brain that is for authoring logic will atrophy. i've seen it in people who've worked for me. its ugly
Anyone have something to recommend for working with it? Tried an Atom extension real quick, but wasn't too happy with it.
It's also a bit unusual in that there's an actual default tool for formatting code, so at least I have a button to auto-format the code for me.
Particularly when using APIs to acquire the data.
Oh, Bureau of Labor Statistics, that seriesID doesn't have data for 2000-2016 except for 2015 cause y'all aren't bothering to actually maintain a catalog of data? Well fuck you[/] then.
My wife does data science for a place full of librarians and cartographers, and I was astonished at how none of the very official sources they pull from give any fucks about their data.
Edit: she had to figure out how to screen scrape some very tabular data hidden in nested divs behind some JavaScript UI. Because WEB TWO POINT OH!