• Content count

  • Joined

  • Last visited

Community Reputation

282 Neutral

About N=1

  • Rank

Personal Information

  1. Ah, I had not thought about the MMO* scene at all. A player-involved (or player based) economy makes it a far more complex problem. I agree that it is not necessarily any good there.   But let me re-phrase the question: why are there so few single player games that have an in-game store that has items for sale?   In a single player it would make a lot of sense IMHO. It adds a meaningful choice on how to spend your money. It adds realism to the buy-stuff-at-the-store experience. And it can even be used by the game designers to steer players towards certain kinds of items. For instance the 'on sale' mechanic could favor items that help in certain quests the player is currently ignoring.
  2. Many games have in-game shops where you can buy gear. But I just realized that hardly any game has items that are temporarily 'on sale', i.e. sold for less than the normal price. I'm talking strictly about things you buy with in-game money.   Decker that this mechanic hidden in its shop. Basically you can always order all items the game has, but you can get the current stock of the shop for a good discount. But I can't quickly think of any other games. Why is this?   I liked the fact that in Decker I have to weigh my options: wait for an item to be in the shop and get it cheap, or just bite the bullet and order it for full price. So why are there no other games with this mechanic? Is it not worth the complexity in the UI? I find it unlikely that nobody has thought of adding it to their game.
  3. Conventional Storytelling in Video Games

    This is a question I like! First of all I'm going to agree with Sunandshadow that a crucial ingredient is that the story/narrative is not something that someone tells, but rather that you experience. An important ingredient is that the more meaning you assign to the events of the story, the more impact it has on you and therefore  the stronger the story is. I almost feel that we need to rename "storytelling" to "story-experiencing" in order to better address this subject. Ok, so translating this to games I propose the following types of story-experiencing in games: 1. -> Games can tell stories the classical way by presenting a narrative and having the interaction (gamey bits) be separate from the narrative. Take JRPGs as an example: here (in a lot of cases) the meaningful events (the story) are outside of the control of the player. So the player will experience the narrative in roughly the same way as a book or a movie. In effect the story and the game are separate things. The game may re-enforce the storytelling during the gamey-bits through its tone or through its mechanics, but the playing of the player cannot influence the story that is told. Don't get me wrong, there is some progressive stuff to be found here. Take "Lonelines", this is a good example of mechanics alone that convey a story. But still I would argue that here the story itself is firmly in the hands of the game and that the player only gets to receive it. 2. -> Games can also tell stories in a way as to allow the players to have some control over the narrative. The player can make a few key choices (be good or be evil is a popular one). And this usually increases the meaning the player assigns to the events that follow those choices if the game does it right. The problem in expanding the amount of choise a player has, is that it is very hard and expensive for a game to have multiple endings that are all consistent and plausible. From a cost perspective the developers will want to re-use enemies, scene's and backdrops so they usually don't like to have vastly different stories in a single game. Mass Effect is good representative of this kind of storytelling. You get to make a lot of small choices (besided the good/evil thing) and the game does its best to enforce the consequences of those small choises. This increase their meaning and enhances the story-value of your actions. 3. -> A third kind of stories takes place in games is where the game allows the player to construct its own story. Take Minecraft where the player only has a vague goal. The randomly generated terrain will ensure that each playthrough is different, and forces the player to come up with new decisions on what to do and how to achieve this. Those decisions have meaning as they are the player's. The game just set the stage for the story. This is effectively role playing the sense that the player will (usually) not go for a 100% optimal strategy. By allowing to accomodate other wishes (make a better house, don't slaughter all the cute animals, ...) the player is shaping the sequence of events and thereby creating its own story. But even if the player is not roleplaying in the sense that the player goes for 100% efficiency, the unfolding of events can still have great meaning to the player. This is usually the case if the player knows that the game was not scripted for these event but that they are personal, unique to this playthrough. This is the case with many roguelikes, but also with other games that have permadeath and random terrain. As a side note: the great thing about this third kind of stories is that there is value in retelling them (as more regular stories) to other people. --- My personal favourite story moment in games is still how to evolve your Jedi in Knights of the Old Republic. (Huge spoiler) you will need to decide how to react to the discovery that you have been betrayed. From a storytelling perspective it is very good that the game has no real meaning about what you choose to do. This seems contradictory, but it breaks from the mold of second kind of storytelling and allows you to fully roleplay. Since the event itself is so shocking (at least the first time) you assign enough meaning to it without needing the game to re-enforce it. So, as to answer the OP question: (how to) tell a story in a truly unique way? I would say that a mix between the second and the third type of game stories would probably be where the future lies for innovation in computer narratives.  
  4. Project: Dark Mines Dark Mines is a roguelike game where you play as a miner who searches a series of caves for gold ore while doding traps and foes. The caves are randomly generated and the idea behind the project is to build up to an epic game with an epic storyline. But for now I'm sticking to the advice of Extra Credits and I'd like to invite people to have a look at my first version, which is sort of the minimum viable product. This means that this is an extremely basic version of the game. It works, has dangers and rewards, but is far from complete. I'm open to any feedback. Can you get it to work on your machine? Is it any fun to play? What did you enjoy and what did you hate? This is the first time releasing a game for me so all feedback is useful, even if it just to say that it doesn't run on your mobile phone (which it doesn't ). I have a small blog on the development of this game: nisone.wordpress.com   Running the game The game is written in Java so you needs Java to run. Fortunately I have made a version that includes an embedded version of Java. But if you do have Java then the download is very much smaller... Option 1: "darkmines-milestone-1.jar.zip". Unzip and double click the jar to run it. (You have Java installed) Option 2: "Darkmines-milestone-1.zip". Unzip somewhere and click "darkmines.exe" to run. (Windows only) Legal: the game is provided under the beerware license. It contains code of JGame which uses the BSD license. No intentional bad things are in this software, but use at own risk. Full license: here Cheers!
  5. Render Management

    I would say that your pattern looks pretty decent.   One reason to remove the rendering code from the Enemy class is that rendering graphics and performing AI calculations are two pretty different things. If the code for each action becomes too big it might make the Enemy class cluttered and unfocused. Then you might want to start thinking about other ways to structure your code.   But until you reach that point, I completely agree with Glass_Knife, just go with it for now.
  6. Thx for all the tips and links, took me a while to pore through them but it was fun! Especially looking for the right video in Extra Creditz's... All in all, most articles are similar but not exactly what I was looking for (but still good, so I'm thankful for them). CulDeVu, the article you referenced (Chemistry of game design), comes closest to what I am looking for and is an interesting read. I'm not sure I buy the 'gameplay = learning' as an end-all concept but the material is surely useful. Skinners box application to games is coming close, but I think there is more to it than just the negative 'grindstyle' implementation. All games must be Skinner boxes at some level because we would not do anything if it wasn't rewarding. It all depends on what question you want answered. Instead of 'how can I make players play longer' you could also use it to try to answer 'how can I make players be more engaged'. The person I got the theory from mentioned something about 'pathing' (not sure it was exactly that word) to describe the way you get players in stage 1. (Presentation) to understand which actions they can take. Anyway thx again, I'm going to stock up on my general knowledge of 'Game Studies or Gaming Theory'
  7. Hi everyone,   some time ago I had a very nice chat with someone who studied game design. We talked about theory and I asked him if there were any standard works, books about game theory that are a must read. He said they did not use those at his college but he did explain that there was one basic theory that was central to all design. I can't remember the name of the theory (or whether it had a formal name) but it ran something like this:   Interaction works in cycles. Every cycle consists of three phases:   - Presentation: give the player/person a choice to do something - Action: the player/person takes the action - Reward: there is some kind of reward for the action   He argued that you can break down most things (including games) into this, and it can help you to figure out why people do stuff, and how you can make your games better.   I've been googling for this, but have not found any specific game theory results. Perhaps it is more behavioral psychology, but it seems very relevant to games. So I was hoping someone would recognize this theory and could point me in the right direction.   Cheers!
  8. One of the things that I think is interesting is that you showcase a lot of technology, but not a lot of gameplay yet. This is not a critisism, it is more of something I recognize from my own work. As a programmer I am delighted that it all works. But as a game designer I think; that does not make a game yet. I have this with my own work more often than I would like. Maybe you can make a few playable levels first to get a feel for what is fun in this game, before creating the entire crafting engine. I know this might sound boring, but I'd bet that you get some ideas and some more valuable feedback if people can play a level or two.
  9. Wow. As I'm working on something similar, I appreciate all the technical details in this game (LOS with lighting!). I think it it has lots of potential. It runs very smooth, path finding is nice, the graphics are basic but work and I even found that there is some strategy using lava to deal with the undead. But as Morikubo implies: the first thing you need to work on is the pacing of the game. The first minute seems to feature everything there is in the game: - bad guys - pets - treasure - gear - deadly lava - doors and probably some stuff I didn't figure out yet What annoyed me about this version was that I did not have time to figure out the controls before the first group of bad guys arrive, making it hard to actually explore the game. Oh, and please look at the control scheme. The use of the mouse to pick up gear clashes with the rest of the keyboard interface. Can't you just pick stuff up when you touch it, like you do with coins and health? But I applaud your effort and I love seeing a game like this in Java!
  10. Awfully many sprites, what to do?

    Measure before you optimize. You might convince yourself you don't need to. And even if you find out that you do need to optimize, you are now capable of measuring the effects of your optimizations. Use System.nanoTime() at the start and end of your render cycle to get a feel for your render time. Don't use System.currentTimeMillis as it has an unreliable resolution that can be in the order of 20ms.
  11. Memories in Games (long)

    This is a construct that I think is nice: I like the idea of fading memories and how you can convey this in a game. First off: from what you write I am totally not getting the concept that Justas is forgetting about his daughter that he is in the progress of rescuing. I fully acknowledge that I have way to little info to go on, but the devil is always in the details. Why is Justas forgetting? What exactly is he forgetting? This may be useful questions to style the scene and give it more meaning in the context of the rest of the story. Also I don't believe that you will get any mileage from the words "find the sweet spot between obvious and subtle changes". This sweet spot depends on factors like target audience, game style and others so you will have to figure this out yourself (or give us lots of more information if you want advice). But we can brainstorm a lot of ideas that you can use in this scene anyways. Ideas such as: - The color scheme could go from bright to sepia or black and white - If you want to highlight changes you can always just have the changed items be... well highlighted in some way at the start of the scene. If the birds disappear then you can start the scene just before Justas enters. The birds are there and slowly fade out. Then Justas enters. You can also have things fade out when Justas gets close to them. This would change the scene into a sort of hide&seek thing. - I am curious why the buildings are uninhabited, this struck me as contradiction to the rest of the uber-happy scene. If one of the changes you want is in the tone of the scene then the state of the buildings is a good subtle change candidate - Changes in or removal of sounds and music. Lots of possibilities here. Most of all I think the hardest part of this scene is how to keep the players interested in re-experiencing it several times throughout the game. I would be tempted to press cancel sooner rather than later once I -as a player- figure out what the scene means and there is no additional value. You can make subtle changes to what it means if Justas is not just remembering, but if he is actively trying to remember. So that it has consequences in how good the player performs at this. Then exploring each repetition is at least rewarded (but might still not be interesting enough just like that). The opposite route to go, is to gradually remove the player interaction, and have become more of a cut scene each time (thus removing the burden on players to do repetitious actions). Actually I quite like this idea, as it also implies loss of memory. First the memory is so vivid that it feels like you are still making the decision. Later the detail decisions are remove, etc, until all of your memory is a movie or even an image. I hope this all helps and I am curious what you decide to make of your dream/memory sequence.
  12. Generic classes of generic classes?

    Let's start with the most profound -and hard to follow- advice for software developers: [url="http://en.wikipedia.org/wiki/KISS_principle"]KISS[/url]. In that spirit you have already described your simple solution, so I would run with that. Just for the challenge of it, let's explore the complex solution. Keep in mind that I strongly advice against this unless you have really compelling reasons to want to save on a single extra property of the QuadTree class. Basically you want your node references to hold either a QuadTree class reference or a reference to your target class. The rules of inheritance state that in that case both must have some common super class or common interface, otherwise it will never work. So if you really really want to do this, you can have your target class implement a QuadTree interface. This seems a very intrusive way (as seen from the objects you want to store) to implement it, but it works. There is an alternative solution. Use the one common superclass that all classes have: Object. Each node NE, NW, SE, SW is just of type Object. You can still use generics to restrict what goes into and comes out of the quad tree, but you use it in the getter and setter methods. Now inside the QuadTree you will have to do a lot of instanceof comparisons to find out what a node is (ugh!), but it should work as well.
  13. Heya, I can relate to you, as I also thought: let's make a 2d rpg like thing in java. I did a quick scout and found that [url="http://www.13thmonkey.org/~boris/jgame/"]JGame[/url] gives a fast starting point. I'd not recommend it if you want to have a clean engine. But for getting started quickly, there is no match. I used the Dungeons of Hack code as a starting point. There is an applet version if you want to check it out ([url="http://www.13thmonkey.org/~boris/jgame/JGame/html/applet-dungeonsofhack-scroll-600x400.html"]small[/url]) ([url="http://www.13thmonkey.org/~boris/jgame/JGame/html/applet-dungeonsofhack-scroll-fullscreen.html"]fullscreen[/url]). Good: you have the code and graphics of this game as a starting point. Bad: it is not the nicest code. So if you want to learn how to program more than you want to learn how to make a game, I'd stay away for now.
  14. New to this need some help

    I was thinking along the same lines as ppgamedev. You are probably returning a Rectangle to do collision detection. If you define a class (Shape) that can detect collision of a point [x, y] with itself then you are free to implement whatever shape you want and have a custom collision detection for each shape. Now this gets complex fast if you want to detect collisions between to arbitrary shapes, but it might work for your setup.
  15. New to this need some help

    Yes, exactly! Now I have a little old school OO advice to add to the wise words of be-the-hero. And that is that one of the best way to make classes and decide what to put in which classes is to think about the responsibility of those classes. Responsibility formal CS lingo for that a class should mind its own business. But what business is that? Actually it is that business that is implied by its name. You have a class named "Player". The name implies that this class and this class alone represents the player as a whole (in the context of your game). And it should be this class that manages everything that happens inside the player. Having a player consist of a location and a weapon is great. The weapon knows how to fire bullets (create bullet objects) and the weapon can decide when it can fire again. So the weapon class also fits the 'mind your own business' rule. I envision that you will be having a Shield class in the player as well that keeps track of whether the shield is active, and how long the shield is active. In this sense: a small optimization is that you could consider to rename Player to SpaceShip or PlayerShip or something similar. As it is not really 'the player' that is flying through your level, it is a spaceship. The player is someone who is playing the game, controlling the spaceship. It may seem nit-picky, but the better you get at finding the most accurate and concise words for your classes and methods, the better a programmer you will be. And how cool is it to have a line that says: spaceship.fire()? [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Now I really like your interest in how to 'do it right'. But bear in mind that there are several different styles of how to do OO programming, and my advice is somewhat strict OO. I don't actually program this way at my work, it is not necessarily always the best way for all problems. However, I think think that it is an excellent way to learn the ropes and get a feel for the responsibilities of classes. Also your nice and compact game structure seems to lend itself very well for this. But don't think you are doing it wrong if you have a few lines that don't seem perfect. It is usually unavoidable. And at this stage it is probably better just to get a few running programs and experiment with using classes than to make the code of this one game perfect. Wow, a lot longer post than I intended. I guess I really like conveying my ideas about how to do OO [img]http://public.gamedev.net//public/style_emoticons/default/rolleyes.gif[/img] Cheers!