Skip to main content

Project proposal - Accepted

I'm working on this games malarkey as my CS Final Project.
I've just had the project proposal accepted, and will be allocated a supervisor next week. I'll have to work up the Full Project plan once I've had a discussion with my supervisor... but for the minute the outline of my project is as below.

What's interesting is that in the two weeks since I wrote it I've done a fair bit of research,  discovered Corona SDK and decided that even if I didn't get my proposal accepted I would crack on with this, as I've rediscovered the fun I used to experience coding back in the 80's.

I've also realised that building/provisioning and just about everything for Android is about 20 times easier than for iOS.


As if to re-enforce that point the nice people from Apple just phoned to say they had to cancel my Developer account, as my Apple login was already linked to my iBooks itunes connect account. So I have to wait for a refund, create a new apple account, (and all the fun that entails with itunes), reapply for the developer account, and rebuild all the provisioning profiles for testing on iOS... I'll post about that next week... at the minute I'm a little ticked off about it all.


"As I write this the app download counter on the iTunes store is approaching 50 Billion.
The Google IO conference today (http://bgr.com/2013/05/15/google-io-1/) announced 900Million active Android devices. Both platforms are powerful and dynamic, but use different technologies and toolsets- iOS is built on Objective C, and Android on a form of Java. This causes additional overhead when maintaining a code base for a common application across both platforms.
The aim of the project is to review and trial frameworks available for cross platform game development for the dominant mobile platforms - iOS and Android. Use one of the frameworks to develop a game for iOS and investigate the methods available for cross platform conversion/compilation.
The game will be an "infinite runner", akin to "canabalt" (http://www.adamatomic.com/canabalt/) or "Jetpack Joyride" (http://halfbrick.com/our-games/jetpack-joyride/) designed to show and test the compatibility of I/O, graphics, physics and sound libraries.
The project will review and report on the options for cross platform game development including:
-C++ and Cocos2D-X cross plaform OpenGL framework - http://www.cocos2d-x.org/ -Javascript and Cocos2D-HTML5 Open GL framework - http://www.cocos2d-html5.org
-Unity, UDK and Torque game engines- http://unity3d.com/ http://www.unrealengine.com/udk/ http://www.garagegames.com/products/torque-3d
- Actionscript scripting language and Adobe Flash through NME http://www.nme.io/about/
-Lua scripting language and Marmalade quick sdk - http://www.madewithmarmalade.com/quick
-Box2D and Chipmunk physics engines - http://box2d.org/ - http://chipmunk-physics.net/
-C and C++ and Allegro cross platform library - http://alleg.sourceforge.net/
-C++ and ClanLib cross platform SDK - http://clanlib.org/wiki/Main_Page
-Java and libGDX cross platform libraries - http://libgdx.badlogicgames.com/
-Python and lib2D - http://www.pygame.org/project-lib2d-2202-.html

The project will select one of the options and build and publish a game, which will include:
• a number of progressively harder/faster'levels'
• a way of informing the player of their current position in the game, the resources, and hazards in the current level and the current state of the player.
• player control to overcome challenges in the current level, using weapons, defenses or "specials"
The program will inform the player when the game terminates and report the total points accumulated by the player. The project will review and report on possible "leaderboard" options such as Apple's Game Centre, Open Feint, twitter and facebook.
The game will be implemented (and documented) in such a way as to allow a programmer to change existing features and add extra ones, or use platform specific APIs with relative ease, making the program easy to maintain and extend.
The game will be designed to work across the major mobile platforms.
The game will be designed using an object-oriented approach.
The process required to transcode or re-compile the finished game (if required) to run on Android will be reviewed and quantified and tested.
Tasks
1.
Review the development requirements for iOS and Android, identify the range of processor/display configurations and identifying a minimum device specification and OS version for cross platform comparision. Ensure access to devices or simulators. Identify routes to market, SDK's and licences required for each platform.
By end of week 2
2.
Review and collate a list of frameworks, engines and libraries that could be used to develop a simple game for iOS and Android. Identify the risks, benefits, restrictions and costs associated with each option. Talk to developers at BuildBrighton Hackspace about alternative approaches to ensure comprehensive coverage.
By end of week 3
3.
Create UML diagrams to assist in the design of the application.
-Create Use case diagrams that indicate the game requirements,
-construct outline interaction diagrams to cover game flow,
work through game description and identify Design Patterns, Classes, and methods in Class Diagrams.
By end of week 3

4.
Build wireframes and create rough artwork and storyboards. Test the designs and gameplay in paper prototype with Game players/developers at Build Brighton hackspace. Review feedback and revise plans accordingly. Investigate the usefulness of ‘Processing’ (http://processing.org/) as a way of rapid prototyping.
By end of week 4
5.
Select a development framework, review the documentation, and tutorials sufficient to build a basic version of the game -Covering IO, graphics, physics, sound. Investigate and acquire any additional tools/libraries/licences required.
By end of week 5
6.
Construct Unit tests for core functions, and build these classes, running tests and documenting the process. Iterate testing as classes are built.
By end of week 7
7.
Develop and test code. Complete finished artwork. Undertake iterative development, with regular end user- testing (My Son has agreed to act as a game tester) Improve the game, add features, refine interfaces, test, and gather feedback.
By end of week 11
8.
Collate documentation, and produce tutorial videos to show gameplay. By end of week 12
9.
Complete Apple developer agreements and submit game to Apple App store for QA. Complete Google Play store developer agreements.
By end of week 13
10.
Review code base and quantify work required to transcode, calculate cost/benefit, compare to previously identified development models/processes. Review alternative approaches. Undertake transcoding or cross compilation, document the experience, and submit the app to the Play Store.
By end of week 15
11.
Gather feedback and draft and submit final report, including evaluation of frameworks, tools and processes.
By end of week 15
"

Popular posts from this blog

live

Beta Beater

The Google Developer Console is really very very good.
It's logically set out, and makes it super easy to run a Beta test.
I'm on the tenth iteration of the final draft, and think I've got to a point where I can actually promote the app to Production.
The latest revision changed the icon set, and removed a load more cruft, slimming the app down to just 12.14Mb. I could strip out the iOS icons and lose a few more bytes but the original aim way back when I started on this project was to build a simple game that could be deployed cross platform, so I think I'll try and maintain just one codebase... as I really should submit this to the iTunes store too, to close the project.



Spine again - animating game assets

Laura Tallarday gave a neat demo of how to build an animation in Spine on the CoronaGeek Hangout, so I had a bash at chopping up an image and animating it.
The plan is to add some more sophisticated animations to the new game "Duck sized horse".. but as was discussed in the show adding a whole bunch of spine animated objects might hammer a mobile device... and as the aim is to have 100 tiny duck sized horses, I'd best choose another approach for them.

anyway here's a swaying viking...