Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Does anyone know ways to use GML programming skills to find or make work, such as freelance work using Game Maker?
I was thinking of doing freelance game prototyping work for people looking for a quick mock-up and getting the feel for their game, that can be done within a week or a few days.
If anyone has an idea, could someone please help me out? Thank you.
Personally, I started out using GameMaker as a hobby, and I've worked on some small projects for other people, but I eventually got hired as a website and database programmer rather than as a game programmer.
Unless you find a team that is already using GameMaker for its project(s), your experience with GML may not count for much on its own, as the language is only useful inside GameMaker itself. However, understanding GML means that you also have basic programming skills, and once you know one way of programming it goes much quicker to learn another.
GameMaker made programming easy and interesting for me, but other languages gave me the tools needed for non-game projects.
A company may not hire you based on the fact that you know GameMaker specifically, but it may hire you because you know programming. It could be wise to research other programming languages and learn the basics of how they work.
If you are to sell your skills to a client, they will likely care more about the end result than the exact road you took to get there. For example, if the job is to make a game that works on Android phones, that is something GameMaker can do, and by extension it is something you could do.
If GameMaker doesn't seem like the tool for the job, use what you learned from GameMaker to help you understand a different program/framework. Even if you focus on GameMaker, you may need other languages if you are to set up an online game server or scoreboard.
A lot of successful games have been made with GameMaker, so it's definitely possible to make a living by using it. The Showcase section on the official homepage shows us games like Hotline Miami and Undertale - big hits in the Steam store.
This article from GameMakerBlog.com lists a few people who's made it big. Most important, I would say, is "True Valhalla", who gives the community running updates on how his business is going. You can find his blog linked in the article. He has written a book about how to make money by selling apps and games, which could be well worth checking out.
If you wish to focus on freelance work using GameMaker alone, then make sure to understand the ins and outs of the program so that you can be as flexible as possible. Make sure that you understand how the movement functions work, how to do collision checking, how to work with data structures, how to work with views and surfaces, and so on.
The technical skill doesn't need to be perfect, but you need to have an idea of what to do and how in order to realize your ideas within a reasonable time frame. Practice until you feel comfortable taking a game from concept to demo in a short time, and build a collection of examples and engines that could be useful to you. If you can reuse a script, that's a lot better than writing it from scratch for every new game you make.
Finally: Marketing yourself. In order to become attractive to potential clients, it helps to demonstrate your expertise by publishing your work online. Make yourself visible. Post screenshots, videos, and playable versions of games you've made. You could blog about game development, or build up a small profile by helping people online and getting credit for it.
Any project you can point to and say "I worked on this" makes you a more credible developer. If you are just starting out you may not have any projects yet, so one suggestion would be to make a small mini-game and publish it in an app store. You may even publish it for free. For your first games, exposure could be as valuable as sales.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am interested in programming for games. I am currently building an iphone game with Shiva using Lua as the scripting language. After that, I am not sure what I should do or what languages I should learn. My goal is to keep building games but I also want to build my own game console. Of course, that won't be for years but I need to learn something right programming now. I know that programming games vs applications is totally different and that's why I need some help. What languages or things do you recommend for me to learn? I also want to be able to create applications but programming applications and programming games is a whole different thing.
The first game I ever wrote was a snake game written in Turbo Pascal. I was fiddling around and managed to get (using a series of dots) a line moving across the screen. Once I did that I made the line change direction. I hooked that up to the arrow keys and got excited. Two hours later i'd gotten a different coloured dot as 'food' up on the screen and it was a game of snake. Each game I wrote pushed me further and forced me to learn new things (ideas tend to roll on from one another.)
Try and stick to arcade style games. Breakout, Pong, Snake, etc. The amount of time it will take you to build Halo doesn't bear calculating!
Don't worry about which language you learn. You will learn many over the years. Right now is the time to ask which is easiest to start writing games with. If you already have the basics of C, then that's your answer straight away.
If you have no idea where to start, start doing animations instead of games. Ideas will come once you get used to your tools.
Write a program that draws a smiley face in the middle of the screen. Changing screen modes and using big graphics engines might be overkill for this. Keep it simple. Get that smiley face to move around, change it's colour, make it an unhappy face, etc. Before you know it you'll pick up some good momentum.
The question to ask is how do I write a smiley face on the middle of the screen instead of just on the next line in the console. In my first snake game, the answer was to write a load of space ' ' characters until i got to where I wanted. The better answer, apparently, is ncurses. If you are on Windows XP then the MingGW compiler is free you can get the (non-standard) conio.h library. That's what I used in my second snake game and it will get you started very quickly.
Good journey!
Look into modding.
I found QuakeC (how Quake1 mods were made) to be really easy to pick up, and you already have a very rich base of game content to use so that you can focus on gameplay and such. I found it a lot easier to stay interested when you're starting with a fun game and adding your own twist to it, rather than starting out making 3d box demos or other overly simple but needed low level programming steps.
Quake1 is pretty old but has the upside of pretty much everything involved in it being open source and free to extend. You could just as easily start modding any of the newer games out there.
A lot of todays big name game shops got their start making Quake or Halflife mods.
Having worked in the industry for several years, this is the best summary I can find:
http://gamesfromwithin.com/so-you-want-to-be-a-game-programmer
My advice:
Learn C++ inside and out. Program in it every day. If you're already set up for iPhone development, learn OpenGL. It wouldn't hurt to learn Direct3D as well if you have access to a PC ( also have a look at XNA ). If graphics isn't your thing, make sure you know how pathfinding (A* algorithm) or collision detection works.
Keep building your own projects, and find a good online community that can support you if you have questions. Employers want see that you are smart, but more importantly, that you are dedicated - game programming is very hard, don't let anyone tell you differently.
You can download free development tools for Windows here:
http://www.microsoft.com/express/download/
The one you want is Visual C++ 2008 Express Edition.
Perhaps check out some of the game programming links here: http://lazyfoo.net/SDL_tutorials/index.php
Those tutorials assume C++ which is used a lot in games programming so may be worth learning.
Or you could check out this tutorial if your interested in Java http://www.cokeandcode.com/node/6
Adam
You should check out Unity3D website. They have now a free version (named Unity) for personal and commercial use. You can use scripting with C# (possibly any .NET language), JavaScript, and Boo.
XNA would be a good fit too.
When you're just starting out, C, C# and C++ might be a bit complex to start with. If you're serious about game development, you will probably need to learn C++ eventually, but if you just want to quickly get some things done, you're already on the right track with lua.
Javascript is another language which is very similar to lua in many ways (and very different in others). One advantage of javascript is that everyone in the world has javascript installed on their computers. Another advantage is that it's very easy to learn. There are disadvantages too, but they are not nearly as bad as most "serious" programmers think. Javascript gets an undeserved bad rap.
Here is a very good tutorial for learning javascript:
http://eloquentjavascript.net/
It does not cover games programming, unfortunately- But it does cover concepts that are relevant to both games programming and application programming.
Here is a tutorial for javcascript that does cover games programming:
http://billmill.org/static/canvastutorial/index.html
you will need a web browser in order to follow that tutorial. This does not include internet explorer, so you will probably want to use safari, firefox, or opera.
Once you are comfortable making games in an easy language like javascript or lua, then it will not be quite so hard to learn to make games in a hard language like C or C++.
On the other hand, you might be happy just making games in the easy language, and that's okay, there's no rules that say you have to learn C or C++ to make good games. Good games come from good ideas, not difficult programming.
Priority Order for a game programmer.
Any subject that needs Analytical thinking and Logical Problem Solving.
Necessary knowledge in the following domains.
Mathematics
Data Structures
Computer Graphics
Physics
Artificial Intelligence
Computer Networks
Web Technologies
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've been in the business of developing hardware and software for 19 years now. In the earlier days the projects and teams I worked on were smaller, much more effective and more fun.
The effect of the input of one single developer to the final product and to its success was evident to everybody. We had direct contact to and feedback from the customers. This was rewarding for our work and a very effective way to improve the product.
With the years the complexity of hard and software increases and more and more people were needed to get things done on time. The downside of the trend to bigger teams for me is that the contribution of a single developer to the project success gets smaller and smaller. And we lose the contact to real world of the users and customers because of growing QA departments more and more.
I always enjoyed my work and kept in touch with latest technologies like OOP, UML, .NET, and whatever. I already worked a few years as a team leader but I didn't like it very much because I missed developing and coding.
I'm just frustrated about the fact that my piece of the whole "thing" we're working on gets smaller and smaller and I lose the overview about it and the contact to the ground. Please don't understand me wrong, I don't want to cry for the good old days but for me the work on more and more specialized sub modules of a giant system simply gets more and more boring.
I'm wondering if I'm alone feeling like that and maybe if you have some advice how to bring the fun back to my work. And sorry, no, I'm not interested in working on an open source project in my free time. Nine hours a day in front of a computer screen are enough, life is more than coding...
I also require interaction with and feedback from the customer. However, a customer can be many things. As long as I'm satisfying someone (end user, team leader, big boss, etc.) then that's enough for me. The interaction itself is the key factor.
As for the feeling of pride and ownership from having a large impact on the system, again it's a matter of focus. You are still creating something, even if it's a smaller piece of the whole.
I long ago realized that I'm a small fish in a big pond. Learning to feel happy about my place in that pond was the only solution.
IOW, it's all relative!
I guess it all depends, there is a degree of camaraderie that comes with smaller teams and a lesser chance of ego's colliding. I have experienced both and they both have their upsides and downsides. To be honest, while working on a larger team I learned so much from other programmers, you think you know a lot, but someone always knows more.
It all depends on the team and the egos of the individuals.
When working on a team with ego problems, it doesn't matter how cool the technology is or how much interaction you get with the customers. One bad apple can drain all of the fun out of working on an otherwise cool project.
On the other hand, if the team has gelled, it matters very little if the technology is out-of-date, or the business problem is boring. Working on an back-office accounting system using VI and 10-year-old beta C++ compilers can still be invigorating when you feel like your peers are in the same fight and have your back. When you learn from others and are listened to when you have some new approach to try. When the developers control the build/test/deploy process so that it's sane and improves the lives (and sleep patterns) of the support team. When your peers (and you them) are always willing to help with an obscure language issue or work through a maddening bug. That what makes programming fun and interesting regardless of everything else.
You may want to consider changing companies back to a smaller company where you had a broader set of responsiblities, for one idea. Also, what are changes in the process that would help with the points you don't like?
I do have the question of what you mean by large here? Would a team of 50 people in a project be large? Or is it more like 1,000 to be large? On one level I'm asking for scale as there are teams beyond large if one wants to look at all the developers that work on Microsoft's big products like Office and Windows while at the other end of the spectrum are the one person development teams that do it all.
I'd second Kelly's answer that it depends on the team and egos for another big factor in things. What do you consider fun? Is it finding more efficient ways to solve problems that have poor solutions? Is it conquering a Millenium puzzle? Or is seeing someone smile while using your software what makes it fun? Lots of different possible answers and while I can make suggestions, how good or bad they are is totally for you to interpret.
I don't think you're alone in disliking how as a company matures the process can change as new people in various roles are added with increased bureaucracy and losing agility as it may take more signatures to get a change to be allowed or developers lose that touch to the customer of their product. There is a spectrum of various ways to produce software and some places may have less process in place and be focusing on "just make it work" while other places may want the process to be much more formal and organized with 1,001 policies for every little thing. At which end do you want to be working?
To answer the question as it's asked in the title: No!
I feel very similar and talked to many others who think the same. From my experience small teams are much more fun to work with and by that (and some other reasons) they're much more effective.
Thank you all for your interesting and valuable answers (and for correcting grammar and spelling :-)
You gave me some big points to think about:
The missing interaction with custumers (whatever "customer" means)
The interaction and feedback inside the developer team
What means fun for me. I think its more the smile in the face of the user than the use of cutting-edge technology.
How to deal with the sometimes overwhelming processes.
Last but not least to find my comfortable place in the big pond. It may be not the one where I'm staying at the moment...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
Where I work we've recently put together what we call the Development Standards Committee which is tasked with improving our procedures, processes, methodologies, tools, standards, and whatever we think would help us become a more effective team.
We've got a spreadsheet of items that we've ranked and are going to start tackling from the top down. We've got things such as better source control (currently on SourceSafe), implement a bug tracker (such as Mantis of FogBugz), peer code review, move to .Net 3.5, possibly move to some form of Agile, do more actual team development rather than single developer per project type stuff, and some other things...
What do you think are some key things that can make or break a development team? What should we add to this list?
Some additional information: We have about 12 people on our windows team, and about fifty in development if you include all platforms. We want to improve as much as possible for everyone, but we're our biggest focus is the Windows team. All of us have been here for a couple of years at least, so most of us know each other and work together pretty well.
The number of people on your team is actually really important here. There are basic things that every team should implement (source code control, bug tracking, etc), but there are things that are different base don team size. Code reviews on a very small team, for instance, can be more informal.
Moving to Agile is a good idea, unless you're particular development environment makes it a bad idea. Also, you'll not be able to do this without support from the people who are using your software.
Consider doing things to ensure that communication between the team is easier and with less roadblocks - do all your members know each other pretty well? Can you work with each other? Do you understand each other's idiosyncracies? Learning to work as a team is much more important than any random process improvements you can make.
Require comments when you check in code (it's great if you can tie commits back to your bug tracker)
Maybe Static Code analysis, like what's built into Visual Studio
Continuous Integration like CruiseControl
Development teams really need good people to start with, that work well together, but this isn't really an item to add to the list. It does however affect my first recommendation, be pragmatic. If you're not encouraging your developers to think about how they work and can drive them selves to improve, it's really hard to lay down a development environment that will do it for them.
Mentor and Training: If you can't do XP, then at least hook up your Juniors with Seniors whenever you can. Not only will you share knowledge but you'll share the context around your projects you own.
Some sort of Continous Integration and regular, tested, working "releases" make wonders for quality.
as better source control (currently on SourceSafe)
If this is Visual SourceSafe -- you need to change this immediately. Try cvs, svn or even something paid like Perforce.
There exists something called Rational Unified Process that deals with your problem (and much more).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Yesterday I had a team leader of another team say that they took a while to figure out something I wrote on a wiki page because I referred to obtaining code from source control as "checking out" which apparently confused them. They said that they were use to Clear Case and had only heard of the term "joining a project" and said that they haven't really programmed much for a long time.
While this is fine, what it then made me think of is the different types of team leaders I've had over the years. I've had some that have been almost purely managerial and I've had those that are programmers that do managerial things at the same time.
Do people have a preference as to what kind of team leader they have? How do you care if your team lead is active in the development of your product? I find team leaders who actually sit and code like the rest of the team more likely to understand things like (from my experience):
things aren't always as simple as they sound. Team leaders I've had who don't code or rarely code at all believe everything is a piece of cake and shouldn't take much time at all (which perhaps might be the case if you want to hack it together)
they are more understanding that developers don't always like sitting in long meetings and do their best to avoid getting their team into as many pointless meetings as possible
they understand what you say from a technical point of view. Those that might not have coded for a while might not be up to speed with a lot of the new technologies, techniques or lingo
I find it much more satisfying to have a team leader who has the mind of a developer and likes to get their hands dirty in the code as well. Perhaps there are some people out there that like team leads who distance themselves from the actual coding side of things and simply doles out the work, or perhaps another type of team leader that I haven't mentioned?
A team leader has to be a coder -- they can't lead the team unless the team respects them and where they're taking everyone.
A team manager, on the other hand, can either be a coder or someone who is just well organised and knows when to ask questions and interface to other management.
It is possible to find both a manager and a leader in the same person, but more often the roles (should be) separate and distinct.
You should read the book Managing Humans. I am of the opinion managers should keep their hands out of the code. They have more important responsibilities like keeping people away from developers, so they can do their job. Having them jump into development creates confusion as they aren't in it enough to know what's going on and have their time divided between that and other things, so it is difficult to count on them for major pieces of functionality. Plus, it really sucks when you have to tell your manager that something they just wrote needs to be changed, and you have to go back and redo it. Managers are really their to jump on the grenades for the rest of the team, so they can focus on accomplishing the task at hand.
That being said, should manager's know about software engineering? Yes of course they should, that's the field they are in. Should be know how to code in the latest and greatest whiz bang technology? That shouldn't really matter as long as they get how software development works.
I have no preference, I can't, I have to work with all of them, even though too many cooks spoil the broth. On a multi-developer typical project I have a technical lead, project manager and a non-technical customer. Of course, divisional and programme management will each stick their head in.
There are a number of types of leader, each have their own traits:
Non-technical customer: "The customer is always right." Often wants a moon-on-a-stick. Will call both the management and the technical bods and take the best answer as gospel.
Team manager/line manager: Somewhat pastoral role. Not particularly interested in the project I'm working on right now. Steps in when there is a decision to be made between project priorities. Probably really wants to be a coder, and delegates all the rest of his work that he can to his subordinates.
Project manager: Varying degrees of technical know-how. Is concerned only with timescales and costs. Does not understand, "I don't know how long its going to take, I need to play with it for a couple of days first to get a feel."
Team leader/technical lead: Just another developer, but with more experience. Responsible for technical decision making that will affect the whole project. Often fighting with the project manager to carry out good engineering practice, even though it will take longer in the short term.
Team leader/glorified secretary: Someone who is supposed to lead the team, but acts as more of a secretary. (Usually a grade above the team). Answers the phones, insulates customers from the technical bods. This works fine until they ask a technical question, where the glorified secretary tries to blag his/her way out of it, and eventually they work around the secretary and talk direct to the team.
We typically have a PM (non technical) who manages the project from an admin. viewpoint and a Tech Lead who manages the technical aspects and provides technical leadership to the team.
The Tech Lead will code parts of the project and will probably be the main (only) developer for the "Proof of Concept" stage.
On some smaller projects, they are the same person but it's a rare combination.
The absolute worst Software Leads/Chief Software Engineers that I've worked with were the ones that wanted to be intimately involved in the technical details. Too many important tasks were either missed or just not done. Managing a team is a full-time job. If the lead wants to get involved in the technical aspects it will certainly come at the expense of the managerial aspects.
I’ve only had 2 Software Leads/Chief Software Engineers out of dozens that I thought were worthwhile. While both were previously software engineers, those days were long gone for both of them. They knew it. They didn’t even try to pretend. Their job was now to manage. Their job was to make sure the developers had every chance to succeed. They did their best to remove all obstacles and make sure everyone was making progress.
I have a theory, but have never seen it in action, that the best software lead would be someone who is not, nor ever has been a software developer. They specialize in the true spirit of management, specifically that of being a facilitator. Unfortunately, most managers are more politically motivated or are just in the job because they've reached their pinnacle technically.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.
Have you any recommendations for improving the the quality of input from the functional people?
Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
I understand that the people you call functional people are acting as Product Owners, right?
I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.
How can you estimate the Backlog item if they are not detailled enough ?
You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.
If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.
Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.
Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.