liviodlc / igf_project Goto Github PK

Here's a legitimate issue for once: Which UML Editor should we use?

I know we've probably been planning to use Violet, but I'm personally getting sick of Violet, and a few months ago I installed a built-in UML editor for Eclipse. I created two sample folders in the master branch about each editor, each with a README file that explains them:

https://github.com/acceleron3000/igf_project/tree/master/uml-eclipse
https://github.com/acceleron3000/igf_project/tree/master/uml-violet

I personally would like to use the eclipse plugin, but I can see that it's a little risky to start using a brand new program that we may not all be used to. It looks intimidating at first, but when I tried to make a sample class diagram with it, I was surprised to see how much more intuitive it is than it looks.

testing the issue system

This is a header

This is an image:

EDIT: this is an edit.

We need to start looking into the sound programming risks, specifically how to stream sound into the game (which depends on the engines and tools that we decide to use), how that affects performance, and what effects will be available to us.

When you run the runnable .jar's that I exported to the Dropbox, for one of them, the images load into the game well and you can see the player and some walls. But for the most recent .jar, the file paths suddenly don't work anymore and the images never load.

You can compare the code behind the two jars in the following branches:

protophase2 => \Program\Prototyping Phase 2\0 - From GameMaker to Java\game.jar
protophase2_livio => \Program\Prototyping Phase 2\1 - First Walking Animation\game.jar

I want to use this thread to discuss the design of the controls and to experiment with different styles of movement. If we knew more about our playable character(s), perhaps that would influence the design, but right now I want to focus on making the player feel like they're on the dark planet.

We want the player to feel like they're in a really dense atmosphere and wearing a space suit that may not be very flexible. This means that fast movements are not the way to go, but we also have to be careful not to make the controls boring and frustrating.

I imagine there's a lot of room for the animation to help deliver this experience, especially if the character appears to be slow not by choice but by the environment. We'll also have to consider how the player's dimensions play a role in this, especially since it can be a little awkward to play a character that is much taller than she is wide. The backgrounds will also play a big role in delivering the experience of being on the planet, and we could also try using some particle effects to make the air seem visibly thick.

I'm going to experiment with my idea for player movement in the protophase2_livio branch. I imagine that we're going to keep the gamemaker-to-java build in the protophase2 branch.

Now that we have all technical risks sorted out, and with Teresa's code in the respository, it's time to finally get to work!

Right now the biggest question on my mind is: how can we make the gameplay work well? I've been thinking about this question and how exactly to go about answering it efficiently and effectively, and this is the plan that I came up with.

First, we need to make a lot of iterations, where we truly experiment with the mechanics rather than trying to think of something that works on the first try. I think this is more of a production problem with how our current workflow is set up. Basically, writing up a formal spec for a small idea and declaring that "this is the idea that we're going to code now," just doesn't feel right from a design perspective. It seems to encourage us on the design side to take each idea more seriously and spend more time speculating on it rather than actually testing it.

So if the next few iterations are going to be centered around experimentation, then the designers will have to be doing most of the programming. Basically, if a designer gets an idea that they want to explore, they should program it themselves and see how it came out. I think this is the best way to maintain the designer's sense of curiosity, which is imperative to maintaining proper design perspective. Plus, it's just better if everyone works alone, because at this scope, group programming will only slow us down. Fortunately, we'll be able to make multiple iterations at the same time.

To solve the problem on how to make a good gameplay system, we'd essentially be making mini-levels, or small puzzles and problems that showcase the potential of the mechanics. This means there's tons of room (and need) for experimentation, which is why it's okay to have multiple people prototyping on the same core idea.

So how will this actually work? I imagine something like this:

1. We declare a "core" idea or problem with which to center this "prototyping phase" around.
   • In this case, I can imagine us using the senses+platforming idea as a starting point for the problem on how to better pin down what the gameplay will be like.
2. We create a dummy branch in the repository that will act like "the core branch" of the current phase.
   • Each programmer will then create their own branch off of the core branch, and this is where they start experimenting.
3. Every time you want to test a new idea that's different enough from a current prototype, you should create a new branch for that idea.
   • For instance, one branch might explore the potential of one item, while another branch might explore that item under radically different settings. The fact that you dedicated a branch to something doesn't necessarily mean that it's good, but that that particular experiment yielded some insight that was worth remembering. Sometimes it's really useful to be able to see why a bad idea failed.
   • The end result is that we generate a "tree" of ideas or prototypes, which literally traces the branching paths of our experimentation.
4. Each prototypes should be made as quickly as possible, meaning they shouldn't take longer than a day or two to make. It'd also be more productive if at the end of each day we look at the other prototype(s) that have been made and discuss their design potential.

So that's my idea for the next prototyping phase. I'm not sure where Teresa fits into this process, except for the fact that we might start out by using her coding base. I'm also not sure when the phase should end (perhaps on a deadline?) or whether we'll just start a new "phase" whenever we find a good reason.

On the current build uploaded to the protophase2 branch, when you slide down a wall of tiles, you can get stuck between some of the tiles and effectively stand in mid-air.

I consider this to be a fairly low priority bug since this is just a prototype. Only when the bug starts be happen more often and starts to interfere with what we're trying to test may it be worth fixing.

This is caused by how the collision detection system does not prioritize the order with which to test collisions. Collision detection is triggered by the Room's updateState() method, which calls on GameObject's collisionTest() method.

We're probably not going to be relying on Swing for the final game, and many of the technical risks that we face will be dependent on the types of engines and tools that we end up relying on. Teresa we need you to start coming up with a plan for how we'll build the final version of the game.

While debugging some of the code, I found 2 more issues that should be fixed by some point. First, the WASD control scheme leads the player character to accelerate unnaturally out of the screen. The arrow keys control schemes do now have the same issue. This should be easy to fix.

The second problem is that though blending code works for wall sprites, it doesn't work for the player character sprite. The change in player character sprite is sudden, not gradual. This is probably due to missing code, and shouldn't be hard to fix as well.