Jump to content

  • Log In with Google      Sign In   
  • Create Account


Verik

Member Since 01 Sep 2012
Offline Last Active Oct 02 2013 02:55 AM
-----

#5011345 Very early alpha of a retro 2D game -- keen for community critique

Posted by Verik on 16 December 2012 - 02:33 PM

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.


#5011217 Very early alpha of a retro 2D game -- keen for community critique

Posted by Verik on 16 December 2012 - 04:11 AM

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!


#4994849 Memories in Games (long)

Posted by Verik on 28 October 2012 - 04:30 PM

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.


#4982869 Generic classes of generic classes?

Posted by Verik on 23 September 2012 - 04:33 AM

Let's start with the most profound -and hard to follow- advice for software developers: KISS. 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.


#4981392 New to this need some help

Posted by Verik on 18 September 2012 - 02:28 PM

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()? Posted Image

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 Posted Image

Cheers!


#4981026 New to this need some help

Posted by Verik on 17 September 2012 - 03:12 PM

Good to hear you are learning things, that's what it is all about!

Ideally I'd create a separate (new) class that handles input, possibly the same class that also controls the frame rate and signals the camera to paint the scene (if I got it right), so a sort of main game controller or game loop class.

Now if you detect that a mouse button is pressed, you can call the appropriate method in the player object to tell it that the (user) wants to fire a bullet or activate the shield. The player object itself can then decide if it is overheated or not. (So the game state actually becomes a player state, which seems more in line with what it is.)

The same goes for movement. Have the game loop call the player object to tell it that the user wants to move it up or down. Let the player object decide how fast this move will take place (if at all). Does this make sense to you?


#4975585 java libraries

Posted by Verik on 01 September 2012 - 05:19 PM

Hi burnt_casadilla,

I started on java development of a 2D game late last year and did a quick look around for suitable libraries. I found JGame (http://www.13thmonke...g/~boris/jgame/) to be an excellent starting point.

The big advantage of JGame is that it is specifically targeted at starting game developers. There is a tutorial that slowly introduces the basic concepts and you get various demo games that display a wide array of games that you can make with it. There is no platform game amongst them, but since JGame supports sprites, background tiles and scrolling, it must be possible to create such a game with JGame.

The good.

- Framework that takes a lot of hassle away (you start coding your game quickly)
- Support for various Java environments (desktop, applet, Android) even a variant for Flash if you want to switch to that.
- Nice tutorial and demo games
- Performance optimized

The bad.

- It is a limited (limiting?) rigid framework. You will probably encounter its limits sooner rather than later. This is exactly the price you pay for getting started so quickly.
- Some aspects of the framework are a bit vague due to unnecessarily short variable names or unclear method names.
- The library is open source, but does not lend to being modified for the purpose of your game. In short: it's messy. (I really fell in love with the functionality, but now that I'm extending the core, I'm first rewriting the core in a way that I can understand.)

My advice.

If you know how all about collisions between sprites and background, have some idea about how to handle threading, know how to load and manage your images and animations, you don't need JGame. If not, JGame is an excellent place to learn some of the basics.

Good luck!


PARTNERS