• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

catslap

Members
  • Content count

    22
  • Joined

  • Last visited

Community Reputation

39 Neutral

About catslap

  • Rank
    Member
  1. ,
  2. Nice to see a simple but interesting question get discussed in detail tbh.
  3. I'm warming to trello/gitbucket and skype to the point I'm dropping microsoft project and Jira. Trello gets better and better the more creative you get with it. Very impressed.
  4. it helps a lot to write a small program which has a variable, set it then printfs each of the options to the output. Then nose at the debugger for the value, the location etc, get your head around it properly.
  5. I got introduced to trello today and like it, look at this also, I think I'll be rolling it out across the board and it's free
  6.   ^^^+1 was beaten to it. Well said. So many whiney little princesses. Software is a great profession!
  7. ah, sorry Samoth, I misread that as if you weren't sure how quality standards are met. Now I see you do! It's been a long day 
  8. If I didn't know that this is exactly true and if it wasn't so sad, I'd say congrats on an excellent joke.      mostly our stuff is safety critical, it's a legal matter, as in you go to jail or pulled up on corporate manslaughter if mistakes are made. Reviews are logged with your name at official bodies, every last test result is recorded and signed in triplicate. Every line of code is scrutinised. The restrictions on what you can do with the languages are huge. It can be miserable at times.
  9. None IMO (not gaming though). A job you can take on freelance at huge rates, take months off each year, with virtually zero overhead in terms of tools (laptop, couple of licences mosty your client covers), can work remotely from a beach anywhere in the world over the internet and skype/vpn and is intellectually challenging. The demand is huge and keeps growing, rates are rising dramatically (30% so far this financial year), There's no hard labour and on the whole you can leave the office and not really care much until the next day. Get to browse facebook and email without anyone really caring. Free hackspace and labs, a team to support you and one of the only industries I can think of where you get supported if you have good ideas and want to go it alone (providing you play it right!). A super easy going environment out of the rain.   I've no idea why guys self-flagellate and whine, it's the easiest gig I've ever known except for maybe slinging drugs, but software has no risk of going to jail. It's sweet.
  10.   It's a bit deeper than that. The coding standards are legal standards, and go off to a lab to get certed. You can break a rule, but it means getting in both reviewers, and  senior manager  booked for a meeting(costly, and pisses people off, although there's biscuits), then a document is written justifying the deviation from standard (costly and boring, massive waste of time and resource), then the certification lab want to check it but charge more (maybe £6k). Basically if you pull that 'clever' shit you can consider yourself unemployed pretty quick. They canned 12 guys on NYE no warning, another 4 last week, all for bad business practice, they were probably adequate coders, just didn't understand the industry.   There are times when you get pulled in to make something uber efficient, like context switching on a blistering fast fpga, but mostly, write it like a muppet can read it and you keep on getting paid.   I do like that loop though :)
  11. yeah, the second parameter for a for loop is a logical condition, the use of the decrement operator will bring it to 0 (logic false) which breaks the loop.   It will fail the review, there's no way it's getting into production code, readability is everything,  I did consider breaking open the assembly to see if there's a performance difference between that and a while loop but there's no need, they'll (probably) be the same .   Although it's nice to see someone who demonstrates a slightly more intuitive knowledge of the language. 
  12. for(int i=10; i--;) { /* do something */ }  I quite liked it. although still getting rejected from review.
  13. It depends hugely on the type of job you have.   I'm a consultant, my main project currently is mostly made from consultants.   The teams are managed through bidding on tasks on a time to complete basis. New guys don't get to take part, they're usually given over the shoulder jobs or more traditional tasks and closely monitored and helped so it's not overwhelming.   The permie guys probably work 42 hours a week, we generally do 37.5, they keep us down as the rates rocket up to double after 38 hours.   LOCs doesn't really reflect productivity, I might remove 100 lines and improve the code.   If the work is quality related, 2 locs/day might be normal, you'll spend most of your time in meetings reviewing the code, planning the code, modelling the code then liaising with guys around the world who will test the code, then referencing the test results against the model and writing documents to show why they're different. If it's not high quality work you might get to code for maybe half the day, meetings, project discussions and general crap takes up the rest. If you're working for a small games co you might get to code almost all the time.   With quality work everything will be mapped out for you, there's very little innovation or autonomy. Non-quality can be hacking away all day long with no-one bothering you and you have almost full control. Where your work interfaces with someone else's that will be defined (or you'll have to define and document it).   An average day for me if not flying would be arrive, get coffee and check the overnight test results as I wake up, skim over the version control logs to see who has branched what and what's been merged in. Check the build still works. Reply to emails regarding the results, usually interrupted by a team meeting to discuss progress and deal with any emergencies (you might get flown out to do something exciting here but usually not, maybe twice a month) Code for an hour or two until lunch. After lunch peer review someone's code, or help the testers or calibrators with the new software written from the day. Or assist the hardware guys if something is looking dodgy. Some days are spent doing pure architecture, but mostly not. There's quite a lot of interacting with non tech people which is amusing but can get frustrating.   It can be quite glamorous, usually it's not.   The better you are, the less likely it is you'll be coding much tbh, you tend to get pushed up quite quick and away from the development into more overreaching tasks, which can be frustrating, coding can be a rare treat with some contracts.
  14. I think it was called basecamp, it looks like it costs (no idea what). I think evernote is a pay service to both have access too.    Google for free collaboration tools, there'll be something similar I'd imagine. TBH the google drive share isn't that bad if you were organised about it.
  15. It's might be wise to incorporate as something mundane then use a trading name as the one people see.