-
Notifications
You must be signed in to change notification settings - Fork 1
/
b58_project.txt
163 lines (120 loc) · 7.84 KB
/
b58_project.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
CSCB58 Project File: Summer 2017
Team Member A
-------------
First Name: William
Last Name: Granados
Student Number: 1002314114
UofT E-mail Address: william.granadosmatamoros@mail.utoronto.ca
Team Member B (dropped course)
-------------
First Name: Saskia Selestyna
Last Name: Tjioe
Student Number: 1003279007
UofT E-mail Address: saskia.tjioe@mail.utoronto.ca
Team Member C (Optional)
-------------
First Name: Venkada
Last Name: Prasad
Student Number: 1002263953
UofT E-mail Address: venkada.prasad@mail.utoronto.ca
Team Member D (Optional)
-------------
First Name:
Last Name:
Student Number:
UofT E-mail Address:
Project Details
---------------
Project Title:
Starflux
Project Description:
Vertical version of the arcade game: FPGA defenders. The difference being
is that we have a cool down timer, a health bar, and allows for movement
in all directions(up, down, left, right).
Video URL: https://youtu.be/oSgEVmga3t4
Code URL (please upload a copy of this file to your repository at the end of the project as well, it will
serve as a useful resource for future development):
https://github.com/wgma00/Starflux
(now public)
Proposal
--------
What do you plan to have completed by the end of the first lab session?:
We plan to have the basic functions of the game completed by the end of the first
lab session. That includes the basic movements of the ship and its bullets, as
well as the cool down timer and the score. We would have also made plans
for the graphics of the game.
What do you plan to have completed by the end of the second lab session?:
We plan to have completed the functions of the enemy ships and also their
movements. We will also add other features such as the health bar, and refine
the feature of the score with the max score cap. We would also have begun the
graphics of the game being displayed to the screen.
What do you plan to have completed by the end of the third lab session?:
By the end of the third session, we plan to have completed the game mechanics. We also
would have refined the final graphics of the game and make sure all the functions of the
game have been met.
What is your backup plan if things don’t work out as planned?
If things go off course, we are willing to work extra hours or remove some features
of the game, such as the health bar or the cool down timer. We can also tone down
certain features, such as having enemy ships continue down one column down the
screen instead of giving them dodging capabilities.
What hardware will you need beyond the DE2 board
(be sure to e-mail Brian if it’s anything beyond the basics to make sure there’s enough to go around)
None so far.
Motivations
-----------
How does this project relate to the material covered in CSCB58?:
This project relates to the material covered in CSCB58 with the use of
shift registers and counters from the labs. It is also an application of the VGA
display. And given enough time, we could also impelement some sort of strategy
for the enemey ships by making use of FSMS.
Why is this project interesting/cool (for CSCB58 students, and for non CSCB58 students?):
This project is interesting for people because many people take great enjoyment
in video games, and Starflux will be a game that can start off many who are new
to gaming.
Why did you personally choose this project?:
We chose this project because we felt it would be a nice challenge to see how
well we can apply our learned concepts into something fun that can also be built upon
later on. One of the members of the group remember the game being implemented
by one of their friends in highschool (with Java), and saw a lot of the core
components could be translated over to hardare.
Attributions
------------
Provide a complete list of any external resources your project used (attributions should also be included in your
code).
VGA_font_rom.v was based off of this source:
https://github.com/yzheng624/verilog-pong/blob/master/pong/front_rom.v
ship.v was based off of this code:
https://github.com/bogini/Pong/blob/master/pong_text.v
Main inspiration for the game.
https://github.com/justinli1/CompSci-Final-2015
Updates
-------
Week 1: We built the cooldown timer and also tested the bullets. Unfortunately, the bullets were completely non-functional
despite best efforts, so we will work extra hours to fix the issue, as there is no game without the weapon. However, the cool
down timer and score are working, just need to speed up the clock and add a narrower cap to prevent the player from waiting so
long for their gun to cool down. Of course, we will have to at this point double book to make time for the next lab session. We
have also changed features to make the gun and bullet mechanics easier, such as simpler bullet mechanics for the enemy ships that
will also act as a series of boss fights rather than a swarm.
Week 2: We had achieved functionality in the health bar, cooldown timer, and also built the player ship's movement mechanics, which
have been simplified into just left and right movements. We have also made the font ROM for the display so that the title can be displayed,
and have also built the ship, although it does not display anything due to complications that should be settled over the weekend. We will
test outside of lab hours before the next lab so that we do not waste time and only have working code at the ready. We have also made the
repository for the project public. As the code for the font ROM and the VGA have been borrowed from outside sources, they have been added
to the Attributions list. Over the next week before the next lab, we will work on the enemy ship. It is no longer a swarm, but instead
one powerful adversary who will speed up with every hit it takes from the player. It's movements will be very simple, only
from left to right, and the bullets will come out as a constant stream that the player must avoid.
Week 3: We modularized the code and added better documentation for some modules. The portion for the drawing and resetting the screen
has been revamped. We have tested the movement pattern of the enemy ship on the screen and have also managed to dislayed the user and
enempy ships on the vga screen. Most work regarding the shifter bit grid has been completed, now we just need to integreate this part
completely into the project so that we can simulate the bullets moving through the grid. The hexlogic for HEX0-HEX5 has been finalized,
and now we only need to complete the requirements of the shifter grid for full functionality. We've also integreated a special game over
LED flash show into our FSM state. For next week we plan to finalize the shifter bit logic into our project, and handle collision detection
for our the ships and bullets. We also plan to enhance the enemy behaviour when they are hit by bullet, specifically we wil make them faster.
Week 4: We finalized the 2D shifter bit functionality that was desired and as a result we managed to finalize the bullet collision with the
ships. One major change that made was instead of two ships shooting at each other, we made the game into a bullet dodging game where if the user
gets hit by the enemy's bullet then the user instantly dies. The score for the game is based on how long the user manages to survive. With this change
also came the change of HEX4, where it counts from 0 to F and upon reaching F the user is given break until the next barrage of bullets. We also implemented
pausing functionality for the game using switch 1. We also had to debug design issues and compiler issues. Some issues we had were using division and modulo
to determine the pixel to draw on the datapath but we discovered that the division and modulo operator are expensive and take multiple clock cycles to complete.
Another issue is verilog creating implicit types for variables with typos and therefore we spent a long time finding the implicit types. We also had huge
compilation times approximately 40 minutes each time which took longer to find the bugs.