We're offering banner ads on our site from just $5!
cardinalMember Since 02 Nov 2003
Offline Last Active Nov 19 2014 09:48 PM
- Group Members
- Active Posts 160
- Profile Views 3,390
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
cardinal hasn't added any contacts yet.
Posted by cardinal on 22 September 2014 - 10:00 AM
Start ups might use agencies rather than spending money on advertising their positions.
Is there a reason you can't do both?
Posted by cardinal on 22 September 2014 - 09:55 AM
With that said, I wouldn't personally reject someone based on which school or program they went to.
Posted by cardinal on 22 September 2014 - 09:42 AM
You cite pro evo using fake names when they don't have licenses. EA has recently settled a lawsuit with college football players regarding using their likenesses. They used fake names as well, yet they still were taken to court. While EA technically didn't lose the lawsuit it still cost them millions of dollars in payouts and legal fees.
You really need to have a lawyer assess your risks of litigation and you need to be ok with those risks before proceeding.
Posted by cardinal on 22 September 2014 - 09:31 AM
Posted by cardinal on 14 September 2014 - 10:14 AM
Are you all working locally or is your team distributed? Knowing each other face to face often helps. I'm sure you've seen how strangers behave on the internet.
Posted by cardinal on 22 June 2014 - 10:23 PM
A lot of high end engines are moving to node based approaches. The new Ubisoft Snowdrop (is that the right name???) does judging by the videos they've released, UE4, and most of the proprietary AAA engines use such an approach these days.
The most time consuming aspect of making a AAA game is content creation. You need to empower content creators (artists, designers, etc.) to build simple behaviours. You need to spend your SE time on difficult technical problems to set your game apart, not on grunt work scripting simple behaviours like windmills spinning and AI behaviours.
What are your goals with this? If you want to make money, you will probably need to find a niche. Maybe UE4 is more comprehensive and powerful, but if you can find a niche, like "much easier to use" for simple games or apps you could steal a segment of the market.
Posted by cardinal on 29 May 2014 - 12:24 AM
You'd really need a lawyer to advise you on this. From what I have seen in the past:
Games often will parody existing characters or other IP(not a true representation), and usually get away with it. Likely covered under Fair Use:
This Fair use is an exception to copyright, and likely won't cover accurate representations.
EA ended up attempting to do so in Battlefield 3 using real world helicopters without licensing them. They were sued and used the defense that it was Fair Use and also covered under first amendment rights. EA eventually settled the lawsuit, so we don't exactly know what the outcome would have been.
A lawyer experienced in intellectual property could advise you better on whether they think your usage would be covered under fair use. But remember, even if your lawyer thinks it's ok, you may still have to defend this in court which you probably don't have the money for. In EA's case, they have the money for that, and they likely intended to set legal precedence in such cases which would have greatly impacted what game companies could and couldn't do moving forward.
Posted by cardinal on 27 April 2014 - 01:59 PM
As a disclaimer, I have no problem with people modding games, even any game I put out. However, to play devil's advocate I would never release save files in plain text.
It's a matter of quality control. Are you going to quality test every possible unreasonable value a user can enter into the different fields? Sure, you can clamp them within reasonably testable ranges, but doesn't that defeat the purpose or letting people modify the file? Who's to say that giving yourself 110 health doesn't result in an issue that causes the player to be unable to finish the game?
In general people that crack games/write trainers/etc. will QA their own work. Force people not technically inclined to use the trainer programs (or explicit instructions) to modify their save files instead of them shooting themselves in the foot and blaming you five hours down the road for your game not working. Most players aren't (and don't want to be) game developers.
I would actually argue that leaving files written out in human readable formats requires more work than just writing the files in binary since you have so much more to QA.
Posted by cardinal on 27 April 2014 - 01:43 PM
Building games (and game technology if that is your interest) is my recommendation. Practice is important. Through doing, you find the areas in which you are lacking and you can work on it.
On top of this, books and articles are useful to fill in your knowledge gaps. I don't have any specific titles as I don't read many books nowadays, but any books on the topics you are interested in would be useful.
You'll eventually find out your areas of interest (i.e. rendering, AI, character animation, physics, etc.) and you can start researching those topics more in depth, and targeting your projects to work on these skills (many professionals are only skilled in one or a few areas). At this stage I find it is more useful to dig into books and papers. I find the "Learn to program games" style books are fairly poor in general and are not detailed enough, plus you can generally get just as good information for free online. Books on domain specific topics are generally better and provide adequate detail to actually learn from.
At your stage, you'd probably want more academic books, rather than practical game programming ones. A good reference book for C++ (or whichever language you are working in) is useful, as well as a book on data structures. If you're not interested in reading books at this stage, google and sites like this are great for asking specific questions on problems you're having. You'll cover the other topics in post-secondary school anyways.
Posted by cardinal on 16 April 2014 - 02:49 AM
Is writing a binary file really going to waste development time? It's not 100% secure obviously, but it will eliminate most people from modifying their save games.
I'm with Satharis on this one though. Save files are not intended to be messed with. If you want to offer modability to your players you should design for it up front and provide the tools for it.
However, since the OP didn't ask for my feelings on the matter, that's all I'll say.
So, to protect a local save file:
-Learn to read/write to binary files
-Encryption can further obfuscate your save data, but at what cost? You'd also better hope there's no bugs in your encryption and decryption code.
Beyond this you'd really need to save to a remote location (server) to prevent people from messing with their save data. If I had a binary save file, I could probably track what my game state was when I saved, open the binary file in a hex editor (or even notepad) and try to identify values that match what I expect (i.e. I had 50 health, back up my save file, open the original up, find some value that is 50, change it, save it, test, and repeat until I've solved how to change my health in save points). Encryption would pretty much make this approach useless unless I knew the encryption algorithm, and would require more in-depth efforts to crack the save file.
The more protections you put in, the more diminishing your returns are (i.e. maybe 0.1% of users would crack a binary file, but only 0.01% would crack an encrypted binary file, so if you have 10000 users, 10 would be able to crack the binary file, and only 1 would be able to crack the encrypted version. So you eliminated 9990 users from messing your game by writing to binary, but you only prevented an additional 9 from messing your game by encrypting the data). And once it's cracked, the person who solved it can give step-by-step instructions (or a tool) to let the less tech-savy users modify their own save files.
Posted by cardinal on 16 April 2014 - 02:27 AM
I've built a couple level editors.
A 2D tile editor (just recently - still in development but it does most of what I need), and a full 3D level editor for my undergraduate project at university.
Level editors are a lot more complicated than they initially seem. You need a good chunk of the game's functionality in the editor itself along with a lot of extra functionality on top. Top of the line editors usually are fully integrated into the game and you can jump in and test your level almost seemlessly.
At the very least you need:
-Other interface code (picking, multi-select, user friendly features like undo/redo for all of your operations)
-Rendering code (you need to render the textures you load and the tiles you've placed, and any other entities you've added)
-Asset management code (texture/tile/shape/entity loading/saving/adding/deleting/exporting)
-Simple camera code (you need to navigate your map somehow)
There are probably a lot of things I forgot to add here. For 2D games I like to be able to drop a character into the editor and move around testing the collision detection and layer transitions (i.e. going up stairs), this requires including more things into the editor.
Posted by cardinal on 04 April 2014 - 12:10 AM
Is controller support out of the question? Or are you looking specifically for keyboard only controls?
I would imagine if you support controllers, you would just plug another controller in and player 2 gets the same input as player 1 without having to share a keyboard.
For allowing players to specify their controls, you would build a screen that lets each player map a physical key to a virtual button and do some sanity checking to ensure there aren't missing or duplicate mappings. The mapping could be as simple as an array that maps a physical key ID to a virtual key ID (you would have one mapping for each user or gamepad). When you process the physical inputs you would write to your input buffer, When you want to see if you want to perform a certain action mapped to a virtual key, you would look at the physical key state mapped to the virtual input and act accordingly.
Posted by cardinal on 08 December 2013 - 10:06 PM
I think "Open World" is a term that causes a lot of confusion. Building a game of GTAV or Assassin Creed's calibre is NOT in any way achievable by one person. There are thousands of art assets. Hundreds or thousands of animations (depending on animation requirements and how many types creatures that have their own rigs there are), hundreds of sound effects, hundreds of pages of recorded voice acting, dozens of hours of scripted quests, and more. That's not even including the programming requirements.
This doesn't mean making an open world game is impossible for one person (one as deep and as detailed as the AAA titles however would be). If you develop a fairly detailed design document, you can break down all of the assets you need, come up with time estimates it would take you to make the assets, or code the feature, etc., and see roughly how long making the game would take. If it's too long, revisit your design and scale back.
I personally don't think having a "dream game" is a problem. I have lots of dream games that are completely unrealistic for me to build (and I've build AAA games for the last 8 years, so knowing how to do it is not the issue). Sometimes working on my dream game gives me ideas for my other games. The problem is if you let your dream game stop you from working on achievable games, or from learning.
Posted by cardinal on 02 December 2013 - 10:32 PM
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.
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.