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

darkhaven3

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

160 Neutral

About darkhaven3

  • Rank
    Member
  1. Daaark, it might just be me, but I think it's misleading to say "you can't do it without Sony's say so", because that's not strictly true in all cases.  It is entirely possible to write raw C or C++ using PSL1GHT or the leaked v1.92 of the official PS3 SDK and then compile and run programs on the Playstation 3 natively.   I'm a little behind on my PS3 homebrew scene-ology, so I'm not sure if the private key used to sign official software is still a valid means to sign your code to run it on the Cell without modification. IIRC this is a vulnerability that isn't exactly patchable without invalidating all prior officially licensed software on the market in one fell swoop. Maybe this is something the OP can look into.
  2. I still don't understand why you can't just say int id=random()*random()>>random() or something similar if you absolutely must have a totally random and unique ID every time and do checks to make sure you're not getting identical ids every time, and of course you can map the results of your random id assignment to some meaningful array of structs describing the widget or whatever
  3. Really? All I can see is the many hundreds of ways this can crash and burn in a series of amusing ways... more so when you consider the follow up reply about not sanity checking the results...   Sure it can crash and burn if I care to introduce bad definitions in the frametable. Who cares? If the function called by a frame for a particular mobj_t says "You can't move here because I said so", then the mobj_t shouldn't give a damn. All that would happen is the mobj_t would stop moving in that direction, and possibly attempt to move in a different direction arbitrarily. It's not an mobj_t's responsibility to determine where it can move in this specific context; it's handled at a higher level. All an mobj_t is responsible for is itself, or being the target of another mobj_t in special cases (monster infighting, or the player being the target of a monster, mainly). And even in that case, mobj_t's typically don't care if they are targets of one another, and can't directly modify one another's target reference; they will attack one another until it is somehow resolved by other mechanics, typically by means of one mobj_t changing targets to the player or another monster, or entering its death state.   It seems simple and concise enough to be easy to debug and easy to implement, and it seems like it would be quite fast, especially in the context of a 2D sidescroller.
  4. It's heavily implied by the design approach that I'm not going to just allow any frame to start calling functions designed to load a map or initialize SDL or anything, just by convention of how the function-pointer list that the frames reference works. I imagine it will work well enough for the sidescroller I intend to use it with where there's not a whole lot of elegance in object management required. Example being: "Object A tries to move in the direction of object B. Do whatever the function to move this object says to do. I don't care to sanity-check the results; the function will resolve that on its own. The end."
  5. typedef unsigned long coord_t; typedef unsigned char byte_t; typedef signed short mobjtype_t;   typedef enum { MOBJ_CREATE=0, MOBJ_ACTIVE, MOBJ_ATTACK, MOBJ_PAIN, MOBJ_DEATH, maxmobjframes; } mobjstates_e;   typedef struct { mobjtype_t type; frame_t* mobjframes[maxmobjframes]; coord_t mapx,mapy; mobj_t* target; } mobj_t; ? mobj_t represents every possible object in the game world, including the player. mobj_t contains a list of pointers to a master "frame list" that defines things like what graphic should be displayed for this object at this frame, what the next and/or previous frames for the current one are, and a function pointer to describe what needs to be done by this object this frame. mobj_t frames only have access to certain functions in a master list which should, by convention, only interact with other mobj_t types, and what object that ends up being is dependent on mobj_t.target. Objects can do whatever the hell they want to each other after this point.
  6. HTML5 and JavaScript (?) are the target languages here, it appears. For such an application, HTML5 and JS should be more than enough.
  7. I vastly prefer PC to play videogames in nearly all cases, although I do have soft spots for games like the Xbox port of Minecraft so I can play with a friend of mine who doesn't have a working PC at the moment. That being said, I have consistently witnessed ignorant (not an insult) individuals on Nintendo Network, Xbox Live, and Playstation Network who think "PC games are full of hackers" and "X is the most powerful gaming machine out right now". The insufferable arrogance of 12-year-olds screaming racial expletives over the internet at me because I killed them on Call of Duty is also not worth the trouble on Xbox or Playstation... Not to say that's everyone, but I've frankly had enough of it.   That  being said, I am not adverse to programming for the Xbox 360 nor the Wii. I actually had quite a lot of fun at the time getting a simple JPEG decompressor routine to get up and running on the Wii back when I was new to it! And there's just something really nifty about spending a late night finishing up X or Y tweak on a raycaster engine you've been working on for Gameboy Advance, and being able to take it with you and show people in the palm of your hand, on the original hardware.   So in short, I think console gaming is more or less intolerable in most cases and I absolutely prefer playing on PC. However, as far as programming goes, I have a fondness for the Gameboy Advance, the Wii, and several other "vintage" consoles.
  8. You're basically going to make an engine if you're not going to use a pre-built one, regardless of simplicity. Using a pre-built one might save you some time, but that time is taken back by figuring out how the engine works and how you can apply it to your game concept.   For something so simple, though, you might just be better off writing your own code from scratch, IMO. It shouldn't be exceedingly difficult.
  9. id Tech 4 and Unity 3D are rather different technologies from UE2.5-3. Comparing between these three engines running identical hardware, Unreal Engine 3 is going to invariably be slower than id Tech 4... Not necessarily "worse".   Don't get me wrong, I personally hate the Unreal Engine and have hated it since 1997, but what I was really trying to say was "a game engine written X years ago is going to run faster than game engine Y written yesterday." Get what I mean?
  10.   Hardly true at all. If Doom, the Quakes, and then Rage have proved anything, it is that there is still a lot left to be done on even current-gen hardware. Rage running at 60FPS on the equivalent of a Radeon X1800 is nothing to laugh at, and neither is the notion of writing one's own graphics engine. As far as having "nothing left to invent", again, not true at all. A game made with Unreal Engine 3 will look different and run much slower (invariably) than a game made using, say, id Tech 4 or Unity.
  11. If you know Java, stick with that! If you're SPECIFICALLY trying to learn a new language, try out C or C++.
  12. ... And thus, a misconception I've had for years about what rand() is doing was today blasted out of my mind. Wow.
  13. Unity

    [quote name='web383' timestamp='1355937929' post='5012508']I need to comment on this though. I feel like you've used the word "we" as if everyone is as experienced as you in writing software. Not everyone understands the concepts of these core engine features - nor does every game even require some of the features you've listed above.[/quote] Then maybe that individual shouldn't be writing their own game engine just yet. It is common knowledge that a good game in this modern era generally requires that there be a standard format or formats for images in place that you will read from the disk, audio of some form, and some kind of user interface. I believe all of these can be cleanly separated into core components of a [i]game engine[/i], and you don't have to be the most intelligent person in the world or even a programmer at all to understand these requirements. [quote]How does one even implement 'camera panning' without some concrete requirement of how it's going to be used? I'll usually fall into the "what if the end-user wants to do this or that" trap... and will ultimately end up writing a bunch of code that never gets used. Personally, I'd rather write a feature for a requirement of the game, instead of some generic feature. And then, if I notice this may be a nice chunk of code to use again, factor it out.[/quote] This implies that the programmer has no idea what kind of game he will be programming, or will be somehow working on-the-fly without some kind of design document about how the game should be implemented written down first. If you are writing a text adventure, you know you will not need camera control of any kind. If you are writing some kind of 2D or 3D game, you will certainly need some kind of "camera" in as abstract of a sense as I can put it. Don't need a particular camera feature for your game? #ifdef it out in your game header files or something. [quote]Writing software without concrete requirements can be very difficult, which is why I believe writing engines can be so difficult. Writing a game/demo/unit test is so much easier because those applications inherently come with a set of requirements which have purpose, and can help keep a programmer focused.[/quote] If you don't have a game design document that clearly outlines the scope and format of the game before you start writing code, I believe you have more serious issues to attend to than deciding how to write your engine. These are all issues that seem easily resolved at the planning stage; if I'm writing a game for Gameboy Advance, I can have it on good faith I'm not going to be needing things like vertex coloring and DX11 tesselation. Likewise, if I'm writing a game on PC and I want it to look fancy, I can implement these features and I will know that I will need to have this information stored in some kind of consistent format. In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.
  14. [quote name='kunos' timestamp='1355938622' post='5012513'] this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else.. at that point it becomes really hard to figure out what's going on... this, again, has nothing to do with OOP but more to do with global state and basic programming theory. Of course, from a programmer's point of view, being able to access every function and every variable feels like a good thing, but it quickly turns into a total mess... and the problem gets bigger as the software gets bigger, so you might get away with it with small code bases. [/quote] I think I can safely say that the above is pretty much a nonexistent issue. In C, you cannot "access every function and every variable"; a static int declared within a function remains within the scope of that function, and cannot be overwritten directly. Of course, it's quite possible to do so intentionally, in the same way that it is with any OOP language that doesn't do bounds checking on arrays, if you get where I'm going with that. If I don't want a function to modify something, I'll pass it a pointer-to-const (i.e. const int* var; ). If I want a variable to be available locally to a function, I will initialize that variable within the function that requires it. Not much more to it than that, honestly. If it comes to a point where data is being modified that I didn't intend to be modified, I can always have a look at that nifty map file the linker generates, which is available to both C and C++ programs.
  15. After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing? But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer. A recent example that I can think of is the IW engine (used in every single major Call of Duty title). It's based directly on the Quake 3 source, so I can imagine it's probably in C still.