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

simesf

Members
  • Content count

    37
  • Joined

  • Last visited

Community Reputation

122 Neutral

About simesf

  • Rank
    Member
  1. Quote:Original post by iliak You can have a look at the mantis of the project. When I find a good source of information, I report it their. The trickiest part (I think) is the way to render the maze, but with a little bit of logic everything is simple. The only assets I "stolen" are the graphics (if any graphician read this and want to help...). I made my clone from scratch. You can have a look at the source for more information, or better ask question in the mantis bug report and *if* I have enough time, I'll post some wiki pages about this... Anyway, if you have question just ask ;) Well thanks very much iliak. That's very generous of you.
  2. Sorry to come in on your post with nothing but a question Iliak, but for a long time I've been itching to try doing an EoB type game. But I've found almost no information about how to go about doing such a thing on the web. Maybe I'm googling with the wrong keywords. The only thing I found was here: http://eob.wikispaces.com/eob.vmp Did you come across any information about how to program any aspect of this kind of game on the web or in books? Any information would be much appreciated.
  3. I think I'm fairly comfortable with the idea of pointers now, although I wish they were called something else - '... and the pointer points to another pointer pointing at the pointed at value...' - if I can barely get my tongue round this just imagine what it's doing to my brain. But it's basically looking at the address on the letter instead of the Dear John letter inside. If she's not a constant woman she could change her mind and put another letter in the envelope. But the 'this' pointer stumps me. I'm sure it will be covered in a later section as to why you would use it, and in preference to a regular pointer but it's hard to take things on faith when you're as old as me. For pointers in general it would be great to hear about real world uses for them. I imagine one example would be if you wanted a new footsoldier to be created in an RTS you would use a pointer to the free store to create a new object while the program was running. Are there any other examples for using pointers?
  4. That makes it crystal clear & I'll be jotting this in my notebook so thankyou muchly Rip Off.
  5. Quote:Original post by Dave Hey The Free Store is where memory is allocated and deallocated using new and delete. The Heap is where memory is allocated and deallocated using malloc() and free(). The two arn't interchangable, meaning that if something is allocated using malloc() then it can't be cleaned up with delete and that something can't be new'd and then free()'d. Hope that helps, Dave Thanks Dave. While I don't know about malloc & free yet, having a workable distinction stops me from fretting about it.
  6. Quote:Original post by Dave 3. The Stack and The Free Store (Heap) Note that the heap and the freestore are NOT the same thing. Dave Could you elaborate on that a bit, Dave?
  7. I'm sorry to post this on this thread but there is no thread for week 6 exercises yet. Also if it's something I couldn't know about from the work we've been doing so far then maybe it would concern other learners. I'm getting the error message: 1>.\main.cpp(1) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory I'm using Visual C++ 2005 Express Edition on XP, SP2 & working with Project: General, empty project. If it's something I should know about then once again I'm sorry & it's time for a reread of my notes. edit - I tried the same source code adapted to a Win32 Console Application, default settings and got a slightly different version of the same answer.
  8. By now I'm getting the feeling that whether to name variables i (not ii) or using longer names is a judgement call which takes into account the need to share code, your philosophy on the matter, and mindful of the particular situation. But above all it needs the 3 'c's - clear, consistent, commented. Is that a basis for my own philosophy?
  9. Quote:Original post by RinusMaximus I always use i, j, k etc. for my loops. This way it is always clear to me that this variable is only valid in the scope of the loop, so I would never confuse these with other variables. That, coupled with the later bit of advice from Oluseyi is just the kind of real world stuff I love to hear about. Thanks! Quote:Just try to program as many things as you can. You can only become a good programmer by writing loads of code. You know, one reason I like Dietel & Dietel's 'C++ How to Program' is the sheer number of exercises it has at the end of each chapter. You sometimes feel you'll never get through all of them but it really hammers home the principles in the chapter; either that or it hammers home that you haven't understood the principles & need a reread. I'm hoping that some experienced programmers will be able to remember the first programs they wrote after they had learned some of the basics & could say what they were. Or is there a website that deals with relatively simple programming exercises so that people can practice their syntax & structure without getting confused over the complexity of the problem itself?
  10. Well there's a wealth of information here that makes things so much clearer. Thank you. Quote:Original post by Zahlman Some examples of what you found "hard to read" might be useful. I wouldn't want to cause offence to any writers (or highlight my own lack of grey matter) by directly quoting them. But here's a small sample that slowed me down (variable names changed): for (vehicle = 0; vehicle < vehicles; vehicle++) for (int car = 0; car < cars; cars++) grade[vehicle][car] = roadArray[vehicle][car]; I find the naming of vehicle & vehicles to be too close together and I lose track of which is which. Also vehicles & cars were declared a few lines earlier so I find myself backtracking to double check them. Once I've double checked what 'vehicles' is supposed to be I've overwritten in my memory the value of 'vehicle'. But they are named logically and are both more clear as individual names than i or j. Finally I have this little ritual where I hold up my left hand & say 'so this is what's in grade[vehicle][car] and its going into roadArray[vehicle][car]' (holds up right hand & waggles it about a bit in a desperate attempt to visualise.) My monitor screen now has lots of little fingermarks where I point at it with two fingers trying to figure out the program flow. In general I've found that the more undigested new material there is in a section of code the harder it is to work it out. I also get the most confused when I'm trying to store more than 2 or 3 variable names & what they stand for / their current values to work out one expression. Multiple dimension arrays are fun too. In such a case I believe the way to do it is to work from the innermost brackets/parentheses/square brackets outwards. Is this right? Do any of you mentors sit down with a pencil & piece of paper to work out a section of code you are not familiar with? Do you start drawing lines on the code to work out program flow? I think I would, along with little bubbles close to variables with an example value inside to picture what's happening at a particular stage. I'd try & run through with what I perceived to be the minimum & maximum values as well. Would this be a bad practice? Also I once heard a programmer at the now defunct Microprose say 'Where's my calculator?... Oh God! Look at that! A programmer without a calculator - that's not right!' Was he just having a joke? Come to think of it, I've also known another programmer who held the attitude that if you're smart enough you can read any code. In fact he was rather arrogant about it & dismissive of lesser mortals who couldn't. Is this a rare attitude or do you find a competitive element in some programmers? I appreciate that these questions are not so much to do with understanding of code, but as a learner the thing I miss most is to physically sit next to an experienced coder and watch them in action.
  11. Having now read some of the chapters of the book I would urge any fellow students who are using the online version to consider getting the book. I tried learning from the online version 2 years ago and I've noticed the later version of the book contains signiicantly more good information than the older online version. The section on advanced for loops threw up a question for me. They reminded me of 'Accelerated C++' by Koening & Moo which many people swear by but I found some of the code too dense. A line of code that does one thing I find much easier than a line of code that does 4 things. But I gather there is the notion of elegant, compact code which accomplishes more things with fewer lines, which if I'm guessing right started in the days when there was precious little RAM & storage space so it had to be tight. But things have moved on and today's computers have squigglies more power & resources. So my question is; is compact / elegant / harder to read code still always favoured over looser / verbose / easier to read code? I ask this in these days of long development times, Object Oriented languages and teams of programmers as opposed to individual coders. Or is it a case of certain areas of code benefitting from dense programming while others from a clearer syntax. I'm assuming both types would be //commented. simesf
  12. Many congratulations to you & your wife for your new arrival! Overwhelming isn't it? I hope everything works out fine for him. In case this is your first don't worry; it gets easier after 6 weeks, then 3 months, then 6 months, even if it doesn't seem so at the time. If we don't see you here for a long time your expertise will be sorely missed but it would be completely understandable, and thank you so far for your considerable help; finally I have a chance to learn something I've wanted to learn for the past decade. simesf
  13. I was wondering if it will be possible to refer us back to this recent discussion when we have covered some more of the chapters in the book? I think this is the single best resource/opportunity to learn c++ I've seen in the past decade, the answers are more than generous and from what I've seen so far the question/answer style could easily be edited into a book. But while I've put together a few lego bricks of logic in my mind, all of a sudden there's a mass more what with reference to classes etc. I'm trying to make sense of it now because I don't want to be asking all those tutors who are giving their valuable time the same questions again & again. But there's a lot to take in & I feel like I'm standing in a hole learning how the foundations are made and at the same time trying to figure out the wallpaper in the upstairs bedroom gets pasted on. I can only digest so many pieces of information at any one time. So, if in the future I ask a question that's already been answered in earlier weeks please don't assume I haven't been reading everything. I'm just not in a position to understand everything I'm reading. Just point me to (eg) week 2, page 1, about halfway down and I'll thank you & maybe I'll get it then. simesf
  14. I noticed in an earlier post that it was said std::endl flushes the buffer. Just to check I understand this; in layman's terms a buffer is simply an area of memory where some thingy that's been processed is sent to. There it waits, in the buffer, until it's called. If the buffer is flushed it means that once the thingy has left, the area of memory it occupied is freed for new operations. If it wasn't flushed, a copy of the thingy would still be there. Have I got that right? One more thing. I remember the last time I tried to learn c++ I was confused by all the references to 'foo' and 'bar' while trawling the web. I thought they were more arcane keywords I didn't know until I realised they were just nonsense words which essentially meant 'any old crap you want here'. Sorry, they meant 'word standing in for highly erudite phrase that the c++ faq people would thoroughly approve of'. I write this just in case there's anyone as thick as me who didn't get that. Doubtful, I know. simesf