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

aregee

Members
  • Content count

    225
  • Joined

  • Last visited

Community Reputation

1072 Excellent

About aregee

  • Rank
    Member

Personal Information

  • Location
    Norway
  1. I thought I would tip you off to these excellent videos that explains what you are asking about.  You will see why the data probably is already in the processor by the time the CPU executes the instructions needing those registers.   https://www.youtube.com/watch?v=qZTt8JtQOmw   https://www.youtube.com/watch?v=TJq5FE7jGzU
  2.   Why the heck would somebody declare a variable that is a lowercase 'L'?  I'd be mad at the single letter variable name declaration.      I'm more curious to know why one would type the lowercase L instead of the 1 in the first place, given that at least on a QWERTY keyboard they're practically on opposite sides of the keyboard.     I was thinking the programming world's version of a troll.  :D
  3.   Oh dear.  :D  Yes, that is overly clever.  Not sure if it is any more efficient though.  The first one seems to even have a bit more overhead than 5 if tests, the second one gives me a feeling to be at best just as good.  I don't know the underlying behaviour of either is_sorted or the Python style chained comparisons, though.
  4.   Yes, you are right.  I was thinking to myself that if I made them unsigned, I wouldn't even need the test for 'less than 0', since that would never happen in that case anyway.   EDIT: Sometimes I just mindlessly write code, but today I just had an epiphany.       Yes, I have had my dose of try..catch with Java back in the day.  It is something I try to avoid, unless something really bad happens in the code, but I do see its use.  Not sure why, but even 25 years back in time when I first learned Pascal, I tended to stick with the functions that didn't throw exceptions if for instance a file could not be found.  Really never been a fan of exceptions.  I think the main reason is that I think it clutters the code too much.   In java you even have to wrap string to integer conversions in a try...catch clause...  I always was amazed by that even the "simplest" of operations has to be wrapped in exception handling in Java.  You can probably guess that it is not my favourite programming language.  If I were to rank, it would be c#, and Swift looks promising too, but both are (or have been) traditionally been tied to a single platform.  So here I am with my second or third best: c/c++.   EDIT 2: Oh, yes, I get why you mentioned exceptions now.  You are probably right that it is better to throw an exception rather than returning an arbitrary 'negative 1', or pass a value by reference to see if the operations succeeded or not.  I still have a bad feeling about using too much exceptions though.   I know I am not alone in feeling this way.  The whole Objective-C setup that Apple provides, is built on the assumption that excessive exception handling is evil.  Having pass by reference error values is the rule rather than the exception there.   Then you have the reversed way where you return an ok/error code and pass the returned index as a reference.   What is best practice?  Is there even such a thing in this regard?  Swift can return tuples.  That is a nifty thing.  Too bad I am reluctant to be tied to a system that is so locked to one platform and one platform only.
  5. Just writing a simple string tokeniser from scratch, when I came to a "clever" realisation when it comes to bounds checking.   Say you have a string of a certain length, and you want to find a token within a section of the string, you would provide an index for the first character position you want to search from and another index for the last character in the string you will be looking.   Then you need to verify the sanity of these values.   The immediate way to do that would be to just check each first and last bounds to the length of the string and check that the last bound index is not before the first.   Then I came up with the following optimisation: static inline int findToken(const int firstIndexInclusive, const int lastIndexExclusive, const std::string string, const std::string oneOfChars) { unsigned long stringLength = string.length(); if ((firstIndexInclusive < 0) || (lastIndexExclusive > stringLength) || (lastIndexExclusive < firstIndexInclusive)) { return -1; } //searching for occurence of any of the 'oneOfChars' here return 0; } Just three tests accounts for all the boundaries that you would normally check against, which in normal cases I would probably have 5 checks for.   After the first bit of cleverness subsided, it came to me that the readability goes down, the optimisation is rather minor unless if I process a lot of text, although the time I spent making this was not much.  Besides, I think that if you do obvious optimisations while you write code, that is a good thing, but the readability factor is an issue to me.   What do you think?  Is this premature optimisation?
  6. Thanks for your suggestions.  I went with forward declaration.  I did actually try to forward declare the template class, but it didn't occur to me that I needed to forward declare the Point class too.  After I did both of those, everything compiles fine, and now I have lots of nice points showing up on my screen.   Now I will move on to make a scripted math library to move those dots around plus researching how I can make a fast 2D picking algorithm for a massive point cloud.  Probably will be much fun to see it all in action.   EDIT: Strewya: Thanks for best practices.  I always do forward declare functions, but that I in certain cases need to forward declare classes is a fairly new thing to me.  
  7. I had a feeling that the order or place I included header files had something to do with this issue.  I tried to move the following lines from the implementation file to the header file: #include "Node.h" #include "Point.h" It solved the problem  even though everything should really be in scope anyway.  That makes for a different question that I tried to research the other day:   I noticed that Xcode likes to put include files in the header file.  I thought that they should be put in the implementation file, so I did look it up.  It seems that most people agree that they should indeed be in the implementation file, but...   That leaves me two questions: 1. Why does Xcode put the #includes in the header file when they seemingly should be in the implementation file? 2. Can anyone kind, please link me to a good explanation what is 'best practice'?
  8. I am trying to make a circular doubly linked list, and thought it was a good idea to implement it as a template, since I will be using this kind of lists in my project.   The problem is, that while I think to my understanding that I have done everything right, my compiler beg to differ.   The error messages I get are:   - "Unknown type name 'node'" - "Expected member name or ';' after declaration specifiers"   I get these two messages for each of the offending lines, and everything seems right to me.  I am sure there is something I am lacking in understanding or something.   My template class: #include <stdio.h> template <typename T> class Node { private: T *mData; Node<T> *mPreviousNode; Node<T> *mNextNode; Node<T> *mChildNode; protected: public: Node(); ~Node(); }; template <typename T> Node<T>::Node() { mData = nullptr; mPreviousNode = nullptr; mNextNode = nullptr; mChildNode = nullptr; } template <typename T> Node<T>::~Node() { } The header class with the offending lines: #include <stdio.h> class Path { private: Node<Point> *mPointListHead; // <<---- THIS LINE, Node<Point> *mPointListTail; // <<---- AND THIS LINE protected: public: Path(); ~Path(); void addPoint(float x, float y, float z); }; The Implementation for the class: #include "Node.h" #include "Point.h" #include "Path.h" Path::Path() { mPointListHead = nullptr; mPointListTail = nullptr; } Path::~Path() { } void Path::addPoint(float x, float y, float z) { printf("Adding point\n"); } The header file for the Point class just for reference: #include <stdio.h> class Point { private: float mX, mY, mZ; float mR, mG, mB, mA; protected: public: Point(); Point(float x, float y, float z); Point(float x, float y, float z, float r, float g, float b, float a); ~Point(); }; The implementation of Point: #include "Point.h" Point::Point() : Point(0.0f, 0.0f, 1.0f) { } Point::Point(float x, float y, float z) : Point(x, y, z, 1.0f, 1.0f, 1.0f, 1.0f) { } Point::Point(float x, float y, float z, float r, float g, float b, float a) { mX = x; mY = y; mZ = z; mR = r; mG = g; mB = b; mA = a; } Point::~Point() { } Thanks for any help with this, and yes, I know that classes are private by default.   EDIT: The weird thing is that the "intellisense" (*) kind of thing sometimes seem to colour the keywords like it understand the names, but when I try to compile again, it forgets them again.  When the names are in the colours that shows that the IDE knows the class names, I can also start typing and get the correct autocomplete suggestions.  Also this goes away if I try to compile.  I am using the latest Xcode by the way, but I am pretty sure it is me goofing up, not the IDE/compiler.   (*) I don't know what name Apple has for the "intellisense".
  9. This:   http://www.gamespot.com/articles/student-transferred-for-making-counter-strike-map-based-on-school/1100-6235913/
  10. This video should give you a thorough explanation on the matter:   https://www.youtube.com/watch?v=O4__F4iX6rc
  11. I am by no means any expert on the topic, but I think you have a lot to learn, if HTML is all you know.  Just client side, I would add that you would need to learn JavaScript too, in addition to the other technologies you have already mentioned.   Unless it is a client based game where nothing is stored between sessions, you will also need a web server with a database system and a server side scripting system. In the past, I have used Apache, PHP and MySQL, but that is starting to be quite a while ago, so have a look around.   Other buzzwords you may have a look into is JSON, JQuery.   Security is a must, so make sure you understand the dangers and pitfalls of a poorly designed system for handling logins and sessions (how you store your passwords, for instance), and data that is sent to the server from the client (it can not be trusted without validation), and SQL security as well (SQL injection, for instance).   All these suggestions are based on what you mentioned in your original post, and there are other choices you can make too, like scrapping everything mentioned above and go for something like FLASH, for instance, client side. You will still need what I mentioned on the server side if you want persistence.
  12. Never heard of the group or demo, but I am pretty sure it is this one:   "Toys" by "Gods" (PC demo, "Trip" party, March 1999, 1st place):   http://www.pouet.net/prod.php?which=710   I couldn't find any YouTube video of the demo.
  13.   I won't repeat what Álvaro said, but please...   Write sensible names.   Name 'dyn' and the likes more like 'isDynamic' (If that is even what you mean).  Then you can test like this, assuming it is actually a boolean: if (isDynamic) { ... } Instead of: if (isDynamic == true) { ... } Try to make your code as readable like a book that you can.   Always use brackets, even if your if, for, while, do..while, etc is having only one line.   'currentLineCount', or 'CurrentLineCount' is MUCH easier to read than 'CurLnCnt'.   What is 'IsPastEOS'?  'EOF' is so common, I guess most people would understand, but 'EOS'?  End of stream?  I would spell it out in either case.   I know that you have an assembler background, and labels like this were common back then.  I also think you actually was limited to 8 chars on certain assemblers too, and that didn't help.  It really feels like reading assembler code written in C.   And I will also point back to Álvaros comments again.
  14. I think exceptions have no place other than in the case of a fatal, unrecoverable failure in a program.  When I was learning Java way back, I was encouraged to use exceptions as the default way of reporting and handling errors.  I always felt that was a bit clunky, and it made for code that was filled with blocks that I felt never belonged in the code at all.  I always favoured explicit error checking over exceptions.  Who thought it was a great idea to throw a NumberFormatException when you feed bogus data to convert a string to an integer in Java??  That pretty much sums it up...
  15.     That's an arbitrary blanket rule. Early returns are a good thing. Breaks and continues have their places. Goto has its place too when you need some kind of control flow that improves readability (like the error handling example) and no other language construct naturally lends itself to that (admittedly, that is rare even in languages like C, and basically nonexistent for higher level languages). And when I see this kind of rule being repeated blindly all I can think of is the programmer who, told not to use goto, wrapped up his error handling code in a dreadful do{}while(0); loop to obtain the same control flow without writing 'goto' and obfuscating his code in the process. And that is far worse than any amount of gotos (well, almost any amount).   I'm not saying goto is good. Here the use of goto for error handling is justifiable because goto naturally lends itself to a rather elegant, very low boilerplate resource cleanup implementation in C. Clearly jumping all over your code, to labels hundreds of lines away, is nothing short of insane. But simply outright banning goto because there is a paper called 'goto considered harmful' without even considering the possibility that maybe, just maybe, goto could be used in a controlled manner (it is a tool, and just like any other tool it can be abused; break and continue are also tools which can be abused) simply shows a lack of intellectual depth in my opinion.     The cascade model is just plain ugly.  The goto way is actually really elegant.  In those cases I would probably go for a function in the past to avoid goto, but your arguments have convinced me.  There are definitively reasons for goto in certain cases, and the function way is not good either.   Regarding the blanket rule, I am not at all preaching the "flow chart" model, since I am obviously not following those rules myself, just wanted to hear some arguments, and I got a lot of good ones.  I am a follower of clean and elegant code, and that is for me more important than any other strictly (and blindly) enforced idioms.  Hearing comments like this also eases my insecurities/discomforts when I am breaking out of learned/taught conventions to make things more readable/elegant too, but the goto one has really got stuck in me for some reason.