• 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.

Memir

Members
  • Content count

    238
  • Joined

  • Last visited

Community Reputation

129 Neutral

About Memir

  • Rank
    Member
  1. Oh and I've worked for a dozen different companies. This is the first to advocate pairing and it's mostly confined to our team.
  2. Thanks for your replies, especially frob. Yes I'm a very critical person, and take much time to try to criticise my own work. Asking questions such as how much work I'm doing vs how much bugs I introduce etc. In a nutshell, the problem can be see one of two ways. 1. The management are not taking the (right aspects of the) project as seriously as they should be. Instead of hiring weak developers, and developers who have no passion beyond doing the minimal amount of work to maintain their job. They should be hiring the best in the industry. They can afford it after all. So it's a tremendous waste of resources. 2. The problem is with me. My standards and expectations of the project are in realistically high. I want a product that will dominate the industry when it's released. I shouldn't care about my work, beyond the paycheck. I do sometimes move to position 2. But then it makes me feel soulless, that a big part of my life (work) is just a waste, an exchange of time for money. The projects which I'm most proud of are the ones where they have affected other people I.e. The masses and I can tell my friends 'I worked on that'. Makes me feel like my job had a real purpose. For what it's worth. It's hard to accurately measure productivity in this industry. But for line count I write at least 2 times as much code as the next person. While I seldom break the build. When there are bugs found, it's very rarely my area of the code, and when it is. It's usually very trivial to fix, mostly turns out to be a requirement that hasn't yet been complete rather than a real bug. It's real simple. I'm just a lot more experienced and faster than the others in the team. It happens. They pay my bills & pay a lot more than my previous company (despite work being far easier). So I go with it. But I employ various strategies to minimise the pairing. Even if it means agreeing with another co worker to say that we paired on a task. Essentially lying. If I did pair properly. I would probably quit as it's not good for my mental health. Time + pain = money is the equation.
  3. Thanks for the responses. I would like to apologise for the wall of text in the original post. I wanted to rant, but also focus on making mostly objective. But alas I'm very passionate about programming, software and especially the currently project I'm working on, and got a bit carried away.   Yes, I think the problem with our project is that the chief proponents of pair-programming are the Scrum Masters (who have no technical experience, and zero programming experience). I feel that many of the developers are political brown-nosers, and don't really care about the project beyond following the Agile process & whatever the mighty Scrum Masters decide (as they are responsible for the hiring & firing).   They are suggesting that we should all pair 100% of the time during a sprint. I feel this is simply not practical, and is a massive waste of resources. Most programming isn't rocket science, and companies should be hiring people that are qualified to write decent code. This latter point I think is the problem.   The only real benefit I can see from pair programming (that can't be gained so well from code-reviews, and just calling someone over 5-10 mins to explain something to you), is that of training/mentoring someone less experienced. For this, it must be established before pairing, not who is the Driver & who is the Navigator. But who is the Student, and who is the Teacher.   I simply feel, and I may be wrong. I'm just the 'programmer' after all, no one tells me the big picture. That if you have a project which is so important, which you simply cannot afford to mess up. You shouldn't focus your efforts on training graduates, leave that for another team. You should be hiring the best in the industry, and let them focus on priority number 1, which is delivering a kickass product!   I find I can just read code to learn new ideas and approaches to problems. Only thing I learn from pairing with someone else is: How fast they type, what keyboard short-cuts they use/don't use, how often they are distracted, their thought processes. If I were the project manager, then it might be useful, as I could find out who were the effective programmers and who were not. But I could just review all the patches submitted over a period of say a week to see how much work people were doing, and the quality/complexity of the work. (unfortunately our Scrum Masters are clueless to the output of their workers, if they knew, they would almost certainly abandon Pair Programming).   ---   In terms of gains to the employer. This is another interesting topic. The question over is it better to have everyone working on everything. Or people that specialise on certain components...   With the former: The advantage is that everyone knows a little bit about everything. With the latter: The advantage is that everything has someone who is an expert.   From my experience, and my current employer has also come to the conclusion that the latter is far more beneficial.   In theory it's good for everyone to know about everything in case someone is busy on something else, away, or leaves the company. However, in practice this is rare. You might lose an expert every 6-12 months, depends really on the project. - I think a lot of developers leave projects because they have no attachment to it. They don't feel they own anything in the cluster-**** of components.   In practice what happens is that no one knows enough about any single component to be confident enough to know what will happen if you do this or that. No one has a complete mental map of any component. You can't properly work on a component, without knowing what *EVERY* line of code inside that component does. Sure you can add an extra function here, or a little bug fix there, achieving a task now. But what happens is that over time, there are lots of ugly extensions, hacks, and bug fixes, that makes the code unmaintainable, because no one can see enough of the forest to say "Hey there is already a SetTextToRed written by Jim, SetTextToGreen written by Jack, and I'm writing a SetTextToBlue function, why not just have a SetTextColor function" - of course that's a simple and obvious refactor that anyone should see, in practice they're a bit more complex than that. But these are the things that are missed when you have no component ownership.   The most bug-riddled code is in the code which is old, has had a lot of modifications over time, and has been worked on by a lot of people. I love git-blame, it tells an amazing story about the code you're looking at.
  4. So a little background about me. I've been developing software in the back bedroom for many years, along with my brothers. Worked for a dozen different companies in varied team sizes, on many successful projects over the past 8 years. So I would consider myself pretty experienced (Games, Applications, Web Applications, C++/Assembly/Flash/PHP etc. you get the idea).   So now, on my most recent contract. The most highest paying one I've ever had, a very important UK project, but arguably one of the more easier projects I've been involved with, and working alongside generally less talented developers than most of my previous roles. I've come across this new buzz word called "Pair Programming" (PP).   Now I'm not sure how I've managed to avoid PP for so long in my career. But apparently, PP is not only the solution to improving code quality, but is apparently the only way any good software was ever built, and any project that has been successfully developed without PP is a miracle.   (I personally think considering the importance of the project we're working on. We should take the hiring process more seriously and hire quality developers i.e. nerds. over hiring 'politically savvy' sub-standard developers and coming up with various processes to improve their output on such an important project.)   *end of rant*   Now looking at this objectively. If I do a google search for PP. I can see a lot of studies that report PP to be more productive, improve code quality, and reduce bugs. I can't understand this when most programming tasks are trivial (or at least seem trivial to me). Once the architectural aspects of a task have been discussed. A good programmer should be competent enough to implement the architectural specification. Then once implemented, another developer should be able to code-review it, just to pick up any small programming mistakes (not architectural mistakes as that has been cemented before coding).   Looking back on an old topic on GameDev.net about PP, seems mostly negative views on it. Perhaps GameDev.net developers have a different view, or perhaps the majority of developers have a different view, and these studies are skewed?   I think the problem is that in most projects. There are 10-20% of programmers that are truly talented and motivated. They are responsible for the core, and even much of the bulk of any software project. The other 80-90% lack talent and/or motivation and don't contribute much (especially when you factor in the number of bugs, and hacks they introduce). PP works well for them.   "I find with PP I'm much more productive" - Perhaps thats because when you work alone, you're not focused, and browse the internet most of the time. Or perhaps thats because you're not as good as your pair, so your output is being raised (perhaps your "better-half" is less productive - assuming he is motivated on his own).   "I find with PP we spot errors like semicolons, and brackets more quickly" - Missing semicolons and brackets is simply unacceptable. If you make these silly mistakes shame on you. If it takes you a long time to spot them after the compiler has helped you find the line, then well I think you need to find new profession.   "I find with PP we come up with different solutions to solve a problem" - No, discussing how you're going to tackle a task gives you different solutions to solve a problem, this is architectural design. If you have discussed a problem properly before writing a single line of code. Then there are very few ways of implementing the code, especially once you follow an agreed upon coding standard/convention.   "I find with PP I learn lots" - You can also learn a lot just by reading or reviewing the code, instead of interrupting someone's train of thought. I actually find I learn much better by playing with the code, figuring out how things work and developing a complete map of the code base, instead of relying on someone else to tell me all the answers.   "After a long day with PP I feel satisfied" - This is very interesting. Considering programmers tend to be introverted. I find programming solo, very therapeutic, and I can code into the evening with people reminding me to go home. Makes you feel pumped and really good about yourself. With PP, I start to get a headache in the afternoon, and just want to go home. It's painful, emotionally draining. - I don't consider myself that introverted, I enjoy talking to people, helping them with problems, and chatting up the female staff. I just don't enjoy pair programming. I feel like an impatient kid jumping up and down watching a programmer slowly write code, and constantly correcting them, and trying to convince them to do it my way.   It probably is a case of talent and motivation. I've done a lot of pairing with others over the past 6 months. But when I think of all the times when I've paired with other people. I've felt that it would've been of better quality on my own (they disregarded certain safer techniques that I would've used), and done quicker (they seemed tired, and not properly focused). While they felt that they produced better quality code with me, and that they were productive.   (Weak Programmer + Good Programmer) / 2 = Average Programmer. (Lazy Programmer + Motivated Programmer) / 2 = Average Programmer.   In closing. I have a habit of checking the git blame (or svn annotate) whenever I see some pathetic excuse for code (dirty copy and paste, badly named variables, not following code conventions, lazy hacks etc.). So I can tell the programmer what I think of his work. However, many a time, I've done this, and to my surprise I discover that the work was paired on (in the comments we mention the initials of who we paired with on the task). So I'm not convinced that pairing is the solution to improving code quality. Finding decent programmers is the best solution (which requires a combination of good pay, and more importantly good interview and selection process). Perhaps our education system is swamping the software industry (especially big companies) with graduate programmers who are neither motivated or up to the standards of the older generation of back-bedroom programmers.   It could also be that I'm not much of a team player :D - Although I actually enjoy discussing and planning things with others. I'm just old fashioned in that I like to do the work on my own.   Coming soon: Quad programming, the only way real software is made. ("We tried making a hello world program, and were scratching our heads trying to find out why it wouldn't compile. My number 2 couldn't smell it. Number 3 suggested reading the error message, thats what his iPhone says. Number 4 guessed it was a pesky semi colon...")
  5. So anyway, I found out that the bug occurs on the iPhone 3G (not iPhone 3GS/4), and also on the 2nd generation iPod Touch. Fortunately my brother had a 2nd gen. iPod Touch and could easily replicate the bug. So I got that from him a couple days ago, and have fixed the bug. Turns out it was a case of me writing outside of a buffer (forgot to clip -ve x & y coords for a particular section of the "solid-map" rasterization), for the iPhone 3GS, this wasn't a problem, but for the iPhone 3G/iPod Touch 2 it causes it to crash. So anyway it seems pretty rock-solid now that I've done this fix, I'll alternate development between the iPhone 3GS and iPod Touch 2 as I create the full version. I'm thinking now might be a good time to release a bug-fix update for the Lite version. Rather than waiting a few weeks to release a new lite & full version, sinc theres quite a lot of people still with the older iPhone 3G & iPod Touch 2.
  6. [quote name='Ed Welch' timestamp='1312569776' post='4845138'] Maybe you simply didn't test enough to find the bugs. I had a nasty intermittent bug in the first version of my game. It took me 8 hours of continous testing before I found it. Also, check the crash logs in iTunes connect. [/quote] Interesting. Regarding the crash log feature. However, I just checked that and there are no crash reports. I've tested the game lots and it's never crashed for me, and obviously didn't crash while being tested by Apple. Anyway, I'll keep looking and add my own checks, it's possible it's a memory allocation issue, whereby on older iPhone/iPod models they do not have enough graphics/general memory. I'm not too bothered about the stability of the lite version, as I made it primarily to get a feel for the market, bug test, and as a work example for getting iPhone work.
  7. Hi guys, I recently submitted a Lite version of my iPhone Game to the App Store (Turtle Trench Lite - http://itunes.apple.com/gb/app/turtle-trench-lite/id447579919?mt=8 ). The game plays pretty well, and I'm working on a full version... 99% of the code is C++, and Open GL ES. The plus side of doing it this way, meant that I didn't really have to learn anything. It was the same as developing for the PC, with a slightly different input interface, and different resolution. Only took a couple days at most to create my graphics library to interface with Open GL ES. The downside of course is that the commercial iPhone industry focuses on Objective C and iPhone specific 2nd/3rd party API's such as Cocos2D. Which would put me at a disadvantage if I seek industry work for the iPhone. (The solution to this, is to create a second 'crap app' that uses Objective C and all the other iPhone specific API's). Here's a screen shot... [img]http://a1.mzstatic.com/us/r1000/101/Purple/3a/79/62/mzl.gjebgyxf.320x480-75.jpg[/img] Anyway, reason I'm posting this is because although the game runs perfect on my iPhone 3GS (OS version 4.2). There are some people that have written reviews saying that the game crashes after the first level, without any info explaining what they were doing, what iPhone/iPad/iPod they have etc. Aside from purchasing half a dozen different iPhone/iPad/iPod models, I figured it'd be better to post it here, and if a few people could test it, and shed more light on any bugs that occur, it'll help me narrow down the problem(s). I used to be quite active on these forums a few years ago, so thought I'd come back to say hi, and show you guys my first iPhone App.
  8. k, thanks guys. this is working now... ok i've got another question. if two computers (different locations/IP) have a UDP port closed. if they both send out a UDP packet to eachother's IP's will that open up the UDP for further 2-way communication, or does atleast one computer have to have their UDP open? i suspect the latter is the case, otherwise you wouldn't have to set up UDP ports for multiplayer games such as Starcraft, Warcraft 3 etc. (everyone would just send out dummy UDP messages to eachother in the game to open up their UDP ports). Well this is my current project => www.playonlinesoccer.com <= it's an online football/soccer game. so you can see where the UDP communications come in. I'll be putting up a new version(s) today. So your welcome to playtest it. [Edited by - Memir on September 19, 2005 7:06:39 AM]
  9. I've noticed that with TCP/IP firewalls are less of a problem in multiplayer gaming, only the server side has to have the specific port open (to incoming connections), whereas the client side 90%+ of the time will have all ports open (to outgoing connections), i.e. like HTTP port 80, you can always connect to web addresses (for two way communication), but you have to open up your port 80 if you want to host a website on your computer (if you have a firewall that is). Now, with UDP it's a lot trickier. The majority of people have all UDP ports closed (to incoming messages), so for the most part they can only send out UDP packets, but can't receive. I was wondering if there was any way around this? btw: Can you have two sockets on the same port e.g. UDP on port 2000, and TCP/IP on port 2000? or will they clash?