Monthly Archives: March 2014

2014 Class Work, Cornstar

Cornstar Week 1 – 6: Proposal

Leave a comment

WAMP and vhosts

To be able to get the server running on my local machine at home, I’ve downloaded and installed WAMP. This was fairly simple with the default settings and it works fine. It just cannot be run after Skype as they use the same port. The way around this is to simply start WAMP first, and then run Skype.

The vhost can be configured by opening up the httpd-vhosts.conf file in the Apache’s conf/extra directory. In here you can add virtual hosts to simulate a real web server domain for each project you work on. The file in mine looks like the following:

# Assignment 1 - Cornstar
<VirtualHost *:80>
    ServerAdmin jamesheazlewood@gmail.com
    DocumentRoot "e:/wamp/www/assignment1/root"
    ServerName cornstar.localhost
    ErrorLog "e:/wamp/www/cornstar/logs/cornstar-error.log"
    CustomLog "e:/wamp/www/cornstar/logs/cornstar-access.log" common
</VirtualHost>

Notice that the DocumentRoot points to the root directory. This is a security measure as all the sensitive scripts and settings will be stored in a directory behind this one. So if someone happens to find a way to access the root directory, they will find it more difficult to get to the sensitive areas.

Setting the website up this way allows me to access and edit the website on a root URL  “cornstar.localhost” by typing that into my browser.

Folder structure

The way I intend on setting up the server will be great for security, organisation, and the MVC software pattern. This structure may be added to as I develop the site, but this is a great start.

  • www – wamp root dir
    • assignment1 – this is a sub dir where the vhosts refers to. This allows me to have multiple websites without moving files around.
      • docs – This is where resources and assignment documents will go
      • logs – this is where Apache and the website store log files
      • root – root of the domain. Typing / after the website domain will be this directory.
        • Index.php – the website runs from this file
        • css – CSS files go in here
        • js – Javascript files go in here
        • img – Images go in here
      • view – all view related files will be stored here
        • template – template files (header and footer) will be stored here. They will contain the main mark-up of the web page to avoid repetition in every page
        • pages – this is where each section of the web page is stored
      • model – all database models go in here
      • controller – all controller scripts go in here
      • conf – all configuration files like database login info and website settings goes in here

Database design

One of the very early things I like to do is create the database and play with that as it is essentially the hard drive of the game. All data about the game, users and corn information will be stored here.

The tables for the database are:

users

Name Type Notes
id int ID of the user
username Varchar 32
password Varchar 64 Encrypted as sha1 before saving
email Varchar 128 Email (checked as proper email before save)
name Varchar 128 Real name, first and last (not required)
<>country Varchar 128 Just country text
money int How much money in the bank. Will always be whole numbers.
width int Farm width
Height int Height
created datetime Date and time user was created
last_login datetime Record of the last time this user logged in

plants

Name Type Notes
id int
seed_id int Links to the seed types
user_id Int Links to which user plated this seed
planted datetime Date and time the seed was planted
harvested datetime Date and time this plant was harvested. *

* Also used to determine if this has been harvested or not. If not, this will be set to “0000-00-00 00:00:00”.

seeds

Name Type Notes
Id Int ID of this seed, used to link from other tables
name Varchar 64 Name of the seed, exmaple “Juicy Corn”
cost int Cost for planting this seed
time int Time in minutes that this takes to grow. 40 hours would be 144,000.
sell int Price this item sells for.

Database notes

The reason I’ve chosen to represent the time left on a plant growing with a date planted is because this is safer to use against hackers trying to dynamically make a plant fully grown. If they do this and send to the system that they are harvesting this plant, the system can check when the plant was actually planted, and if the time has been enough, then it can be harvested, and if not, then we decline the request.

Another table for this database could be a “Country” table. This will allow people to select their country in a drop-down and would store the country as either an ID or a country code (example: AU). However, this is not an important feature of the website, and the country field will not be required, so I’ve left it a as simple text field.

I could have also made the first and last name separate fields in the user’s table, except this sort of this is not important for such a game. If this was a database for a mailing list and you wanted to arrange the users by last name, then that’d be useful. But otherwise there is no point.

Artwork

When making games, I usually start off with assets after planning as usually someone else will do these and I can then focus fully on the programming-side of the game.
Because HTML can include buttons and other tools like select box drop-downs, I will basically only need the game board. The only artwork I’ll need for this would be 3 different animations of corn growing and dirt.

corn0001

DELICIOUS.

2014 Class Work, Cornstar

Cornstar – A corn growing game

Leave a comment

 

 

 

 

 

Update:

The game is finished. Play Cornstar. 

title

Hello. I’m Jimmy, a famous corn star. I grow corn and sell it to make money so I can buy more seeds to grow corn. My life is like watching grass grow. Except it’s corn.

 Proposition

For this task, I plan on creating a very simple HTML game that allows users to plant seeds and grow corn. There will be 3 types: baby corn, juicy corn, and golden corn. The baby corn is cheap to buy and cheap to sell, but takes a lot less time to grow (3 hours). The golden corn is slightly more expensive, sells for a lot more but takes 40 hours to grow. More patient users will use this option. The juicy corn sits in the middle of these. In addition to this, once the user can afford it, they can expand their farm.

The idea is that people farm the corn to earn money, and are rewarded for patience, better corn takes longer. Expanding their farm gives them more space to grow more corn, and the cycle continues. Users can then look at their friend’s farms and compare them and their current riches.

The database will need to store user data, crop data, and a link table between the crops, which user, and where the crop is planted. The user data will also contain the user’s currency and stats including the number of each type of corn sold.

For advanced features I’ll be setting up a vhost on my local machine. This is an Apache “virtual host” that lets me have multiple root domains on my local machine without having to change settings or move folders. In addition to this, I will put the game up on a real server with a database to show it off to friends.

Another feature, if I get more time, is to add more varieties of corn. For example red corn, popcorn corn and blue corn. These could be unlocked over time. Another feature could be a bad guy crow that eats your corn unless you get a scarecrow. The scarecrows could be upgraded to be scarier for larger farms.

The game will use javascript for the clicking of corn, but the page will need to be refreshed to see progress of corn growth. However, because the corn will be stored as “time planted”, this can be utilized to show at real-time how long until a corn is fully grown.
Although it would be an interesting feature to have plants die if they are unattended, I want the game to allow users to come back at any time in the future and have their fully grown plants ready to harvest as having them die would annoy some users.

Detailed Plan

Login

Behind the scenes, the first part of the system will be the login screen. Without being logged in, the user will be able to view their farm but won’t be able to plant anything. The user must use a login button at the top of his or her screen to login and make edits.
The actual login screen will be a home-page type of screen displaying a logo and fields to enter their username and password. Once this is done, it will redirect to the user’s farm page.

Farm view

In the farm view, when logged in, there will be displayed the current user logged in, the money they have, and a drop-down (select box) for which seed they would like planted, defaulted to normal corn.

Below this is the game board which will look like a typical chess board, but each corn image will be drawn from top to bottom and can grow higher than the square by 3 times.

20140327035728

 

By default, and no upgrades, the user will have a 6 X 2 large farm and must grow corn in this area to afford to upgrade to a larger one, 8 x 3. The next upgrade will be 10 x 4, then 12 x 6, then every upgrade after that adds 4 to the Y axis, for example 12 x 10, 12 x 14 etc. This is because web pages typically are scrolled down rather than across.

When editing, the user selects the square at the base of the corn. Clicking an empty space of ground will plant the selected seed. Clicking on fully grown corn will harvest it and give the player money. If the user doesn’t have enough money for a seed, they cannot plant any corn. The user will be able to see their friend’s farms, but need to be logged in to make edits of their own.

When viewing a user’s farm while not logged in, there will be a big bright button telling users to create their own corn farm.

2014 Class Work, Plasmation

Particle Tool – Week 7

Leave a comment

This week I focus on research and creating a schedule for the creation of the tool. I figure that without research, I might not be able to accurately produce a workable schedule. We’ll start with the documentation creation process and how long this should take:

  • Start date: 12th February 2014
  • Due date: 28th May 2014

This in total is 15 weeks to do documentation, with a presentation on the due date.

Week 1 to 5 Discuss and research initial ideas
Week 6 Finalise Preliminary Idea
Week 7 to 12 Research project and document drafting
Week 13 to 14 Final Drafts
Week 15 Final Documentation and Publishing
Week 16 Submission

Since I already have the initial idea, I’m going to start on the actual project and document drafting. Below is a plan of what I’ll need complete by the end of the planning stage:

  • (W-7) 26th March – Create a plan. Then Research some more effects and specifics about realistic particle simulation.
  • (W-8) 2nd April – Make a start on the documentation, making the templates for each document and make lists of the parts I’ll be doing.
  • (W-9) 9th April – More research on things
  • (W-10) 16th April – More research on things
  • (W-11) 23rd April – Will be travelling at this time, but can do little things when needed.
  • (W-12) 30th April – End of document Drafting – most of the documents should be complete by now.
  • (W-13) 7th May – Final drafts to start.
  • (W-14) 14th May – Back from Travelling – Knuckle down in final drafts. Start presentation.
  • (W-15) 21st May – Final documentation and publishing. Finish presentation, Do mock recording etc.
  • (W-16) 28th May – Due date! Everything should be done and handed in on this day. Everything should be done before this but leaving a week for any catch up.

On each of these days I’ll be writing a blog entry like this one. On the date of final documentation and publishing, I’ll copy all the blog entries into a document for handing in. As it is easy to track things online.

  • Research Journal
  • Learning Plan
  • Peer Reviews
  • Design Documentation
  • Technical Design Documentation
  • System Analysis Plan
  • Project Management Documentation
  • Financial Outline

These will need to be submitted both by PDF and a binded document. I’ll need to make sure I have enough printer ink and buy the binder.

Research Journal

For this task, I will need to use WordPress to log each week of what I’ve been researching and which peer reviews, information I can find about the system. At the end of the week I will need to copy them to a word document and spell check them. This will be printed and binded. I will be watching a lot of videos on real special effects like plane crashes and gun shooting to see how fire and smoke acts in real life, and then study images of fire to reproduce it.

Learning Plans

Some ideas of learning objectives could be:

  • Work out whether saving files to the server or directly to the user’s hard drive is better. Should I use a conbination of both?
  • Learn how to optomise particle systems on the video card using researches methods
  • Marching cubes / metaballs for water effects – maybe use normal maps and specular maps to add better lighting
  • Volumetric for ckloud effectrs
  • screen space ambient occlusion for smoke
  • particle light emissions into smoke
  • volumetric lighting inside smoke cklouds caused by particles
  • Real life particle movement with wind and the best way to do this
  • Creating normal maps
  • Learn what industry people want
  • Undo and Redo feature using “Memento pattern”.

I might need to elaborate on these more and explore / find new ideas as the documentation develops. Each of these will need to be saved as separate PDFs, and printed along with other material to be binded.

Peer Reviews

I would like to post on as many forums as I can and also ask at least 3 industry special effects designers what they like and dislike about Fume FX and as many opinions as I can get. These can be people on YouTube that post special effects demos and forums. Some things I could ask are:

  • What are the best features of Fume FX? What are the things that you cannot live without?
  • Do you find the interface overwhelming?
  • Are all options used or are there settings that are mostly used and some that should be default anyway?
  • Would you pay for software like this particle tool idea?
  • Do you think having it run in a browser would be beneficial? Why / why not?
  • What are the hardest special effects to create?
  • What features do you wish were there / were easier?
  • Would a GUI speed boost make workflow a lot easier?
  • What sort of interface would work better? Is one like Photoshop a good choice? Would an interface that goes away from the trends of Photoshop be a burden?

The general idea is to prove my niche really. I need to know these things so I can design the interface around these. These will all be recorded and preseted as part of the peer review documentation. I will the end it with a conclusion.

Design Documentation

This will be where the tool is explained in as much detail as possible. Some general things would be things like:

  • Tool will run in primarily Google Chrome (and Firefox)
  • Complete functionality. It will:
    • Be able to save and load on the server
    • Be able to save and load files locally
    • be able to create, delete and edit “layers” (smoke on one and fire on another for example)
    • Export a spritesheet that can be used in the Unity’s particle cool (must do more research about compatability with normal maps and different effects, alpha sorting issues and using multiply and additive together)
    • Can export different channels, like a normal map, additive and multiply
    • use the GPU to simulate the system
    • can create frames
    • Frames can be scrubbed through
    • A frame can be chosen with a small box where the section will be exported per frame
    • The “camera” can be moved around to center the frame
    • The “frame” will be a square but a “fade out” can be applied in a spherical matter inside the frame, as this is a pre-particle exporter, the effects need to be technically sections of a larger particle system.
  • Tools in the toolbar will be
    • Brush to draw particles to the 3d world
    • A pushing tool to drag particles around like the liquify tool in Photoshop
    • A gravity tool for pulling particles towards the cursor
  • Interface will be designed around simply the default styles that three.js comes with.
  • Different interface view modes:
    • Game engine preview – will show the rendered version with all effects added using a 3 point light system that can be customised. This will not be rendered, as lighjting in games can change. For example a water particle cannot have a bright light reflection rendered at the top-left because the game’s light might be under it.
    • Real-time preview (slower to render but will try and make it at most 1 frame per second, each frame can be cached into a buffer on the canvas and displayed until he user moves the camera) This will be the main area that the game will use
    • Normal mode will show 10% of the particles
    • Motion vector preview – a normal map looking (x y z velocity represented as red green blue channels) as to visualize movement in a single frame.
    • Depth buffer view (shows the depth texture, mainly for me debugging but may be useful for others
  • Particles could light up when hovering over them
  • The background can be customized to show the transparency in the screen
  • Screen effects can be applied, like depth of field, screen space ambient occlusion on “smoke” particles (using the depth buffer), glow and
  • Particles can be simulated using either vertices connecting a vertex colouring additive effect on each particle so make more realistic fire (will go into detail later, and after more research), smoke as volumetric, particle lighting and ambient occlusion (more research needed)
  • Can add a game light to simulate how it would look in a game
  • Server will need a database to store user data
  • To be usable, the system needs to have an undo / redo feature. This should be done using the “Memento pattern” and should be implemented from the start.
  • A status bar showing the particle count, some extra info and a status of the program (like loading or saving or exporting etc.)
  • Toolbars, one on the left, the right, the bottom and top. I will try and make them simple without many options as one of the aims of this project is to have a program that’s less daunting and easy to learn.

The name of the program I’m leaning towards something like “Plasmation”. Because the word isn’t really a word, apart from being seen in some online places, which say it’s “forming or moulding” when this tool is like moulding a special effect particle. It also has “plasma” in it, which, to me, sounds special-effect-y.

Technical Design Documentation

This will consist of a lot of UML diagrams basically. Once I’ve sorted out the design documentation, done enough research on the formulas and ways to produce the effects, I’ll be able to do this properly. I think this section will be important to show how the web server and client-side parts will work together, as the barrier here is that because the program is working on a web server, the data needs to be transferred up and down to that and loaded in by users from their hard drives. A list of these would be:

  • Component listing
  • Pseudo code for all systems and components
  • Program design diagrams in UML
  • Data flow diagrams in UML

The thing to start off with will be the way the server and client could interact, but as I haven’t done the design documentation, this is just an example (Made with Lucidchart, a great example of an online tool): Web Server Workflow - New PageAs you can see, this is a basic flow of data in the logging in / creating account / workspace.

System Analysis Plan

In this I will basically talk about why I’ll be using an agile type of development methodology. I will most likely use Scrum because it is what I’m used to. An issue with this is the morning meetings, which I can replace with the journals and discussion of my goals and blocks.

Requirement analysis will also need to be documented which is basically a document that describes the requirements of the program. This will be closely tied to the technical documentation. I will need to include this as a separate documentation with an introduction explaining briefly the purpose of the application, scope, objectives and success criteria of the project, and the usual glossary of terms.

The second part of the documentation will include requirement and the analysis model of the application. The documentation will finish with references.

This section will also include a test plan and test cases for requirements validation.

Project Management Documentation

This will consist of a Work Breakdown Structure (WBS), complete with resource allocations, and a gantt chart with critical path. I will be using gantt chart software for this and will discuss in my journals which software is best for this.

This part of the documentation will also include a risk assessment and contingency plan.

Financial Outline

The application could either be free or a subscription-based program with advanced features unavailable. For this project, however, the program will be very basic, and adding user and subscriptions in there just makes another layer of difficulty. For the actual outline, I will be creating a mock one for industry professionals in a form of a pitch to get funding. The actual money involved will cover things like web servers, domain names, time food and workspace programs for myself to create at home, software, internet and power costs.

Uncategorized

Getting up to scratch and a new uni project

Leave a comment

Hey everyone. I have not posted in ages mainly because I keep forgetting to. So I’ll be doing at least one a week for a new project I’m working on plus any number of others that I have in the works. The things that I’ve been working on briefly are:

Game Faming

20140326142906 Game Faming is a gamer social network website that allows users to post videos and blogs, vote on them by attacking or defending them, which allows the good videos to be kept and the bad ones be deleted. The site is like a Facebook type website but for gamers only, or game related content. The core of the site will be that users level up the same way as you do in an RPG type game and can access extra content and even enter competitions to win prizes based on their level. The website is being developed by myself and a team of others.

Filtrate updates

20140326143333 Filtrate is a 2D platformer game made with a friend in my first year at AIE. The updates include:

  • Extra HUD with dimension indicator and death counter (it’s great coming into a room where someone’s been playing a level for ages and seeing the death counter.)
  • More player animations and smoother walk cycle. Animated idle stance.
  • Added more music depending on the level
  • Added more level variations that match the music
  • Added backgrounds
  • Tweaked graphics. Particularly the spikes image as people thought it looked like grass and would skip and hop through a meadow of death.

I had also done a few code tweaks and added a mode where the orbs would kill you instead. This made the game really hard and had to tweak the levels slightly.

Little Annoying Rocket game

20140326143358 This game is a type of phone / tablet game where you control the rocket by tapping and holding, and then dragging the touch to rotate. As you’re touching, the rocket jets fire and you move forwards. It is a difficult game because the camera moves with the rocket and only moves the direction it is facing, so it’s hard to control, but that’s where the challenge is. The goal of the game is to get as much score as possible by going as high as possible, going

FPS Punching game

20140326161308This is currently in very early construction but basically, the idea is that it’s an arena type game like Quake III Arena except you only get the ability to punch people and kill them in 1 hit. The idea came about at a LAN one day when we decided to create our own game-mode in Crysis Wars where we would not use weapons. The game gave you the ability to go invisible, be super fast,. jump really high, or have armour. Using these abilities drained energy and you’d need to turn them off to recharge it. The game mode ended up being really fun because of 3 main aspects: sound effects – satisfying hearing the bash and crunch when you hit someone. Rag-doll: seeing your friend’s bodies fly across the arena after you punch them and then flop to the ground was funny. One hit punches: With the strength mode, punching someone was an instant kill, and this was extremely satisfying. This video shows this in action. 20140326164046   The way this worked well was also because it was a first person shooter game with guns, but if you take away the guns and make your arms super powerful, it’s a whole new game, and just as fun. This game will be fast paced and include power-ups that allow the player to move faster or jump higher, go invisible, and occasionally a ball they can throw once to kill someone. We will be developing it in Unity3D because it’s easy to use and I’m familiar with it. I also have a student licence for the pro version.

Helping a friend with some art

20140326182139 Even though I’m a programmer. I still enjoy doing (2D) artwork from time-to-time. A friend has been developing a game for fun and I asked if I could so some art for it. The concept for the art I was aiming for was a spaceship that appeared like a sports car (Sort of like the game is about you driving sports cars in space and not allowed to scratch it). 20140326182623

Particle tool for CIT

20140228054828 There will be a separate post about this later. But basically, because I really enjoy particle effects, for my “Final Project” for CIT, I’ll be creating an “In browser” tool that lets you create particle effect animations to be used as animated sprites in your game’s particle engine. The need is that there’s not many cheap / free usable particle creation tools around, apart from having to create them in Adobe Flash or Photoshop. There are tools around that let you create super realistic particle effects like Fume FX for Maya and 3DS Max. but these aren’t cheap and they require a lot of setting up. They also don’t allow you to view the effects at real-time as they need to be rendered out, which takes a considerable amount of time. So the main aim for this tool is to have a particle effect generator that utilized WebGL’s GPU usage to display the particle systems and the browser can take care of the toolset.

2014 Class Work, Plasmation

Particle Tool Proposition

Leave a comment

20140327022854

Proposition

As I have a passion for particle simulation, I would like to create a 3D particle creation tool using WebGL in Google Chrome. The tool will allow the user to create a particle system that can render up to 10 million particles and export a single frame or animated sequence for use in games as sprites in their game’s particle system. This will be things like single smoke puffs, magic spark effects, fire, explosions, fighting effects, plasma bullets etc. As a way of getting more realistic particle effects without having the game simulate millions of particles, this can act as a mid-point between millions of particles being simulated in the game engine and having to create particle animations in Photoshop or other tools.

The tool will focus on real-time interface speed and be done using WebGL. I will research particle simulation techniques, one in particular is a trick that utilizes the graphics card and uses image maps as the positions, velocity and other elements using the RGB values of each pixel in the map for the X Y Z values of these elements. I will then use render targets to do post-processing like glowing, color manipulation, sharpening and lens flares.

The user will be able to render the particle system, like an explosion, magic effect or smoke cloud, and see each frame individually as it will be all stored on the video card. Once the user is happy with the animation, they can export it and download it as a sequence of PNGs (some may have many channels like alpha, multiply, additive). The rendered images will be done client-side and appear in the browser, able to be exported to use in their game engine.

As for game engines and target platforms, the tool will mainly focus on exporting for the Unity game engine, but because it will export PNGs, these could be used in any engine and any platforms, and because the tool will run in browser, it will not just be limited to PC, but in any platform that uses Google Chrome and WebGL.

The main goal of this project is to create a free, usable tool for artists that will allow them to create realistic special effect sprites like explosions, fireworks, magic effects, smoke and whatever they can manage to create. The niche is that there isn’t any free, easy to use tools that allows an artist to create a realistic explosion or a smoke effect other than tools like 3DS Max, and even those tools require a lot of setting up and don’t allow you to view the effects at real-time. They are also not built to do those sorts of things but rather are expensive complicated plug-ins for expensive complicated programs.

An additional thing I want to do is make the particle system like a plug-in so that people could use it in games for less intense particle systems. This is because I want to focus on getting as many particles rendered at real-time using GPU power.

Some ideas for extra work would be packing the images as a zip file, and combining them into sprite-sheets.

Some challenges:

  • “Domain” security with websites and web browsers accessing local data. Textures and save files will need to be downloaded/uploaded and the state of the application will need to be stored on the server the site is run from.

  • Lighting with smoke particles will be a challenge to get right. I will need to research how this can be done to many particles without losing much GPU resources.

  • Particle flow will need to be chaotic and still realistic so that it looks good enough, this may need to be simulated perhaps with particles representing pressure

  • Real-time storing of long animations will be difficult as they are stored client-size, these particles will use a LOT of memory, and some systems will either run out of GPU memory or physics memory. So this will need to be closely maintained.

Some research that will need to be done is on usability. I will ask people from the industry and artists about the tools they use, the issues they have with them, and things they like and are familiar with. This will help with the layout and to keep usability solid.