The OP's question was already answered, but to further explain, the type of Computer Science degree you get is based on which school runs the computer science faculty at the institution. Usually it will be either a Bachelor of Science in Computer Science (BSc), or a Bachelor of Computer Science (BCS). As an example, I went to Carleton University in Ottawa, It has a school of Computer Science, and therefore awards bachelor's degrees in Computer Science (BCS). When I was looking into universities I also considered the University of Ottawa, from what I remember it runs the computer science faculty through the school of Science. Therefore they give Bacherlors of Science in Computer Science (BSc). The programs were almost identical. Really it's just how the University structures their faculties. Neither would be more or less applicable to a programmer's application.
cardinalMember Since 02 Nov 2003
Offline Last Active Yesterday, 10:21 PM
- Group Members
- Active Posts 127
- Profile Views 1,741
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
cardinal hasn't added any contacts yet.
Posted by cardinal on 25 November 2013 - 11:24 PM
1) I want to say HELL NO! But it really depends on what you actually mean by episodic. I will still say HELL NO though since games like the ones you listed have upwards of 300+ people working on the game. I went to an animation talk by one of the leads on Assassin's Creed 3 a year ago and he stated that the development team size was over 300 people. Assuming you want to make a game 1/10th the size of assassin's creed, you would need 30 people for a year (this is really a rough estimate since 30 good people would be more than 1/10th of the productivity of that team). Assuming the average salary is $50,000 yearly (which is low for experienced people, but a lot of the 300 are low wage QA), that is already 1.5 million dollars and you haven't spent a dollar on marketing.
Another thing to consider is that while Assassin's Creed comes out every year now, the original definitely would have had a lot of pre-production time. Definitely more than 6 months.
Unreal allows for free use in lieu of royalties paid (I've never used unreal so I'm only going by anecdotes). The royalties are quite a bit for a big company, but for a small budget they are very reasonable and remove a lot of financial risk.
You really need to better define the scope of your project to get a real estimate of the work involved. If you know the size of the world, or the number of levels, and the number of characters, and the level of quality of the artwork (among countless other things including audio), THEN you can start to break down the game into hours of work, which can then be converted to salary. There are of course other costs, such as servers for version control repositories, and equipment.
Lastly, even if you did work out the cost and it fits your budget (which seems impossible to do if you have no experience), who is going to hire the employees? You? How would you know who can do the job?
2) It really depends on the scope of the game. A game with one character and one enemy type in one environment takes much less to build than a game with several main characters fighting dozens of enemy types across 30 environments. You need to define your scope. You can easily develop something interesting with one programmer, and one artist, but it's definitely not going to be on the level or scope of a AAA title. Going by your description, I would guess you'd need at least 5 programmers, 5 animators
, 10 artists, 10 QA members, plus whatever designers you feel your need (probably 1 for a team that small), all relatively experienced (and therefore pricey).
3) Because you've never worked on a game before, I would suggest it, and I would learn as much as possible from them. Or find a programmer who shares some of your passion and can help you clarify your designs into something the rest of your team can work with.
Other 3) If you don't have a track record, money talks. It's also best to have working prototypes, concept art and high quality design documents to show you're serious. I would strongly recommend hiring a small experienced team (i.e. an experienced artist, animator and programmer) and working on a very small (very high quality) vertical slice of your game. I would then use this to entice other people to invest (either through investors or some crowd funding campaign). Only then would I commit to hiring more people to build the final vision of the game.
4) I think your inexperience is mainly a hinderance in terms of hiring the right people. Getting a small competent (experienced) prototyping team who you grow to trust would be my suggestion as they could then help out in the hiring process when your team is ready to jump into making the actual game.
Posted by cardinal on 25 November 2013 - 10:50 PM
Generally system requirements are made for financial rather than technical reasons.
You need to be able to sell your game X number of times to break even. You know Y people have systems that are at least a certain level of power, you know Z people have systems that are at least a certain other level of power. You would base your target requirements based on the size of the audience you generally need to sell to in order to make money.
For indie games you generally aren't pushing any limits and you generally don't support varying rendering quality (no high/medium/low detail). In general you should probably pick a reasonable minimum requirement spec and use that as your test case.
For high performance games there is a great deal of work done up front to assess feasibility of your game. Each member of the team will work out the memory/performance/etc. requirements of their areas, usually using past games. If it's too difficult to assess, or there is no basis for comparison (i.e. a company's first game or a new engine), it is important to prototype all risky features to the level that you can accurately enough estimate your requirements. From these metrics you can scale your requirements to the estimated full requirements of the game.
Once the leads are convinced of technical feasibility only then will (or at least should) the team move forward, otherwise some sort of compromise needs to be made in order to fit in your chosen specs (either cut features, or change your target specs, or R&D how you can make it work).
Posted by cardinal on 25 November 2013 - 10:29 PM
Global (or World space, as I never hear it called global space) is the arbitrary coordinate system of your world. Let's assume there is no camera for a minute. Everything has a position, and if that position is outside of the viewport, you don't see it.
Local space is a coordinate system relative to some arbitrary point. A coordinate system in your main character's local coordinate system has him always at 0,0. Everything else is positioned relative to him.
The way you generally move a camera is to simply track a translation offset and apply that to your modelview matrix. This will automatically transform world space coordinates into your camera's coordinate system, which will frame the action.
Each object should move independently from the camera.
Generally in games you want to have a mainloop that does (at the very least):
1) read input
2) update game simulation
At a basic level the input is used in the game simulation to move your character (in world space. Their position is actually changing). Input shouldn't change enemies positions relative to your character. The enemies' AI should move them independently of input (again in world space).
When rendering you want to frame the action in some way. Here you can calculate the camera offset to frame your scene. Very simply you could center your character horizontally (calculate center point of your viewpoint, and calculate the distance from that center point to your character's position, use that as the offset).
Generally the camera shouldn't need to know specifically about game objects. It's just framing the action based on one or more reference points.
If you want to get fancy you can add logic to lead your character based on his velocity, but it all starts from the same basic logic.
Posted by cardinal on 11 November 2013 - 09:47 AM
AI Systems is a vague term. If I were to interview this person for a job, I would assume it meant he designed the framework in which the game's AI works as well as some of the specific AI features within this framework, and I would ask him to elaborate on it.
Posted by cardinal on 10 November 2013 - 02:07 PM
Do you have a business plan? Where is the money going? You need $10,000 to $20,000? Which is it? Why the huge disparity?
You are legally obligated to deliver your kickstarter promises, so don't ask for a cent less than you have worked out you need to finish your game.
Have you judged the viability of your idea? A lot of successful projects seem to have done legwork to drive interest around their game before the kickstarter kicks off rather than scrabling to draw interest once the kickstarter drive goes live.
Posted by cardinal on 30 October 2013 - 09:10 AM
Is it getting too long? This specific project is pretty big and I still have some more parts to write about.
Am I using the proper format? Is it okay to link to the source code the way I'm doing it or is it better to embed smaller parts on the page?
Is the video demo actually helping? Is it a good practice?
I'm not a native english speaker. Am I expressing myself correctly? (I'm aware there are some gramatical errors which I'll definitely clear up before going live.). Do my points get across or it just reads like a lot of gibberish?
A few comments:
1) I don't think it's too long per se, but I would try to reorganize it a bit better and create some spacing between sections and subsections. Have an overview with links to bookmarks further down the page, also have mini overviews for each section. I didn't have the same problem as frob looking at it, but clearly there is the possibility of confusion as right now it's a bit of a wall of text. Separating sections and having overviews might help break up the page visually better allowing people to process the information easier.
2) The video was cool. It might be better to embed the video on the page. I usually skim over text, but if I see an embedded video I'll be more inclined to watch it.
3) I wouldn't embed code on the page anymore than you are already doing. It would clutter the page too much. Just make it easy to view the source relevant to your sections for those that are interested.
Posted by cardinal on 30 October 2013 - 09:01 AM
It doesn't. Applying for an internship is the same as applying for a job.
Yes, I still interview interns the way I'd interview a regular candidate. You are competing with other interns rather than graduates/experienced workers, but you still need to distinguish yourself from the pack. You should prepare the same way.
Posted by cardinal on 22 October 2013 - 11:10 PM
Just a few suggestions:
-Remove links/references to games that infringe on copyrights. Including the zelda fan game linked in your cover letter. You can really only sell yourself based on your legal and/or original games.
-Your resumé and cover letter are too long. Be concise. Your employment history doesn't really have anything related to game design on it. This section should be for relevant work experience. If you don't have any feel free to include the most recent and most relevant only, and be concise about what your roles and responsibilities were, they don't need to know every task you performed.
-Your software and skills section is all the way at the bottom of your resumé, below the section about being trained in first aid and being a fire marshal. If I'm an HR person, I'm giving up before getting to your actual skills.
-The Always the Same Blue Sky logo at the end of the resumé is awkward to me. Why is it there?
In total your resumé probably should only be one page long, 2 including the cover letter, and the cover letter doesn't need to take up the whole page. Think of ways to sell yourself succinctly as possible, and then link to your portfolio and personal websites for more in depth descriptions.
In reference to your website, your games section has a lot of games to play with, but no screenshots or videos. It's likely no one hiring you will download your games unless you've already made it deep into the hiring process and they need to differentiate between you and another candidate. Have a quick way for them to get a taste of your work.
Lastly, one month is a short amount of time. QA is usually hired en masse at certain points during the year. So trying to get a job outside of those points is more difficult. As I said before Production/Design roles aren't generally entry level. There aren't really junior designer positions for the most part although things such as level designer are generally more junior. If a company was hiring externally for these positions they would probably advertise them on their websites and/or use a headhunter.
It took me 5 months to get a job after graduation, and even then it was only because I had a friend already working there refer me for a job. Knowing someone is the easiest way in, so keep in contact with old friends who share your interests.
Posted by cardinal on 21 October 2013 - 11:31 AM
*EDIT* I'm ultimately aiming for a producer/designer role but will take anything just to get my foot in the door!
So what job are you actually applying for? Does your cover letter/CV make it clear? I would think if it didn't that would be a quick way to have it filtered out. If you're applying for entry level you definitely still want to specify the job title you are applying for, rather than throwing shit at a wall to see what sticks.
Also, producer/designer roles aren't exactly plentiful and they don't pop up all the time as the people that have worked their way up into those positions don't really give them up too quickly without being promoted.
Posted by cardinal on 20 October 2013 - 02:55 PM
I don't find the conversational aspect too strange, but I think you need to divide it more clearly (i.e. create a "Dan" comic character and have him join the conversation rather than replying to the characters in your normal paragraphs).
What bugs me about the book though is that it has far too many spelling and typographical errors, and poorly structured sentences. Very unprofessional. It's as though no one has proof-read the book at all. You're and your are confused often, as are Where and Were, emersion rather than immersion, and countless others. You also choose multiple spelling for certain words on occassion which makes searching awkward (semi-colon VS semicolon for example).
I also found that you ask questions in the question section without explaining anything in the preceeding section and expect people to be able to answer. An example is the question on where semi-colons are used when there isn't a mention of semicolons in the entire section.
Lastly the about the author section has no mention of the games you have brought to market, which to me would be important to someone deciding whether to buy your book, in case you decide to sell it later. Why should I spend money on a book teaching me how to develop and market games if the author can't provide me with successful examples of his own work?
I can provide more feedback later as I've only read up to the coding section and I'm not the best person to critique the game design sections' content.
Posted by cardinal on 19 October 2013 - 12:21 PM
I think starting with a battle game would be a good idea. It focuses your development and helps from your scope running out of control.
It also gives you a solid place to expand from, for instance, adding a story (even if it's entirely text boxes in between battles), or adding an experience/level up/loot system on top of the battle engine. So you could ultimately decide when to stop developing your product. You could even take your battle game and port it into a full game if you decide to later on.
Posted by cardinal on 18 October 2013 - 10:54 PM
I've heard by different people that companies don't generally like to hire Game Designers
That's slightly incorrect. Companies will definitely hire experienced game designers. "Game Designer" is generally not an entry level job though. It is possible to get in as some sort of junior designer, such as Level Designer, but there are fewer design positions than programming.
The career path to become a game designer, is complex and not really straightforward. You can start in QA and work your ass off to get a junior design role, only to work your ass off even more to work your way up. You can even start as a programmer/animator/artist and make a transition to a design position. You can even be a domain expert (i.e. a retired minor-pro athlete on a sports game team). I've seen people go through all of these paths.
I don't want to discourage you from trying. I do have friends who got intern design positions and then got hired on as designers when they graduated, but these people are generally the exception, not the rule. Success always starts with working your ass off regardless of the path you decide to follow.
Posted by cardinal on 18 October 2013 - 01:32 PM
I disagree that it limits the character at all. In fact it could be a big differentiator between characters and tactics. For instance you might have a character that hits hard but goes through stamina quickly VS a high stamina character that does less damage and can be used for quick strikes, or to draw attention.
I like the idea of each action requiring an amount of stamina to act. It gives you the choice to blow through your stamina trying to overwhelm your opponent at the risk of burning out, or playing it more cautiously to preserve stamina and win a drawn out battle.
It also forces you to read the opponent's tactics a bit, so if they are playing a high stamina game, it might be better to withdraw, save your stamina and counter hard when they are tired.
Posted by cardinal on 17 October 2013 - 09:19 PM
What about magic defense? I would think certain characters have higher magic resistance than physical damage resistance.
Also, wouldn't you want a range of damage based on the relative attack/defense ratings rather than just being attack minus defense? Otherwise the game is pretty static in the sense that the same attack against the same enemy will always produce the same result.