Revisions all done… well it never is done really is it? However i’m happy with how my API is shaping up. The user can has access to functions and variables that tell him things like if the mouse is hovering over the UI element or which mouse click was triggered. Every UI element can be overridden and made into a custom class without losing any of the base functionality and i feel like everything can be constructed very simply.
I’ve begun work on my presentation which is where i’ll prove my research. I’ve made a small application that displays many of my UI features and how they interact. i’ll also be typing in Notepad++ to show some of how the classes work without showing them my base project i used for research. this way i protect some of my code (and the messy parts i’m not proud of) and get across all the information i want to give them anyway.
I’m unsure of what will be enough or not enough. i don’t plan to explain the functionality of everything, just the basics of my design philosophy and how they can use the my API and create custom UI components of their own.
Some parts of the research assignment and whats required to be shown at the end is unclear… so i’m unsure if ‘I’ve covered/made enough stuff … but only time will tell…. wish me luck!
Now i have a decent list of UI elements users can add and change. I now turn my attention to revision of features and changing what the users can access. I also need to think about how i wish to present my research. What i hope to show is how easy it is to use and set up custom content with my API but also what i’ve learned about using 3rd party libraries and what is expected from them.
Everyone in my class is very busy with their own stuff right now, but if i get time i hope to see if someone else can use it to make somthing cool.
Thats all for now
Our game was chosen for AIE’s Year 2 spotlight! Check out the video to learn a bit a about our progress during pre-alpha.
It’s assignment time again at AIE and this week we’re reviewing a game and its core mechanics and discussing how these mechanics effect the design process and how marketable it is.
Tribes: Ascend is a FPS developed by Hi-Res Studios and it shakes up the fps genre by making the competitors extremely mobile which takes familiar game modes (Such as capture the flag) and makes them feel new again.
aside from a unique fast paced combat style, the game has a focus on Account Status and progression through experience earned and levels. Win or loss you earn experience on your account which unlocks new weapons, playable classes and new player skins and colors. Having these unique looks in-game can set you apart, making you feel more important or skilled then the other under-dressed players.
Having this kind of System does not only increases the games playability adding an experience grind, but it also makes you feel like all the hours you’ve put into a game hasn’t just ended in a win/loss score. you have real, digital evidence that you’ve achieved something in the game, such as a cool gun or suit or armor.
having these kind of goals really drives a player.
This system however greatly effects game design. by leaking content to the player over time, you can make the game unbalanced due to difference in weapons and abilities available to each individual player at the time of the match. controlling the content like this requires a balance in itself. you don’t want to make those who’ve spent more time in the game too overpowered, at the same time you wan them to feel that the new weapons they’ve earned where worth the grind. Even with matchmaking systems looking to group players of similar levels together, there will still be a level disparity more often then not.
If done poorly, it can be near impossible for new players not only to win matches, but have any fun at all playing the game. this is ,of course, a huge problem to game design and requires a lot of testing.
Continuing my Research Assignment i continue to wrestle with XNA. It’s actually very easy to work with XNA but like all engines it has its quirks and it takes a little bit of time just finding your feet.
So my task at first was to set up rendering objects in 3D and having a 2D interface drawing on top of it. After playing around with some of the graphical settings and applying some basic lighting to my 3D model I had what i wanted.
step two was to implement the most basic of UI elements. the Button.
Having worked in unity extensively of late, i found that i had been quite spoiled with its ease of use. I set up a simple “pipeline” for my UI system, a UI component class for my individual elements to inherit and a UI manager to make sure everything was drawing and updating. After that was set up it was a simple enough process to set up a button class.
after that is was a matter of making sure i wasn’t tracking mouse clicks to many times per tick and i was done.
Thats all for todays update
After scrapping the space game idea of ours, we turned our attention to a more traditional pc game format…. the indie platformer.
Our core mechanic was being able to control two different characters and use there strengths to overcome the others weakness.
The whole team has fallen in love with this project and we’ve already got some cool puzzles prototyped in.
expect to see more of this game is it develops.
Play or Download it here: https://www.dropbox.com/sh/xblxso7cfbebdz5/3U13ZUXrt2
This week, alongside the 4th and final prototype, i begin my research assignment as well as completing a assessment on GUI.
We were asked to code up a GUI in unity and write 300 words on a user interface used in a published game today and talk about its strengths and weaknesses. I Picked Scrolls, a game in beta, published and developed by Mojang.
Scrolls is a one on one competitive virtual card game and tonnes of fun…
The GUI is great over all… your cards are nice and big in the centre, Turn Time limit and player names are un-intrusive at the top of the screen and the end turn button is displayed with a befitting image of an hour glass. right next to that is your resources for playing cards and the enemies resources are displayed on the opposite side which make sense. next to THAT is how many cards the enemy has in hand, which i find clear. the player to player chat window doesn’t show up unless you press enter to type which is very nice as chat box’s take up a lot of screen real-estate.
The big negative for me is there is no user connection to the rest of the client… which has lobby chat, access to your card lists and your profile… although this information is not directly related to the match in progress, being able to switch out during your enemies turn to check on some stats or chat is a huge benefit. at least the ability to access some base profile stats of yourself or your enemy during the game would be great… Hovering your mouse of the enemy name or avatar could bring up a context info box for example.
Over all this game has a solid GUI that dosn’t intrude on the game space, but its just shy of a few chunks of information that, while not critical to the game, would be very nice to have access while playing.
You can check out Scrolls here: https://scrolls.com/
This week we decided to attempt an idea that we could spread over 2 weeks. all of us in the office are fans of RTS and MOBA style games. we hoped this week to boil down such a strategy experience into a single player 10 – 20 minute experience.
due to the scale of the idea and a programmer getting bronchitis we didn’t get as much achieved as we’d like. We got positive feedback from our peers and it was nice to see alot of the concepts come together. in the end we decided not to continue the project into its second week and pursue a more practical idea.
download or Play it here: https://www.dropbox.com/sh/37z3kobw22c404y/AsrF5wN8he
Kicking straight into week 2 we decided to turn the idea ambition up a notch. With 2 new (and talented) artists on the team we decided to go for a pc title based off another of our ideas on the list of 10.
“Harken” was a third person stealth action game with sandbox elements. playing as a kid lost in a spooky mansion, you had to hide behind obstacles and use gadgets to get the key to the only door out. Our prototype for this week was never intended to display all planned mechanics. Our focus was on hiding from enemies and finding the key. Turned out nowhere near as fun as we’d like.. also not very new… or interesting…
Regardless we met our goals and produced a decent prototype and pitch. Prototypes like this are for the very purpose of testing an idea. not all ideas will be winners.
Play it or Download here: https://www.dropbox.com/sh/sxyts1r5q8rmszn/5noPb3aeOw
For the final few months of my second (and last) year at AIE Artists and programmers group up together and spend 2 and a half days throwing together a game prototype.
for the first week I took up a lead programming/design/team manager roll. and we soon had a focus on a game idea that was achievable and smart(we thought) for todays market.
The game for the first week (working title “ColorFall”) was a downwards scrolling fast paced arcade game for mobile platforms.
The core mechanic was based around “colour switching” which involved changing your character shield color to match the laser obstacles so you could progress.
We didn’t just want to make a game in 2 and a half days, we also wanted the game to have potential to grow into a much larger, more exciting project if we decided to focus on this game idea when “end of year” projects came around.
Play it or Download: https://www.dropbox.com/sh/dkuj9n511o8sy8x/QLZrO9SbUk