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

Alex Melbourne

Members
  • Content count

    78
  • Joined

  • Last visited

Community Reputation

294 Neutral

About Alex Melbourne

  • Rank
    Member

Personal Information

  1. I'm very much a fan of Visual Studio. Because I'm a student I can make use of the Ultimate release for free. I'm not sure what your exact predicament is but if you don't release your games for money and you're also a student I'd recommend attempting to get a copy. The extra tools like static analysis and profiling are certainly very, very educational.   MSBuild is also a nice tool once you start to learn it.   Failing that you could just install GCC and use CMake to automate building. You're then free to use whatever text editor you like. Sublime (http://www.sublimetext.com/) is pretty cool.
  2. I was wondering if anyone would be able to give me a hand with my general commit messages in Git.   Specifically, my project's history is here: https://github.com/MiniAl/Radium-218/commits/development/.   My question is basically: What kind of quality would you rate these messages?   General goals and thoughts when I write commits: Explain what changed (as a brief overview), explain why it changed, and finally explain how this might affect the project in the near future; Attempt to make commits minimal and focused ('git add -u -p'); and Write messages in Markdown (http://daringfireball.net/projects/markdown/) to provide a structured way of providing links and emphasis without bloat. I was hoping someone could take a brief outside look at let me know if I'm actually achieving these goals or if there's something huge that I should be doing and are not.   Brutal, constructive criticism is welcome. .
  3. Yeah, this is the other reason. I'm hoping that a lot of programs installing using the %ProgramFiles% macro. If I change that in the registry then it'd make life just generally easier.   How does Windows react to the "Common" folder being moved?
  4. My head. Designed most of a system of a program that works out StarCraft II build orders when I woke up yesterday.   Apart from that I have my laptop that I specifically got with a smaller screen. It's only 14" so I can take it most places.
  5. Sorry for the double post but I wanted to make this bit clear (I'm not amazing at explaining myself): I was just wondering how Windows behaved during updates, etc.
  6.   My current Windows folder (that's just the system folder) is 30 GB. I wanted to leave room for updates and the like.   It's possible via a change of the registry value that changes the default location and then a ROBOCOPY via a install disk and then apparently a junction to the new location just in case. That's done after the installation finishes.     Visual Studio 2010/2012's toolset, Starcraft, Steam, nothing really fancy. These aren't _that_ big in themselves its just that with them and Windows fighting for space It's unlikely that I'd have the room.   I know. :). This is really a curiosity for usability. Really if it came down to it I could just make "fake" folders on the separate drive.   Added benefit of wiping Windows and leaving all my files intact.     I regularly fill the 256GB of my current drive so those sizes aren't really up to my requirement. :/. I figured I could just get a cheaper HDD and upgrade when I have the money later.     That was exactly my plan. :). I was just wondering how Windows behaved during updates, etc. All I could find on Microsoft forms was the _advice_ not to do it. _advice_ is nice but it's not really an explanation. :P.
  7. Not really a coding topic but I'm a little confused.   When you install Windows (specifically 7 x64 in this case) the drive contains 4 folders: Program Files, Program Files (x86), Users, and Windows. Now I know that you can point User Profiles to wherever you like so that isn't a problem.   What I'm doing is building my first PC and I'm just looking into a method of having the operating system on an SSD (because they're kind of expensive right now) and everything else on a standard HDD. My current idea was to purchase a 40GB SSD and some arbitrarily sized drive for everything else.   The thing is that most of the space is likely to be rapidly taken up by programs and not Windows. Probable solution: 2 drives (one containing the Windows folder and another containing Program Files, Program Files (x86), and Users). How does Windows react to fresh installs with programs on separate drives?   If I wiped the Programs drive or the Windows drive how badly would Windows implode?
  8. Are you suggested effectively storing entities and components in giant string tables?   I'd have thought that Systems would be better placed to be isolated functions in this case and you just call them all in the game loop.
  9. My understanding is that components really only had 'get' and 'set' style functions. It is the Systems that are aware of how to manipulate such data. In my current project (still planning it) I simply have three base interfaces: ISystem, IEntity, and IComponent.   I store your 'movement' component in a 'CSpacialComponent' class that contains both an entity's spacial position but it's velocity, and acceleration. It also stores the same values for the object's rotation in Euler angles (that is angular displacement, velocity, and acceleration).
  10. I'm going through and learning how to use Visual Studio properly and I've recently discovered its modelling tools (hooray!). I already knew UML so I've set about creating the layout of the engine/game I'm building.   Now I found it's possible to generate code from these diagrams but the code is always in a C# project. I'm happy to write out the T4 files to generate C++ and not C# but I can't find a way to simple dump the files in a directory.   I know how to write MSBuild files fairly well but I don't know how to achieve what I want...   To summaries: Does anyone know how to prevent the generation of a C# project file and simply dump the generated header files in a different project directory.   I want to make the engine project dependent on modelling project so that I can regenerate structure quickly and simply.
  11. Different subjects deal with different bases regularly and so tend to be lazy and create small notation.   'log' written on its own should be assumed as base 10 if a base isn't specified, 'ln' is to the base 'e', and 'lg' I think is commonly base 2 but that notation is fairly informal (is my understanding).
  12. For the record I'm attempting to write/rewrite the Ocarina of Time on the PC. I don't plan to release it or do anything with it I just wanted something that I could look at and think about how things are done rather than what is being done.   I'm studying Software Engineering at Uni and what I really wanted was some kind of over view about how a game/engine might be engineered architecturally rather than exactly how Direct3D works or how basic physics is calculated (I already know the basic maths I can implement this later).   These posts have introduced me to several ideas I didn't know existed so educationally this is exactly what I wanted.   In terms of game objects I was just going to have a giant internal table of IEntity objects (cameras, players, enemies, static boxes, etc). Such an interface really only stores absolute position in the game world and the Euler angles. So far I hadn't thought much further than that.
  13. I'm a little confuse about what is being suggested. I've done a small amount of Googling (I'm going to do a lot more research on SOLID because it looks like a powerful method of segregation).   My original idea was simply creating system types and have them as data members. From what I've read is it better to simply have a series of pure virtual functions as an interface (say IInputManger, or IRenderer) and contain only pointers to such types? I'm assuming the actual systems derived from these interfaces (RenderingEngine inherits from IRenderer) but have no accessible functions (other than those defined in the interface) because they're only ever accessed through pointers these interfaces?   This makes all interfaces simply adaptors (http://en.wikipedia.org/wiki/Adapter_pattern)? Isn't this the same kind of thing COM attempts to do?
  14. Everytime I talk to someone about game programming they always say "just do it". So "just doing it I am". However, I was wondering if I could get a slight bit of feedback on my current idea. I'm going to keep pursuing it until I hit a brick wall for educational purposes but I was curious how common this kind of structure in a game is.   I was recently reading a book that brought up the concept of a 'system'. Systems have inputs, outputs, feedback mechanisms, etc. It occured to me that all game engines are just a series of systems (and the award for over-simplification of the year goes to...!).   My current structure simply involves all game parts (input manager, rendering engine, networking) inheriting from an interface ISystem. This makes all systems completely isolated from each other.   Systems can also contain subsystems. If the game itself is a system then it can contain a input manager system, a rendering system, and so on.   The way I've defined the interface means that systems can communicate via a message passing interface. Messages derived from an IMessage interface and carry their type with them so that certain systems can receive specific information. I've previously looked at DOOM-3's source in brief and after reading 'All Signs Point to "No-No"' here (http://www.gamasutra.com/view/feature/132500/dirty_coding_tricks.php?page=2) I figured this was a better idea than enforcing simple packing.   Systems keep an output-restricted deque to allow important messages to skip to the front of the message handling process.   This is my first real project and I was really wondering what someone with actual experience thought of this idea. Have I been paying attention to everything I've been reading in books/online or have I missed the point entire and should probably be shot.   Thank-you for any comments.
  15. Win32 is all in C. The typedefs LPCSTR and LPCWSTR are C-style strings. You can't really pass a std::string directly to functions that take this type. Pass it the result of std::string::c_str().   Also, Windows has the define TEXT that will automatically mark a string as with either L or not based on the defines of MBS or UNICODE.