This may be completely ridiculous to point out for this exercise, but you are also not checking the "number of times" variable to make sure that its actually a number. What if someone types in "asdf" instead? Then the Int.Parse() method would crash your program. So, you'd want to put that in a Try/Catch type block. I know you know to put in numbers, but if you ever build software to be used by other people, then you can't trust them to put in the correct types of input. Maybe its silly for this exercise, but its good to start getting into the habit of thinking about how people could intentionally mess up your code / program.
slayeminMember Since 23 Feb 2001
Offline Last Active Jun 23 2016 06:29 PM
Indie VR Game Developer working on Spellbound. Founder of Wobbly Duck Studios.
- Group Members
- Active Posts 1,590
- Profile Views 20,017
- Submitted Links 0
- Member Title Member
- Age 34 years old
- Birthday January 1, 1982
Seattle, Washington, USA
Programming, Philosophy, Chess, Video Games, Science, Mathematics, Business
Posted by slayemin on 19 January 2015 - 02:12 PM
Looks pretty good to me.
Changing the if/elseif to a switch statement in this case is unnessary. It would totally be a case of premature optimization and only make the code slightly less readable.
The only thing I'd say... for the sake of learning code, avoid using the Array.Reverse() method and try to do it manually.
Also: what happens if someone wants to print their names -1 times?
Posted by slayemin on 15 January 2015 - 08:25 PM
I'll have to disagree that programming is hard. A program can be complex, but not necessarily hard.
I'd say start with a game engine that doesn't require as much work on the textual side at first, so that you can get a good idea of what goes into making games in general (sound, graphics etc). Something like Scratch or GameMaker.
You will see results, and you will also see if it's really the programming that is holding you back (and not laziness, or the lack of focus.)
Without focus, no matter how simple the tool makes it, you still have to understand your own idea well enoug to create it using the "tool" that is programming.
It's not the programming that's hard. It's finishing the big project you're working on.
To put it another way: Running itself isn't really that hard. But running a marathon is.
Your advice is good -- start by trying to run a mile and get good at that, and slowly increase how far you can run. Eventually, you can run marathons if you stick with it and push yourself.
Posted by slayemin on 15 January 2015 - 01:25 PM
I'd do this for a week, and then stop and pause and look at what I'm doing with my life and conclude that it's being wasted. I'm wasting time. And then I'd get disappointed in myself and want to do something better with my life. That's a fleeting feeling though, and soon I'd dive right back into the games and videos. It's all I did. Anybody would eventually get depressed if they just did that and only that (money is irrelevant here).
Off of the OP's topic for one second. How do you make money to survive by playing games and watching youtube? That doesn't sound bad to me. Sounds like heaven.
You don't. You save as much money as you can while you're "officially" employed and when your job ends, you have to live off of those savings until you make more money. You can stretch the savings account by investing the money, but that's always a huge risk, where you may lose the money as well. It never feels good to lose money you can't afford to lose, but it's a relief when you get money to buy you more time. It sounds nice, but it gets old.
Posted by slayemin on 14 January 2015 - 05:25 PM
I can understand the depression bit. I think I've been there a bit myself. I can't speak for you, but here's what was happening with me:
I'd spend every single day in front of the computer, playing video games or watching youtube videos, and alternating between videos and games when one gets more boring than the other. I do this until I am completely and utterly exhausted, usually some time at around 4am or 5am. If it was summer, the birds would start to chirp before the sun comes up and that would be my cue to go to sleep. I'd do this for a week, and then stop and pause and look at what I'm doing with my life and conclude that it's being wasted. I'm wasting time. And then I'd get disappointed in myself and want to do something better with my life. That's a fleeting feeling though, and soon I'd dive right back into the games and videos. It's all I did. Anybody would eventually get depressed if they just did that and only that (money is irrelevant here). I mean, there's more to life than video games and youtube. You don't want to realize a decade later that your last ten years were a blur, right?! That'd make you feel even more depressed and hopeless. But here's the thing: video games, youtube videos, netflix, etc are just a default habit, it's something you do when you don't want to try to think of something else to do. I mean, you *could* spend 30 minutes figuring out a good project to work on and get into, or you could just fart around on the computer. We human beings tend to take the path of least resistance, we're lazy. If we always take the easy road, we get fat, stupid and complacent in life. If you really want something, you have to work for it. There is no shortcut. Want to get stronger and in shape? Gotta lift weights and eat well! Want to be better at mathematics? Time to crack open a few math books and start doing some practice problems. Want to get great at painting? Break out the paints and start painting. Want to get good at game development? Start making games at your skill level. Want to get good at wood carving? Break out some wood and get carving. You'll suck at first. Everyone does. But don't be a critic on your talents in comparison to others, instead, focus on how awesome this thing *YOU* did is. YOU figured out how to do it all on your own, and you did it! All on your own. Its rewarding. A big part of the reward in all of this is your own personal discovery. Even today, I'm discovering new things for myself which are probably well known to everyone else but me (example of something I learned today: If you take two line segments of any triangle and draw their perpendicular lines at the midpoints of each segment, the intersection point is the same point as the third segment you didn't draw!). Who cares if other people already knew this or that, or mastered something I'm a novice at. It's new and hard for me! What's funky is this...believe it or not, it's actually more fun to NOT play video games, NOT watch youtube videos, NOT watch netflix or TV, NOT do the default goto behavior/habit, and much more fun to spend time working on your own projects (whatever they are). Yeah, it's hard work. Yeah, it takes effort and exertion. It's just as hard as hiking up a big mountain every day. I can tell you to do it, and tell you about the view from the top, but you have to climb the mountain for yourself if you want to see the view. Nobody can helicopter you to the top. That means putting one foot in front of the other even though your body and mind is telling you that you don't want to. A lot of people dream about seeing the top of the mountain (figuratively) but never take the first step to even try. A lot of people take a few steps, see its hard, and give up. Some people take a bunch of steps and die on the trail trying to get to the top. And some people overcome all of this and reach the summit. Clamp down, fight yourself, find that grit, and steam roll any obstacle that gets in your way with hard work and perseverance, every single day. That's the key difference between successful people and failures.
One last thing about making games: Making games is not even close to the same as playing them. Being good at (and enjoying) playing games is pretty irrelevant to making games. This is a common misconception among young college students who pay bucket loads of money to go to a specialized university which will teach them how to make games. They get there, pay a lot of money ... and then it gets really hard, they have a rude awakening on the level of work required, and they don't know to work hard or want to work hard, and then they get disillusioned, give up and drop out. The school is more than happy to take their loan money and let them wash out. Making video games is a subset of software development, not playing games. Become a great, hard working software developer and you'll do fine in either the games industry or the software industry.
Posted by slayemin on 13 January 2015 - 03:23 PM
1) Software programs are never completed. They may be complete for now, but requirements / needs will change over time. That means the program needs to change as well or it will become useless / irrelevant, and you're not going to find a business person who has invested hundreds of thousands to build software that can't adapt to their changing needs. What this means is that someone will need to read and understand the code, the quicker the better, and most often it is not the same person who wrote it. This person is the maintenance programmer. They are angry people. They want to murder people who write bad code. So don't give them a reason to hunt you down.
2) Elegance is simplicity. The principle of occams razor applies. If two competing techniques yield the same result, the better technique is the simplest technique. For coders, this means less chances for bugs, less code to maintain, and usually better performance.
How much effort should you put into writing elegant, simple code? As much as is reasonably possible given your skill level and constraints. It will never be the last time anyone looks at that code.
Posted by slayemin on 09 January 2015 - 09:13 PM
The reason I recommend Unity is because it is a mature engine which has multi-platform support, including for mobile games. It also has a pretty big community behind it, so its easy for a beginner to find articles for the help they need. Yeah, it has a bit of a learning curve. You might spend a month or two, or three learning how to use the tool. But take it from me, a guy who wanted to avoid learning a third party engine as long as possible by creating his own engine, you will save SO much time trying to learn another engine / editor. I spent 12-18 months trying to build my own engine. It works, but its not very good. Certainly not good enough for a shippable game. If I wanted to add extra features and capabilities, I could look forward to spending a large amount of time implementing it, and it still wouldn't be nearly as good as the out-of-the-box implementation done by a team who spent many months sweating over the same problems. I'm not talking about adding a function or two, more like "I need to have multiplayer, which requires network code! shoot, that's going to cost me 2-3 months minimum to just get something up and running" vs. "oh, I need to add networking. Let's just look up how to use the built-in engine tools within the documentation and implement it", which would cost 2-3 days. These days, if you are a very small team and want to make a game -- and you're building your own engine -- you're doing it wrong. If you have a huge and experienced development studio which has a track record of shipping many games in the past, it isn't a bad idea to build your own engine (but you should have a really good business reason for that! Such as licensing, technical limitations, or pushing the tech forward).
Unity has multi-platform support, a mature community, and you can try it out before paying any money for it. You can also write C# code to script out any game behaviors you need, so that's pretty handy.
The most viable alternative to Unity is Unreal Engine 4 (which I'm using). You can pay $20/month to get full access to the whole engine, all of its source code, and be making games in no time (or how fast you can pick it up). You don't necessarily need to write code, you can implement game play logic using their "blueprint" system to visually script together game logic. If thats not powerful enough, you can always add in C++ code to supplement your BP code. UE4 also has multi-platform support, but is a bit newer on the market so the community hasn't had as much time to develop and create tutorial content (though some exists).
Picking either UE4 or Unity will give you more than you'll ever need, so choosing one or the other will never be a disappointment.
Posted by slayemin on 09 January 2015 - 02:33 PM
I actively use both C++ and C#.
With C++, you can very easily shoot yourself in the foot if you mismanage pointers or forget to deallocate heap memory. It's one of the biggest sources of common bugs, especially with beginners.
C# and Java try to help you avoid these problems by taking care of most of that backend stuff for you. They both give you a garbage collector which will clean up your unused objects, but you lose control over when that happens. This can cause slight performance issues, but I have yet to see them myself and I wrote a rudimentary game engine using C# and XNA.
What really determines "speed"? I would argue that algorithm choice and implementation design are a hundred times more important than language selection. If you have 10,000 objects in a game world and you need to run collision detection on them, the technique you select is going to have a bigger impact on performance than any slight boost you'd get from using an unmanaged language. In other words, bad code / algorithm choice is much more responsible for bad performance than language choice. Aim for O(LogN) algorithms instead of O(N*N), and you'll generally be just fine. Even C++ will struggle with bad algorithms.
My recommendation: Use C# until you find a really compelling reason not to.
Posted by slayemin on 08 January 2015 - 08:35 PM
Oh. This just occurred to me.
You should look at your UCLASS macro. Your class probably isn't showing up because its not visible to the editor. You'll want to add something like
This should make your class visible within the editor and allow you to derive blueprints from your class. It may also make your class visible on that dropdown menu.
Posted by slayemin on 08 January 2015 - 03:44 PM
What kind of problem are you getting?
Is the widget not visible within the details tab within the editor? Are you getting a type conflict which prevents you from adding the BP?
Also: You'd probably get a faster and more accurate response by looking around on the UE4 forums.
Posted by slayemin on 05 January 2015 - 04:23 PM
When I look at resumes, I try to figure out a few things:
1) Does this person know what they're doing?
1a) what is their skill level?
1b) What's their project track record?
1c) Is their experience relevant to the position?
2) Can I depend on this person to take ownership of a task and see to it that it gets done on time and to a high degree of quality?
3) What value can this person bring to the team? What can they do? How do they help me make more money than what I pay them?
If I was hiring for a programmer:
As it stands right now, your resume would be quickly discarded without a second thought. I'd look for stronger candidates. Who knows, maybe you are a strong candidate, but your resume just doesn't tell me that. All it has are a bunch of short non-descript terms for things I'm vaguely familiar with. Take "OpenGL deferred renderer, shader permutations (GLSL), and multiple lighting models." for example. It doesn't tell me much, if anything. What's involved with that stuff? What did you do? why did you do it? what problem did it solve? did it work? What was the result? Pretend I'm an idiot HR manager with a vague head for business and zero technical knowledge. How does this illustrate to me how you'd bring value to my company? Connect the dots, spell it out for me -- or I may either not connect the dots or connect them in ways you didn't want me to. (it's like programming! leave no room for guessing and assumptions!) What if my company doesn't use OpenGL or GLSL? Does that make your skill useless? You also barely mention everything. When you say, "2D collision detection", I have no idea how involved that is. Did you just do a simple function to test for overlapping axis aligned boxes, or did you do something as elaborate as creating something like Box2D? I have to assume its the former, which leaves me underwhelmed.
I also wouldn't care one bit about your jazz certificate.
The purpose of a resume is to get you an interview. You have to give me enough meat to chew on to consider you to be a viable candidate. That doesn't mean you write an essay or your life story, you just give me enough to go off of so that I can say, "it wouldn't be a waste of my time to interview this person. Let's bring them in!". Then, at the interview, you sell yourself and you do it hard. Don't go to an interview without a clue on what to say or do. Don't expect a bunch of one-sided questions from employer to employee, be the one to pitch yourself! Introduce yourself, demonstrate your value, see if its a job and company you would want to work for, then close the sale. Ask for the job.
Posted by slayemin on 02 January 2015 - 06:16 PM
I'm starting a small indie game project and I'm looking for an open source game engine to work with. I need open source tools because I want to allow community content in my game but most proprietary engines are not redistributable and make modding support tough. I need an engine that offer networking, decent lighting, an editor, and a common scripting language. Any suggestions are much appreciated.
Yeah... that's not going to be a small project.
Unreal Engine 4 supports all the things you're looking for, though I don't think you'll really need to dig into the engine source code itself. It's sort of open source, where you can download, modify, update and look at 100% of the code needed to build the engine, but you don't own the rights to do whatever you want (ie, you can't freely give it away or sell the engine yourself).
Posted by slayemin on 02 January 2015 - 01:58 PM
First and foremost, you don't want to get ripped off. You don't want to sign a contract which signs your rights away, gives up creative control, or gives up your intellectual property rights. So, be careful for any terms which may do so without appropriate compensation.
If they're paying you money to make this game you've prototyped, you should also keep in mind that you may not want to work on this game as a solo developer. You may find that a few months down the road, you need help in areas that you don't have a good skill set in, or you just have too much work for one person. This means hiring someone to work with you and that usually equals paying wages and that means you have to have a place for them to work, and that comes with some slight facilities costs. Whatever happens, you'll want more money than you personally need due to unforeseen cost overruns or future expenses.
That being said, since you're dealing with someone who you've never done business with before, you can't necessarily trust them. Especially as an international relationship. The simple response is to agree to some contracts, but what happens if one party breaks the terms of the agreement? How are the contract terms enforced in international law setting? It would be easy for someone like you to take the money and just disappear without a trace and there's very little legal recourse. Or, you could sign some agreement where you deliver a finished game and expect to get paid for it, but never do. I think, in a scenario like this, what would probably work best is some sort of milestone payment system, where you and the publisher agree on a set of milestones for the project, and you get paid each time you reach one. And, to get things started, you'd need some seed money both to start working and as a sign of good faith and commitment on behalf of the publisher.
Keep in mind, every publisher is treating your product as a risky investment. They want to make money off of it to recoup their up front costs, so you're going to get pressure to monetize the game. You'll have to explain to them how you plan to make money off of this, and if you don't, they'll plan it for you (and you may not like their monetization strategy).
Anyways, take my words with a heavy grain of salt. I've never worked with a publisher myself since I'm independent. But these are things I'd look out for.
Posted by slayemin on 31 December 2014 - 05:19 PM
Have you read the FAQ on the right? I know its easy to miss, but its got lots of valuable information for people just getting started.
I have two recommendations for you:
1) keep your first games SUPER simple. For a complete beginner, making a game like pong would be quite challenging but also a good introduction to making games. To accomplish that task, you have to understand the game loop, how to handle user input, how to display scores, how to trigger victory and loss conditions, how to write AI and where that fits in, how to move things on the screen in real time, etc. You can even accomplish this with a black background and white rectangles, no need for graphics yet.
2) The best resource for getting started is a solid book on beginning game programming. I recommend something on C# with XNA (ignore that its deprecated). Sure, books cost money, but who cares? You get super high quality content which has been vetted and compiled into a coherent series of chapters. Its rare to get that by reading online articles. If you really resist buying a good book, the second best starting place is probably over on Riemers XNA tutorials. He also publishes a book, which is probably better than his online articles.
Again, start super simple and buy a book. Every great project has humble beginnings. The first step is always to get something to show up on the screen. Good luck!