liviodlc / igf_project Goto Github PK
View Code? Open in Web Editor NEWAn old, barely-touched repo for a team project that ended up not using GitHub.
An old, barely-touched repo for a team project that ended up not using GitHub.
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.
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.