2FIVEEIGHT - 2fiveeight.com
Started as a school project for Web API at the University of Colorado in Denver, 2FIVEEIGHT is a social media app in the vein of Instagram, Snapchat, and Twitter. I worked on developing the front-end in React with JSX and CSS. I designed the feeds and layout of the app to be user friendly and easy to use and navigate. I was the project lead and worked to plan, set milestones, and encourage frequent communication among team members to ensure the project met the requirements we initially set. I also coded a majority of the back end in Node.js with Express and interfaced with the MongoDB database with the mongoose API and created the logo and app icons. Optimized for mobile.
Source code on GitHub:
Front-End: https://github.com/Gaveno/twofiveeightfe
Back-End: https://github.com/Gaveno/twofiveeight
Source code on GitHub:
Front-End: https://github.com/Gaveno/twofiveeightfe
Back-End: https://github.com/Gaveno/twofiveeight
|
|
Arduventure
A large open world turn based RPG for the Arduboy; Arduventure is my greatest achievement on the Arduboy. After the work I did to fit Mystic Balloons levels onto the Arduboy, the founder of TEAM a.r.g. asked me if I could figure out a way to store a large world on the very limited hardware of the Arduboy. He thought I could use a mixture of the techniques from Mystic Balloon and another TEAM a.r.g. project, Virus LQP-79. After a lot of planning I figured out how to construct the world using a bitmap for chunks, regions for how to determine the chunks from it's surrounding chunks, and exception chunks and tiles I called specific chunks and tiles respectively. Due to the complexity of this system, I spent about two months building a graphical tool to easily build the world and export it into C++ code.
Once the world engine was complete, I was planning on my role for Arduventure to be over. The game launched on kickstarter and had a successful campaign raising over $60,000! However, in the fall after the campaign, unforeseen circumstances meant I had to take over development and finish the game. I had about a month and a half to program the entire battle engine, shop, boss battles, and progression. It all had to be fun too!
All through December and January of intense planning, programming, and testing (and a lot of additional testing from my brother), I completed the game in time for the initial release to reach the Kickstarter backers.
Website: http://team-arg.com/ardu-media.html
Github: https://github.com/TEAMarg/ID-46-Arduventure
Once the world engine was complete, I was planning on my role for Arduventure to be over. The game launched on kickstarter and had a successful campaign raising over $60,000! However, in the fall after the campaign, unforeseen circumstances meant I had to take over development and finish the game. I had about a month and a half to program the entire battle engine, shop, boss battles, and progression. It all had to be fun too!
All through December and January of intense planning, programming, and testing (and a lot of additional testing from my brother), I completed the game in time for the initial release to reach the Kickstarter backers.
Website: http://team-arg.com/ardu-media.html
Github: https://github.com/TEAMarg/ID-46-Arduventure
|
|
|
|
Arduventure World Editor
The world is rendered to the Arduboy in a multi-step process. The method to draw the world loops through every visible tile to the view, and no more. From here things get technical.
Each x, y coordinate pair for the tiles is passed into getTile which returns which tile should be placed in that location on the screen. This method is where things get interesting. To find the tile, it has to know which chunk (6x6 matrix of tiles) it belongs to. The chunk is either determined by region, or by being specifically placed. The getChunk function first turns the coordinates into a single unique integer (think 2-dimensional array to 1-dimensional array) and then checked with a switch statement for all the specific chunks in the game. If that fails to find a chunk, it then finds which region the coordinates belong to. Regions are a rectangular sub-section of the map that can be layered inside one another with depth. These regions place chunks in one of three ways: Binary, the simplest, is either a solid chunk or an empty chunk, Empty Center and Solid Center take into account their surrounding chunks. For example, if the chunk being checked is in an Empty Center region, and all adjacent chunks are empty, then the player should be able to move from that chunk to any of the adjacent chunks.
GitHub: https://github.com/Gaveno/ArduboyWorldEditor
Each x, y coordinate pair for the tiles is passed into getTile which returns which tile should be placed in that location on the screen. This method is where things get interesting. To find the tile, it has to know which chunk (6x6 matrix of tiles) it belongs to. The chunk is either determined by region, or by being specifically placed. The getChunk function first turns the coordinates into a single unique integer (think 2-dimensional array to 1-dimensional array) and then checked with a switch statement for all the specific chunks in the game. If that fails to find a chunk, it then finds which region the coordinates belong to. Regions are a rectangular sub-section of the map that can be layered inside one another with depth. These regions place chunks in one of three ways: Binary, the simplest, is either a solid chunk or an empty chunk, Empty Center and Solid Center take into account their surrounding chunks. For example, if the chunk being checked is in an Empty Center region, and all adjacent chunks are empty, then the player should be able to move from that chunk to any of the adjacent chunks.
GitHub: https://github.com/Gaveno/ArduboyWorldEditor
|
|
Mystic Balloon
A platforming adventure game for the Arduboy developing as a collaboration with TEAM a.r.g. I designed the gameplay mechanics, programmed the gameplay and created a level editor tool to speed up development time. I also created the initial look and feel of the game and characters with placeholder art which was later refined upon by other team members.
It took several months of planning and research to figure out how minimize the level data in way that would allow over 30 levels to fit into the 30KB of storage available to the Arduboy. When released, the game received overwhelmingly positive feedback and was selected to ship pre-installed on all new Arduboys for over a year.
Website: http://team-arg.com/mybl-manual.html
Github: https://github.com/TEAMarg/ID-34-Mystic-Balloon
It took several months of planning and research to figure out how minimize the level data in way that would allow over 30 levels to fit into the 30KB of storage available to the Arduboy. When released, the game received overwhelmingly positive feedback and was selected to ship pre-installed on all new Arduboys for over a year.
Website: http://team-arg.com/mybl-manual.html
Github: https://github.com/TEAMarg/ID-34-Mystic-Balloon
|
|
|
Mystic Balloon Level Editor
The levels in Mystic Balloon are quite a bit simpler than the Arduventure world, but I knew I wanted to quickly and easily design and test the levels for the game. I kept the interface straight forward without pop-ups (except for opening and saving levels) to keep everything right within reach.
Technical aspects...
The levels are stored in two parts: a bitmap where each bit represents whether a tile is solid or empty, and the object data. All levels are 24x24 tiles (cells) in size and each tile is 16x16 pixels. Total tiles is 24x24 = 576 so divded by 8 gives us 72 bytes per level for the tile data. Objects are 3 bytes per fan and 2 bytes per any other object. Each object can have at most 6 instances except for the key, door, and player which are all singletons, and all required.
To allow the objects to take up as little space as possible, the bits are used as follows:
Technical aspects...
The levels are stored in two parts: a bitmap where each bit represents whether a tile is solid or empty, and the object data. All levels are 24x24 tiles (cells) in size and each tile is 16x16 pixels. Total tiles is 24x24 = 576 so divded by 8 gives us 72 bytes per level for the tile data. Objects are 3 bytes per fan and 2 bytes per any other object. Each object can have at most 6 instances except for the key, door, and player which are all singletons, and all required.
To allow the objects to take up as little space as possible, the bits are used as follows:
It could be argued that 31 is the maximum value stored in 5 bits which means it could have been more efficient to make each level 32x32 tiles instead of 24x24. But it also would have meant each level would be 32 x 32 = 1024 divided by 8 is 128 bytes per level and therefore less levels overall so it's difficult to determine which option would have been best definitively.
|
|
Sammy's Great Adventure
My first time working on a 3D game, Sammy's Great Adventure was a school project for my game design class. The summer before the class began I taught myself as much 3D modeling, animation, and rigging as I could in 3D Studio Max. This project was created in Unreal Engine 4 with 3D Studio Max and Adobe Photoshop for textures. I created all the character models, animations and textures, as well as coding the primary gameplay dynamics. My group partner worked on the UI elements, and level transition dynamics.
Github: https://github.com/Gaveno/Sammys-Great-Adventure
Github: https://github.com/Gaveno/Sammys-Great-Adventure
