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

BryanCroteau

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

105 Neutral

About BryanCroteau

  • Rank
    Member
  1. So I bought Antichamber on steam. Big mistake. Apparently the developer decided that 100% of the population is right handed, so there is no reason to support primitive functionality like key bindings.
  2. Apparently there is a forum on gamedev where you can spam and it's OK! Who knew?   Announcing.... TacticsEditor! I've been working on this simple WPF/C#/AvalonDock tool for about 5 months part time, mostly on weekends. It supports multi-level undo, and it behaves rather well when you try to be sneaky and remove the flash drive you saved a project in....   Anyways, here is a video that should demonstrate what it can do. It's actually inspired by the old TimeSplitters 2 mapmaker, but for Fire Emblem-style tactical RPGs. If there is anyone on these forums that likes Fire Emblem AND TimeSplitters 2, then he or she should be able to understand my reasoning behind working on this project. I hope to promote the idea while at the same time submitting it to the community at large for critique.   http://www.youtube.com/watch?v=7OfAHHDApAM    
  3. When I was doing SQL-type work last year I was serializing datasets and sending them over a network. The serialization used something called XSLT (I think) to translate the serialized XML into a more readable format, and back. The actual output xml was used in conjunction with a Visual Studio tool called XSD to generate a schema file and then C# classes. I think I used: xsd Data.xml xsd /classes /namespace:YourNamespaceHere Data.xsd This type of technique could be automated with a shell script I am sure and maybe generated/executed at runtime. I am not a very experienced developer so I can't say for sure. But if you are interested it might be an idea to look into the xsd.exe documentation on MSDN. Either way, it was for a business application and I am not sure if it is efficient enough to use in a real game.
  4. [quote name='Antheus' timestamp='1320797407' post='4881926'] If concerned about interaction design, then asking whether a token field is a suitable solution would be a better question. How it's implemented is a technical detail and not something that ID or UX does. [quote] true object oriented design often takes a back seat to the demands of the implementation[/quote] OOD is said to be sound if it suitably models the target domain. Current frameworks, such as WinAPI, WinForms or similar model the WIMP paradigm, which is essentially unchanged since it was invented in 1960s. That one in turn was influenced by interfaces of the time - boards of switches and dials. Once upon a time, there was VisiCalc. It wasn't great, it ran on 8-bit hardware on 40x25 screen, in monochrome. Yet it was an instant hit among population that never saw a computer before. Why? Because people got it. They didn't need training, they knew what a spreadsheet was, they used them every day and now it was on screen. Between many radical and improved approaches to spreadsheet software, Lotus 1-2-3 eventually took over, despite being the "poorest" of alternatives. Again - users just got it. It didn't try to pretend to be something different, it simply was a spreadsheet. Today's APIs arose around such expectations. We still have windows, icons and pointers. Web changed a few things. Despite having probably the most broken development model and lacks any kind of standardization, it iterated into usable and familiar from. Single, two or 3 column layouts, expectations on navigation, content density as well other details about how documents are presented and navigated, it eventually built upon the newspaper layout. It can be argued that it's not the best we could do and better alternatives exist, but it's familiar to users. Of more radical changes, Apple is the clear winner. They are first to successfully break the WIMP concept through introduction of touch and gestures, completely redesigning what users expect from applications, yet managed to deliver it in, again, familiar form. Note that in none of these cases the APIs matter. Computers still do the same basic things. They read inputs, then render either shapes, text or blit squares. So the fundamental APIs are perfectly fine. An important aspect of usability is also in details. Controls provided by frameworks today do a lot. Stuff many never heard about and wouldn't unless they try to implement them. How is a font defined, the impact of kerning, line breaks, word wrap. When to overflow, when to truncate. What about other languages, BiDi, top down, symbol selections, various IMEs, the proper scaling depending on DPI setting of desktop synchronized to mouse or other input DPI, proper alpha blending based on monitor gamma profile, lcd/led specific aliasing, .... the list goes on and on - and to make use of all of this, the combined effort of decades of experience provided by hundreds of millions of users, all you have to do is type "new TextBox()". It's a big but mostly "soft" field. There are no absolutes, emotions and impressions matter as much as marketing and price and depend on each other. Simplified and approachable forms of interaction design are present in progressive web development today in forms of designer templates and metrics analysis. Desktop has been somewhat stagnant, but at least it offers vast array of pre-packaged controls out-of-box, which offer a familiar experience to typical users. [quote]What are your thoughts/opinions and have you applied any of the techniques described in the book?[/quote] I listened to a presentation given by people from a company that specializes on these topics as part of marketing efforts on web. One of the points they raised was that a requirement is to be lacking hair. Or - it's a field for seasoned veterans with 15+ years of cross-disciplinary experience. It's simply not something you walk into, write a few lines of code and call it a day. I don't remember which site exactly, might be NYT, might be some other similar site has 50+ department dedicated to nothing but UX. Some companies have hundreds employed in similar roles and they aren't even classified under IT or programming, despite being concerned primarily with web design. [/quote] A very well-written and intriguing response. I suppose it's what they call "standing on the shoulders if giants." And VReality, is that a complement?
  5. I am currently reading About Face 3: The Essentials of Interaction Design. This book speaks to me, it really does. Not because I am a design-oriented guy frustrated with bad software, but because I am a programmer by trade and I am guilty as charged of taking shortcuts in implementing prototype interfaces and then coming back and having to re-architect the code to implement the other 20%. Often times the popular programming patterns are the direct opposite of user friendly, even with object oriented languages, true object oriented design often takes a back seat to the demands of the implementation. I am inexperienced and haven't been working in the industry long though, so that might be one factor. Some problems are just so difficult and timelines are so unrealistic that there is no choice. Recently I had to implement a sort of token field (like what you find in mail clients, Mac has a build-in control called NSTokenField iirc) in C# WPF and in the end the solution that actually worked was to serialize a RichTextBox to XAML, edit the XAML using basic string manipulation, and serialize the control again to be rendered. This implementation is so radically different than the correct "programmer" way of doing it, which would be to define a special control with special behaviors from scratch, but it doesn't seem to interfere with usage so in this case we dodged the bullet. Anyways, has anyone else read this particular book? What are your thoughts/opinions and have you applied any of the techniques described in the book?
  6. What about function pointers, lambda expressions and closures?
  7. I think you guys are completely misunderstanding what I originally asked for. All I am trying to do IS render a quad to the screen and apply a pixel shader to it. Seriously guys, I learned HLSL in like 5 minutes doing the tutorials included inside Shazzam. I spent weeks trying to learn Joomla with absolutely no web experience whatsoever, I even asked on their forums for tutorials that give instructions, and I got similar responses. I told them: I don't need implementation specific details, all that stuff should be abstracted far beyond what is seen by the user." It was only after I found some videos with step by step instructions on what to DO that I began to understand how it worked internally. And I was using some pretty nifty features after just watching about an hour of tutorials. I understand that you guys think the introductions are widely available, but as I said they are not good enough because they lack a key element: interaction. [url="http://www.rastertek.com/dx11tut01.html"]http://www.rastertek.com/dx11tut01.html[/url] contains a "To do list" at the bottom, and while there is only one, I'll have to give it the benefit of the doubt for now. In the end that's the kind of guided experience I am looking for. And while I think Zern is a troll I have to thank him for posting this. It was not one of the tutorials I found while searching by myself.
  8. Basically what everyone is saying is that there is wisdom in not trying to be a good teacher and not trying to improve the learning process because the status quo has the advantage of teaching people how to learn without teachers. To me this seems absurd.
  9. [quote name='Jason Z' timestamp='1319399799' post='4876076'] I may be walking into a bee hive here, but I am going to try to help - and give some suggestions even if you don't want them. The basic topics that you have questions about are the very first principles of working in computer graphics and their APIs. In order to get something done, you must have some basic background knowledge of the subject or else it isn't going to do you any good to get through this tutorial task.[/quote] I have rendered my own scenes in opengl, texture loading, terrain generation with perlin noise, and custom shaders. I fully understand the high level concepts, and I understand pixel shaders rather well. I don't work as an engine programmer, I'm actually a tools programmer, and recently I created an HSV color picker for WPF with the bulk of the work being done on the GPU by an HLSL shader. My area of concern as a programmer is human-computer interaction and ease of use, not rote memorization of particular implementations. If it's any consolation, I have read through every documentation page in the D3D SDK sample browser that deals with the basics. As I have said, they are [i]not[/i] tutorials, I cannot think of an analogy better than the airplane analogy I gave above. [quote name='Jason Z' timestamp='1319399799' post='4876076'] For example, do you have any concept of the rendering pipeline? There is geometry fed into the pipeline from vertex and index buffers when a draw call is executed, and that geometric data is transformed in a vertex shader to position it within the current view port. That transformation is done with world, view, and projection matrices, which are usually concatenated together and supplied to the vertex shader through a constant buffer. That transformed geometry is then rasterized to produce pixels, which are then subsequently processed with the pixel shader (similar to what you have already provided). This overview covers the minimal pipeline setup, with all other programmable stages disabled (which is done by setting null into the corresponding shader slots). What you are trying to do is cover the entire viewport with a single triangle or two, so that with a minimal amount of geometry you are going to invoke a pixel shader for every pixel of your render target. The choice is yours in how to accomplish this - you create vertex buffers with some input geometry, and at the output of the vertex shader you need to have the x and y coordinates over the range of -1 to 1 being covered by the geometry. If you use one triangle, then you can just make the input vertex positions be large (such as v0= {-1,-1,0,1} v1={-1,20,0,1} v2={20,20,0,1}. With these vertex positions, your geometry doesn't need to be modified at all - you can simply pass the input values to the output of the vertex shader. This will then produce a single fragment for each of your pixels, which is what you wanted in the end. The actual code snippets to create a vertex buffer, bind it to the pipeline, setup the corresponding pipeline states, and then call the draw call are all available on the internet. In fact, most of them are available in the DXSDK documentation... However, I would suggest that you not simply hunt for the code snippet that you need for this one task, and rather that you invest some time into understanding more of what you are doing with the pipeline.[/quote] Yes, that's all nice. And I promise that if I understood [i]how[/i] to do this I wouldn't have made this thread. [quote name='Jason Z' timestamp='1319399799' post='4876076'] I think you instructors in college may have done you a dis-service by spoon feeding you code tasks - if you don't know anything at all about the underlying system that you are programming, then have you actually learned anything by following a recipe style list of things to do?[/quote] What evidence do you have to back up this statement? Are you a teacher? What statistical information do you have correlating a particular technique with retention and self-reliance? [quote name='Jason Z' timestamp='1319399799' post='4876076'] I don't think so - but that is just my opinion. So when you write your code sample for your portfolio, if someone checks it out and they ask you to modify it to do something else, what will you tell them??? I know it is a gigantic topic to dive into, but if you put the time into it, you will surely learn about it and be better off not to need to rely on others to provide sample code for tasks like this. Again, this is just my opinion, but I truly hope that you follow my advice and spend some time learning the background info on at least some of this stuff - you just might like working with it![/quote] Oh I would love to. Here is the use case scenario that I encountered. Right, I search for tutorials on the internet on learning Direct3D, and every last one is exactly the same: mile-high overview of the topic with mathematical graphs and representations of vector spaces, along with working code. It is missing the most important ingredient, the very essence of learning, and that is interaction and feedback. I understand what you are saying, and you think I would be better off learning from the ground up, but what I am trying to tell you is, and this is not just true for Direct3D, the [b]information out there is not good enough[/b]. I know for a fact that if I knew everything there was to know about Direct3D, I could write a tutorial that nobody would ever be confused about. I work hard every day and even on weekends implementing the functionality my clients want for my company. WPF is a very counter-intuitive framework for computer science students because it goes against everything you learn from assembly up. All computer instructions translate into load, store, math, conditional, and jump statements in the end. Everything from delegates and polymorphism to threading and serialization and abstract data types are all just combinations of these five elements. But WPF throws a lot of the traditional programming styles out the window and uses instead static property tables and automatic synchronization of variables and whatnot. It was extremely difficult to learn and the tutorials out there are just as bad as Direct3D. I am not saying that what you ask me to do is impossible, I am saying there is a better way. I promise you that if you researched it yourself and experimented with people who have never used graphics libraries before, you would quickly change your mind about spoon feeding tasks.
  10. [quote name='YogurtEmperor' timestamp='1319382206' post='4875616'] I am not willing to dumb it down as far as you requested, because if that were necessary then you would have no place even attempting what you are attempting. We can all assume one of the first things you learn how to do is to set a projection matrix and to create a vertex buffer and render those vertices to the screen. Right? If that is already above your abilities then you have some more tutorials to read, and yes these things are covered in tutorials. This is the bare necessity for getting anything onto the screen, which is why not every tutorial covers it. It [i]must[/i] be assumed you already know it. So let’s assume you do know that much, because I am not willing to cover it, nor is anyone else. Draw a full-screen quad.[/quote] No, I don't know how to do any of that. I haven't done any graphics programming since college and even then it was in OpenGL and my teachers provided detailed, step by step instructions that you could slavishly follow and believe it or not, it worked remarkably well at the time. But what I am saying is, these things are NOT covered in any tutorials. The code is given to you with a high-level explanation and that's it. It's like showing a person an airplane and then explaining the physics that make it fly. It doesn't matter if the learner understand the physics, they'll still crash. When somebody makes a tutorial to DO something, they cannot assume the learner knows anything at all. You don't need to know the details or even the basics, you just need to DO something and over time the basics will become obvious. [quote name='YogurtEmperor' timestamp='1319382206' post='4875616'] #1: Create an orthogonal projection matrix that spans the entire screen width and height. Study the D3DXMatrixOrthoLH() function. D3DXMatrixOrthoRH() may do just as well because you may as well just turn culling off for this process. -1.0f for near, 1.0f for far. Fairly sure you can figure out how to pass the window size to that function on your own. IDirect3DDevice9::SetTransform( D3DTS_PROJECTION, mat ) that matrix. #2: No need for any camera matrix. Set the view matrix to identity. #3: Create a few vertices at [0,0], [1,0], [0,1], and [1,1]. If you know how to make a vertex buffer, and you do, then this is no problem. #4: Make a matrix that scales the X and Y up to the screen width and height. D3DXMatrixScaling( MAT, SCREENWIDTH, SCREENHEIGHT, 1.0f ) and then apply that to the world matrix. Now your vertices will be scaled to fit the screen. #5: Put the source texture(s) into the slots in which they belong. Whatever image you are trying to render over the screen needs to be in slot 0. If you want to read from multiple targets, put them into multiple texture slots. The rest here has nothing to do with just “rendering a full-screen quad”. I am sure you can figure this out.[/quote] 1) Where? In the initialization, render, or re-size callbacks? How will this conflict with the existing code in the tutorial? How can I know? 2) Once again, where? There are 900 lines of code in the sample I am working with. 3) No, I don't know how to do this, because when I tried it crashed on startup and gave an error message: "the direct3D device has a non-zero reference count, meaning some objects were not released." 4) Again, where? 5) The resource I need is a cube map defined in the FX file already by the author of the tutorial. As far as I know it is in scope of any shaders I try to apply in various places. I applied my shader in place of all the shaders in the file already, with different results. For instance the reflection on the car's windows was the effect I wanted, but I have no way of applying that to the whole screen. [quote name='YogurtEmperor' timestamp='1319382206' post='4875616'] Sometimes the lack of completeness in tutorials is annoying, but when you have enough experience you are able to fill in the gaps, and that is what the authors expect. Because if every author for every tutorial had to explain things from the ground up we, as humanity, would not be progressing very fast. We would all be spending our time covering and re-covering the basics before we could present anything new. It is generally understood when writing an advanced tutorial that your readers will have a firm understanding of the basics. And don’t feel left-out. I used to get angry at tutorials that did not feed me every tidbit of information. It took many years to realize that that was just because I was trying to stand on the shoulders of giants to accomplish something without actually understanding what I was trying to do or what they had done.[/quote] We wouldn't progress fast if we had to explain the basics? I fully disagree, and I can provide an alternate theory that contradicts your statement with evidence and examples, and an entire book, to back it up. You don't need to understand what the giants did or the fundamentals that the used to invent something new. You don't need any formal training to follow instructions and you don't need any knowledge to learn from mistakes as long as 1) You receive feedback on those mistakes and 2) there are no consequences to those mistakes that prevent you from advancing. For instance, if you make a mistake flying an airplane you die. No feedback to let you get better, and an important consequence that prevents you from trying again, namely, the fact that you are dead. I believe there is a quote from Dune: "Muad'Dib learned rapidly because his first training was in how to learn." When you go ice skating, the little Asian girls skate the best and fall down every few seconds. Humans learn by failing over and over and over in rapid succession with constant feedback. The book "The Talent Code," or even just the first chapter which is available for viewing online, has a number of examples. Take the Shazzam shader editing tool for WPF/Silverlight. The environment is set up so that you have immediate feedback when you make a change, and you can immediately see the visual effect of the change. Furthermore, when you read through the tutorials [i]provided inside the program[/i] (which by the way is a fantastic place to put them), there are commented lines that say: "change this line to this and see what happens" and: "do this and try getting it to look like this." If you think back about how YOU learned Direct3D, I guarantee you the sum of your experience has followed the same pattern, try something, if it doesn't work try something else, and over time you master the details and are ready to stand on your own without the shoulders of giants. [quote name='YogurtEmperor' timestamp='1319382206' post='4875616'] In a few years you will look back on your former self and sigh. And then move on to finishing that crazy new graphics algorithm you are inventing. L. Spiro [/quote] Hopefully in a few years everyone will look back and see the former methodology of teaching Direct3D and laugh at how stupid it was.
  11. I am working on a tech demo for my programming portfolio, and I am using the CubeMapGS Sample in the DirectX SDK Sample Browser. Like all computer graphics tutorials, it is less of a tutorial and more of a gratuitous high-level explanation of nothing useful to somebody without code that does what they want, (though I suppose the incompetence of humanity in coming up with decent tutorials for any topic --except how to build a Lego-- is a discussion for another time). My tech demo has very specific needs. Let's say I have a PS: float4 PS_Final( VS_OUTPUT_SCENE vin ) : SV_Target { return float4(1.0, 1.0, 0.0, 1.0); } And with no guarantees on the syntax, this shader should return yellow pixels. Now, I want to apply this shader to the entire screen after everything else has been rendered. I have been told that you basically need to render a screen quad and apply the shader to that quad. Except I wasn't told HOW to do this, of course, because one thing you can count on on the internet, 0% of graphics code actually compiles and runs. So I tried migrating some of the code from the "render a triangle" tutorial into the cubemap tutorial, and it didn't run. Some horrible thing that I didn't do quite right. Maybe it's the fact that it takes 300 lines of code to render one triangle, and I tried finding a way to migrate the important code into the cubemap sample which is itself 900 lines long without knowing anything at all about the DirectX library. What I need is step by step instructions on how to apply this post processing pixel shader. Do I need information about computer graphics, history, theory, pretty mathematical representations? Not really. Will those things be helpful? Not at all. What do I need? Instructions that when followed lead directly to my goal, nothing more. If you can't provide instructions that a 6-year old could follow, please don't bother trying to help. There is PLENTY of useless non-instruction information on the internet. You can't expect any human being to look at a picture on the box and put the pieces together without instructions.