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


  • Content count

  • Joined

  • Last visited

Community Reputation

287 Neutral

About Pointer2APointer

  • Rank
  1. Low-level is my bread and butter. I've always loved knowing and wondering what was going on underneath all these symbolic English words on my text editors, IDE programs, etc, such as "include this", "load that", "call this", "return this". Higher-level programming means simply writing instructions in a language that is not directly, or close to being directly, executable instructions from a processor for a specific instruction set architecture(C is not really "low-level" as Assembly languages are). Lower-level programming is writing instructions that can more closely be executed directly by the processor(Assembly or machine code). Assembly on a specific architecture is almost the lowest you can go without almost completely sacrificing readability. Binary code or machine code is the lowest-level execution done in general, but even that can get one step lower: microcode(although useless in almost every case for developers, and always pre-coded by hardware engineers basically). It's almost impossible to do much of anything with machine code directly because it's extremely difficult to maintain, and you'd have to literally enable yourself to think along the lines of machine instructions for every miniscule instruction done by the processor. Assembly is much more readable, but still very, very difficult for a newcomer to really grasp(I am still in the midst of learning Assembly for x64 after first mastering 8-bit Assembly from 6502 Assembly, which was used in Nintendo Entertainment System's console in 1985). This is why higher-level languages get things done faster, because the abstraction from the processor is defeated using other tools and programs to "translate" the higher-level instructions into a directly executable format(on the machine code level, usually). If you really want to go to low-level, it's a definite suggestion to start with lower bit-depth processors first(through a virtual machine or such). Although low-level has lost its spark decades ago, it's still nothing more than amazing and useful information to know how it all works from the hardware itself.
  2. Agree. DX and the WinAPI are the [b]LOWEST[/b] level APIs you can interface and develop with on Windows. As you might suspect they are the hardest. SDL, SFML, Allegro, etc. Plenty of APIs that will wrap the Windows API, and hide DirectX completely in the shadows from you. This will make the [i]developing part[/i] faster and easier, but doing it with DX and WinAPI will make the [i]setting up[/i] part longer and more difficult. A beginner would be better off with the wrapper APIs, because, believe me, DirectX can be one [b]major [/b]pain.
  3. Some developers may prefer that you know DirectX for Windows platform-specific development, because in that case they may choose DirectX over OpenGL(even though up to certain point all advanced Windows-based games use DirectX for rendering certain aspects of graphics under the hood, but you simply don't have to code it that way from your position). So I'd say that it isn't really necessary, seeing as most people go for cross-platform, and using DirectX itself would be harder to grant that through porting.
  4. It's much easier to make a program act as if it were a real operating system (to some sort) than an actual operating system(and a lot more bearable as well). And I don't think your terminology of "virtual" to "real" operating systems makes sense. An operating system running on a virtual machine is still a "real" operating system, as it would generally carry the same instructions that would be used otherwise on real hardware directly, rather than a program acting like a virtualized version of real hardware itself. And if you're really that eager to see how they made the video, contact them on their YouTube account. Someone else can propose an idea, guess, or maybe know, but it's hard to tell based on just a video as to what program was used to make it. If you want to make an operating system for real, however, you have a lot of learning to do. Even though an operating system is still software, it's not the same as compile-and-go "Hello world!" that can be accomplished and executed in less than a minute from scratch(with the right programs, input speed, files and knowledge ready).
  5. The thing about programming is that there will [i]always [/i]be trouble spots for every programmer, best or worst, top or bottom of the list. If you haven't already made a "falling blocks" kind of game, which is like Tetris(without explicitly referring to it), you should proceed on there. Platformer games give MUCH more experience that would be applicable to the kind of game you want to make, because they incorporate the more advanced work of professional games(such as artificial intelligence, gravity, field and space dynamics, etc.). So my advice to you is ... not quite. Even though completing a Breakout clone is already good achievement, and pong as well, and the fact that you can do artwork makes it even better. But if I were in your spot I'd progress through a few more projects before tackling a game that'll probably be harder than you think ultimately. By the time you've completed games like Tetris and Super Mario Bros., you are ready to set the stage on any game you want(well, the first big stage of the stages). I say this because those are classics; a side-scroller featuring many important aspects of advanced game development subjects, and an arcade-style game with falling blocks. But you're definitely well on your way to accomplishing the "any game" feat. Though it wouldn't hurt to practice a bit either, but you would do better to really (and I mean really) study and learn the difficulty involved in a complicated RPG game (and even the simplest RPGs are still complicated to some extent) before tackling an entire project on it to leave it in the dust, and have to start over anew from a lesser position of development success hierarchy. I think I'll make a tutorial series on how to implement the mechanics of RPG games in code(although I'm not any programming expert, I have experience in programming and design).
  6. [QUOTE]Making my first game[/QUOTE] [QUOTE]I have made pong, and now i want to make a simple game.[/QUOTE] [QUOTE]a tactical stratergy shooter, similar to xcom[/QUOTE] It's a bit of an unreasonable stretch to attempt to make a game like XCOM, 2D or not, after making pong. If you made pong, didn't you realize the difficulty of it just for such simple instances(two paddles, one ball, reversing velocity)? There's no comparison from a simple pong game, even an advanced one, to a fully-fledged commercial-quality game series like XCOM. I'd suggest you start smaller and work your way into larger, more complex scaled games. Maybe you should migrate to a platformer-style game first: --> [url="http://en.wikipedia.org/wiki/Platform_game"]http://en.wikipedia.org/wiki/Platform_game[/url] I will tell you though ... if you think a commercial-quality game is feasible, just try completing a simple platformer with a few levels(many good programmers have programming-plateaus here), and if you can do that you're well beyond a beginner.
  7. I suggest you start by overviewing the principles of isometric projection: [url="http://en.wikipedia.org/wiki/Isometric_projection"]http://en.wikipedia.org/wiki/Isometric_projection[/url] Like anything in making a game, a game's development relies heavily on an idea, a computer programmer experienced with game programming, and/or a graphics artist(altough a programmer can be an artist, and vice-versa, etc.). Regardless of the road you take, knowledge lends you the power to accomplish whatever task you wish anyway you want. But basically, isometric game design relies on isometric projection principles in graphics, and computer programming. You can check out some of the basics of computer programming here as well: --> [url="http://python.about.com/od/throughacomputerseye/ss/begprogramming_all.htm"]http://python.about.com/od/throughacomputerseye/ss/begprogramming_all.htm[/url]
  8. You didn't link with OpenGL, maybe? --> -lopengl32, -lglu32, -lglut, etc. Try adding those above and see if it works. Also, is the build target for a GUI window (graphical one?) rather than a console window(text one?). Be sure. EXTRA: [QUOTE]I have the "lobopengl.a" library file[/QUOTE] You mean "libopengl.a"? What does the linker error say?
  9. You could maybe elaborate a little more in-depth about the game - maybe even show us. I'll let you know instantly if I find the game good, average, or below average, in my opinion. However, any decent, somewhat playable game programmed entirely by one's self is always an achievement.
  10. I put the link to Lazy Foo's site on the other thread we were on. That site has a whole once-over on configuring SDL to work with Code::Blocks for Windows(that's your current platform, right?). I'll put the exact link here to the tutorial: --> [url="http://lazyfoo.net/SDL_tutorials/lesson01/windows/codeblocks/index.php"]http://lazyfoo.net/SDL_tutorials/lesson01/windows/codeblocks/index.php[/url] I know you'll probably (I was the first time) be a bit confused with the settings and such, but just read thoroughly if it's somewhat difficult, and if you have any problems you can report back here!
  11. [QUOTE]When I code something in C++, it runs it in what looks like Command Prompt.[/QUOTE] Because your build target is set to a console/terminal command-line window(in Windows this is DOS-style command-prompt). It is text-based only - no images or graphics(unless they're made with character symbols or ASCII art). There are a few options you have here, and quite some understanding that would help you out here. Windows graphic-based applications on Windows OS run through software known as DirectX or DirectDraw for windowed graphics, and use the Windows API to manage the controls for the windows(GDI/GDI+ are used as well). This stuff is a complete different implementation on command-prompt windows. There are libraries that offer "wrapping" for this to avoid directly interfacing with this stuff for development if you find Windows API and DirectX to be hard(which many do find them to be). As mentioned, SDL will "wrap" around the lower-level abstractions necessary for window management and graphics(such as DirectX and WinAPI). What this does is gives you an interface that will get you things done faster and easier than with Windows API/DirectX directly. SFML will do the same, and so will many other libraries providing abstraction from the lower-levels of user-space software rendering of the operating system. Aside from what the C++ disliker above is saying, SDL or Allegro is probably what you should be working on and studying now: [url="http://lazyfoo.net/SDL_tutorials/index.php"]http://lazyfoo.net/S...rials/index.php[/url] [url="http://wiki.allegro.cc/index.php?title=Allegro_5_Tutorial"]http://wiki.allegro....egro_5_Tutorial[/url] All of the lower-level abstractions come with more programming experience. The Windows API is the lowest-level API that controls all window structuring and management on all Windows OSes so far, to note. It works alongside with DirectX for optimum software rendering. Learning them both can be ideal and useful, but at this point it would be a little farfetched. [QUOTE]I believe it has something to do with .txt files[/QUOTE] Absolutely nothing to do with text files.
  12. As far as I know, you can't forego any [CODE]this[/CODE]-type reference or pointer to a class object in memory in programming languages(well, at least not in any practical way). C++ also implements the [CODE]this[/CODE] pointer as an r-value: [url="http://en.wikipedia.org/wiki/Value_(computer_science)#Assignment:_l-values_and_r-values"]http://en.wikipedia....es_and_r-values[/url]
  13. [CODE]_stdcall[/CODE] pushes parameters backwards (right to left) on the stack. [CODE]_thiscall[/CODE] gets pushed on the stack, but in normal order, and the [CODE]this[/CODE] pointer is placed in the ECX register. They are simply calling conventions for the compiler when generating object code during compilation.
  14. You can't invoke a function from a function if it isn't defined yet before scope enters that particular function call(in C++, for this predicament). MyRegisterClass() has to be defined above for it to work. Same with the other function. "Identifier not found" is the compiler's way of saying "This function call doesn't exist from this scope yet."
  15. It's like [CODE]using[/CODE] in C++. After a while, when using the STD library in C++, beginners will probably learn this: [CODE]cout << "Hello world!"[/CODE] instead of [CODE]std::cout << "Hello world!"[/CODE] . It is less typing.