It's been a while since I talked about our progress with J3WAO. The biggest update is that we changed the scope of the project. Originally, we were planning on making an RPG with a music-driven battle engine. Instead, we are making more of an action game with the same battle engine. Instead of advancing the story through RPG elements like map exploration, the story will be advanced more like a fighting game. Specifically, the story will be developed through cut scenes or dialog that is between planned battles.
The reason we decided on this change was to because of time constraints. Our team is more busy than we originally thought, so we don't have time to implement everything that we wanted. We changed the project so that we could release a complete, polished, and content-filled game for the end of the course.
However, we are still planning to create an RPG version of the game. We will have two complete games to release to market when we are done. That should be very cool. :)
As for progress, our team is mostly done the battle engine. After we get a few more features ironed out, we can move onto our game engine that will transition between stories and battles. Once that's done, we will focus on content generation, testing, and deployment. It should be an exciting few weeks. There's only 4 more weeks until the course is done, so we're working hard to get this thing out. :)
Showing posts with label J3WAO. Show all posts
Showing posts with label J3WAO. Show all posts
Thursday, March 10, 2011
Thursday, March 3, 2011
Swarming!
Our project manager at Karos Health shared a link with us the other day about Swarming.
This is the first time I've heard of this technique and it sounds quite interesting. The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.
I also think having many developers focused on a single story encourages collaboration and teamwork. It forces everyone to work together very closely, and this probably leads to getting the story done faster.
Of course, the story in question needs to be big enough to allow multiple developers to work on it together without stepping on each other's toes. If our J3WAO stories weren't so small, I think it would be interesting to try it there.
This is the first time I've heard of this technique and it sounds quite interesting. The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.
I also think having many developers focused on a single story encourages collaboration and teamwork. It forces everyone to work together very closely, and this probably leads to getting the story done faster.
Of course, the story in question needs to be big enough to allow multiple developers to work on it together without stepping on each other's toes. If our J3WAO stories weren't so small, I think it would be interesting to try it there.
Sunday, February 20, 2011
Android vs iPhone development
I stumbled upon this article talking about the pros and cons of developing for the Android and iPhone platforms. It's an interesting read, especially if you've had some experience developing mobile apps. I agree with most of the points made in the article.
In the 2 months I've been working on j3wao, I've already encounter a bunch of the Android issues the article talks about. Probably the biggest complication we've hit so far is the huge disparity of device screen resolutions. Targeting all Android phones is a nightmare for this reason alone. Another major issue is the emulator. It takes something like 2-3 minutes to start up and load the home screen. Every operation on the phone is incredibly laggy, even basic things like doing the unlock slide. We might have a lot of issues testing our game on the emulator because of this issue.
Unfortunately, we are (realistically) stuck with Android-based development and testing for j3wao. While we plan to deploy to iOS devices, Android will probably be the primary target for development and testing. There's more financial commitment to developing for iPhone. At the very least, we need a $99 licence fee. There's also the fact that we need Macs to develop and test on. This is a major inconvenience when we have 4 developers for this project. You get what you pay for, I guess.
In the 2 months I've been working on j3wao, I've already encounter a bunch of the Android issues the article talks about. Probably the biggest complication we've hit so far is the huge disparity of device screen resolutions. Targeting all Android phones is a nightmare for this reason alone. Another major issue is the emulator. It takes something like 2-3 minutes to start up and load the home screen. Every operation on the phone is incredibly laggy, even basic things like doing the unlock slide. We might have a lot of issues testing our game on the emulator because of this issue.
Unfortunately, we are (realistically) stuck with Android-based development and testing for j3wao. While we plan to deploy to iOS devices, Android will probably be the primary target for development and testing. There's more financial commitment to developing for iPhone. At the very least, we need a $99 licence fee. There's also the fact that we need Macs to develop and test on. This is a major inconvenience when we have 4 developers for this project. You get what you pay for, I guess.
Thursday, February 3, 2011
J3WAO Game
So I realize that I haven't talked about the actual game we want to create for J3WAO.
Our game is a music driven RPG. The player's attack are linked to music and interactive cues on the screen. The player needs to tap (or swipe!) the screen at the right time and place, based on the music. The attack mechanics are very much osu! inspired. We are also working on a storyline and a Final Fantasy Tactics style map.
We are planning to release to both iPhone and Android. We also have plans to release a desktop (web-based) version. We are using Adobe AIR to give us the flexibility to deploy to all these platforms with minimal effort. We get to use Adobe Flash and Actionscript 3 for development. These tools have great support for game design, so using this platform will probably save us a lot of development time.
Our first milestone release (of the three scheduled for the course) is next Thursday. Our goal is to have a simple proof of concept demo out by then. I'll try to post some screenshots of the game when it gets more presentable. :P
Our game is a music driven RPG. The player's attack are linked to music and interactive cues on the screen. The player needs to tap (or swipe!) the screen at the right time and place, based on the music. The attack mechanics are very much osu! inspired. We are also working on a storyline and a Final Fantasy Tactics style map.
We are planning to release to both iPhone and Android. We also have plans to release a desktop (web-based) version. We are using Adobe AIR to give us the flexibility to deploy to all these platforms with minimal effort. We get to use Adobe Flash and Actionscript 3 for development. These tools have great support for game design, so using this platform will probably save us a lot of development time.
Our first milestone release (of the three scheduled for the course) is next Thursday. Our goal is to have a simple proof of concept demo out by then. I'll try to post some screenshots of the game when it gets more presentable. :P
Wednesday, February 2, 2011
Pet Peeve #582: Bad Documentation
At work, I've been using GWT, and for the most part I've really enjoyed it. Occasionally though, I get frustrated by some things. For example AutoBean, a JSON-to-Java object parser for GWT, has almost no documentation. The Google Code wiki page is literal one of the only pieces of documentation out there, and it's quite bare. :/
Today I had to parse JSON lists using AutoBean. Here is the only relevant statement I was able to find:
No information on how to go the other. Not cool. I had to do a lot of experimenting to find out that AutoBean only accepts something like this right now:
Hopefully this will be improved for the next release.
Also, there were very few code examples online. Open source software can be really cool in that they provide a lot of really useful tools, but their lack of support is quite frustrating. This is not to say that all open source software has horrible documentation, but in my experience, it is usually worse than the Proprietary equivalents. Just take a look at MSDN vs Oracle's Java documentation. Thankfully, a co-worker helped me find a workaround that he had used in a different project.
Anyway, time to learn everything to there is to learn about Flash/AIR/ActionScript 3. Our J3WAO sprint ends tomorrow, and we still have a lot (all) of our development left to do. :P
Today I had to parse JSON lists using AutoBean. Here is the only relevant statement I was able to find:
List and Set properties are encoded as JSON lists. For example, a List<Person> would be encoded as:
[ { "name" : "John Doe" } , { "name" : "Jim Smith" }]
No information on how to go the other. Not cool. I had to do a lot of experimenting to find out that AutoBean only accepts something like this right now:
{ people=[ { "name" : "John Doe" } , { "name" : "Jim Smith" }]}Hopefully this will be improved for the next release.
Also, there were very few code examples online. Open source software can be really cool in that they provide a lot of really useful tools, but their lack of support is quite frustrating. This is not to say that all open source software has horrible documentation, but in my experience, it is usually worse than the Proprietary equivalents. Just take a look at MSDN vs Oracle's Java documentation. Thankfully, a co-worker helped me find a workaround that he had used in a different project.
Anyway, time to learn everything to there is to learn about Flash/AIR/ActionScript 3. Our J3WAO sprint ends tomorrow, and we still have a lot (all) of our development left to do. :P
Labels:
GWT,
J3WAO,
Open Source Software,
Web Development
Thursday, January 27, 2011
Introduction to Actionscript 3
I am doing a crash course in Actionscript 3 for J3WAO. It's fun. It's going to be a challenge to learn the language this fast. We will also need to know a good amount of the language features to implement our somewhat ambitious game.
First impression with the language are not very good. Where are my abstract classes? Dammit.
First impression with the language are not very good. Where are my abstract classes? Dammit.
Tuesday, January 18, 2011
Introducing J3WAO
The Arts 304 project is coming along very nicely. We have a few really great ideas out there, and we should be deciding on one on Thursday. I am really impressed with the ideas we came up with so far. I also really like how our team is interacting. Everyone has an important contribution to the project, and everyone seems to be interacting really well. Things like duets in the Comfy! :P Our group even has an unofficial name: J3WAO (initials of the members). I am really excited to see how this project unfolds! :)
There are a lot of interesting challenges from a technical point of view. Specifically, one of our main goals is to deploy to multiple platforms. Jesse and I and currently doing research on possible platforms and tools that would make this easier. Part of the problem is that neither of us have ever developed for mobile devices before. We also need to look at available game frameworks. Since we are on a very tight timeline, we don't have time to reinvent too many things. Lots of stuff to learn! Wooo! :)
There are a lot of interesting challenges from a technical point of view. Specifically, one of our main goals is to deploy to multiple platforms. Jesse and I and currently doing research on possible platforms and tools that would make this easier. Part of the problem is that neither of us have ever developed for mobile devices before. We also need to look at available game frameworks. Since we are on a very tight timeline, we don't have time to reinvent too many things. Lots of stuff to learn! Wooo! :)
Subscribe to:
Posts (Atom)