I think you have misunderstood how distributing code works. Ignoring the fact your framework is a short collection of trivial functions no one is likely to want, you still need documentation and licensing clear before anyone is likely to use it. You should also have a clear hosting location, assign version numbers to releases, and provide a short summary of what the intended purpose of the code is.

Probably easiest just to have a series of getting started rooms, one for each choice, and you must make a choice to move to the next room. Then you can just repeat the hair color block several times, just have each one only apply when you enter a specific room, rather than start of game.

Simply add up the values as fallsberg indicated, then look up the tile index in this table:

Code:

0 0
1 1
2 2
3 2
4 3
5 4
6 2
7 2
8 5
9 5
10 6
11 6
12 7
13 7
14 6
15 6
16 8
17 9
18 10
19 10
20 8
21 9
22 10
23 10
24 11
25 11
26 12
27 12
28 11
29 11
30 12
31 12
32 13
33 14
34 15
35 15
36 16
37 17
38 15
39 15
40 5
41 5
42 6
43 6
44 7
45 7
46 6
47 6
48 18
49 19
50 20
51 20
52 18
53 19
54 20
55 20
56 11
57 11
58 12
59 12
60 11
61 11
62 12
63 12
64 21
65 22
66 23
67 23
68 24
69 25
70 23
71 23
72 26
73 26
74 27
75 27
76 28
77 28
78 27
79 27
80 29
81 30
82 31
83 31
84 29
85 30
86 31
87 31
88 32
89 32
90 33
91 33
92 32
93 32
94 33
95 33
96 21
97 22
98 23
99 23
100 24
101 25
102 23
103 23
104 26
105 26
106 27
107 27
108 28
109 28
110 27
111 27
112 29
113 30
114 31
115 31
116 29
117 30
118 31
119 31
120 32
121 32
122 33
123 33
124 32
125 32
126 33
127 33
128 34
129 35
130 36
131 36
132 37
133 38
134 36
135 36
136 39
137 39
138 40
139 40
140 41
141 41
142 40
143 40
144 8
145 9
146 10
147 10
148 8
149 9
150 10
151 10
152 11
153 11
154 12
155 12
156 11
157 11
158 12
159 12
160 42
161 43
162 44
163 44
164 45
165 46
166 44
167 44
168 39
169 39
170 40
171 40
172 41
173 41
174 40
175 40
176 18
177 19
178 20
179 20
180 18
181 19
182 20
183 20
184 11
185 11
186 12
187 12
188 11
189 11
190 12
191 12
192 21
193 22
194 23
195 23
196 24
197 25
198 23
199 23
200 26
201 26
202 27
203 27
204 28
205 28
206 27
207 27
208 29
209 30
210 31
211 31
212 29
213 30
214 31
215 31
216 32
217 32
218 33
219 33
220 32
221 32
222 33
223 33
224 21
225 22
226 23
227 23
228 24
229 25
230 23
231 23
232 26
233 26
234 27
235 27
236 28
237 28
238 27
239 27
240 29
241 30
242 31
243 31
244 29
245 30
246 31
247 31
248 32
249 32
250 33
251 33
252 32
253 32
254 33
255 33

If levels are small, short strings users can copy paste to each other are the easiest for users to share. After that, images with the level data embedded, there are many image hosting sites users can use. And finally full on files + dropbox, ftp, etc.

No matter what, you'll still need your only server if you want ratings. If you don't like the idea of registration, store unathenticated author metadata in each file, and let them upload without an account. You track levels, rather than users, after all. Some user bases don't really mind the forgability aspect.

the AS3 documentation recommended using Number over int for big integers (which is horrible advice).

That's because it can hold more integers than an int can. It does all integers up to 2^53, vs 2^32 for ints. In some circumstances this is handy, but not that many.

Python struct module is probably what you want. It supports different endianness's, so if you start your struct with ">" it should just work.

Code:

import struct
data = open("myfile","r").read()
struct.unpack(">iiiff", data)

etc

Note, reading binary formats can be a bit tedious. If you control the java program, there are easier output format you could use.

could you imagine any scenario where one would have to be running two or more states simultaneously? Like if i wanted to do a cross-fade between two states?

It seems most people (myself included), code support for multiple states directly into the managing function if they need that sort of functionality.

But seeing as nearly everyone is using classes to represent each state, you could imagine a TransitionState that owns two children state. and makes use of both, eventually yielding control to one of them. Would work particularly well with Average's "return the next state" method.

I'm pretty similar. I general have a bunch of Screen objects, arranged in a stack by the ScreenManager. The top-most Screen object is active, the others suspended. Sometimes I have a concept of "transparent" screens, which means that screens below it still get calls to Draw(), but not to Step(), so they are paused. The menu screen is pushed in main, and it is responsible for constructing and pushing the game screen, which is responsible for constructing and pushing cutscenes, pause menus, etc.

I find it's not helpful to view different screens/modes as states of a state machine. You typically need to pass more info than just the type of screen, and the information to be passed is highly specific to the particular transition.

Imho, the hate of singletons come from desire to run tests. Effective unit tests means no global state, everything must be injected (also, polymorphic). So namespaces are no better (though one could disciss their merits vs singletons in other areas). There's no doubt that removing global state complicates your code, though often bettering it by making it more reusable.

Testing and reusability are offen lesser concerns in games, so I'd generally say go for it - you can always refactor later (caveat: refactoring out singletons can be really tedious and widespread).

For the cause of audio, I don't see why they would make a particularly good example. You'd probably want to switch audio output methods (to support *no* audio, at least). And anywhere likely to want audio access is probably going to need access to the display and other critical components - you might as well bundle all that together in a UserOutput object, and pass a reference to that around.

[However]

Dude, if you consider 2 or zero physics frames per event loop to be visible stuttering, then you are never going to be happy with an event loop like that, as it must happen occasionally, or else the accumulator is doing nothing. However, smoothing should elimate the most of the problem (as you are going from "late in frame n" to "early in frame n+2" which is a difference of roughly one frame).

I would posit you have a bug in your smoothing code. As a guess, it would be you are miscalculating accRatio. Normally, the ratio is between 0 and 1, showing progress through the current frame. But yours is always above 1. Try moving the calculation of accRatio after the accumulator subtraction. You may need to adjust your smoothing code, too.

I should point out for platformers the only force of note is constant gravity. Euler doesn't correctly integrate it, but most other techniques are actually 100% accurate for that particular setup (including velocity verlet iirc), so there is no further accuracy to be gained from using RK4.

Aside from fixed intervals, another way of timing an ongoing series of events is test if you should randomly generate an event every frame. If you do 60 tests per second, but the chance of an event is only, say, 1 in 300, then you'll get roughly an event every 5 seconds. But sometimes they'll be clustered together, sometimes they'll be spread apart. It feels very natural, and makes players a bit more wary of when they just get unlucky with the waves.

The maths of this is you are approximating the Poisson distribution, which is a very common real world distribution for series of events with a even arrival rate, for example, the distribution of buses at a bus stop.

It also lends itself very naturally to different difficulties and spawn types. Increase difficulty just by increasing the probability of an event. You can do multiple types of enemies by doing a separate test for each type. If you sum the probabilities for each event type, you get the total probability for any event (assuming the probabilities are small, as in my example above), so it is easy to mix the balance of types while keeping the frequency of waves the same.

st33d, I think you are apologizing a bit too hard for Adobe here. Gamepads have a standardized interface (google USB Human Interface Device). It is not hard to support all gamepads, Enjoy or JoyToKey manage it. And it's certainly rubbish to suggest that there are security risks - doesn't Flash now have various shader support, despite that being a potentially huge security risk if poorly implemented.

Granted, the interface is not "consistent", but that shouldn't really stop Adobe. Their keyboard API is not consistent either, (as IIRC keys are mapped by their value, not their phsyical location), but its still useful.

I suspect they haven't done it for lack of demand, rather than any serious technical issue.

Ok, yes, you need the cross products too, I got it wrong. Too used to 2d. It still seems simple to implement, if not as efficient.

In fact, SAT seems an even easier way, is there a reason you didn't just do that:

Code:

def support(axis, box):
  # Returns a point on box furthest along the axis.
  ...

def all_axis(box):
  # Yields the 3 perpendicular axes of the box, and their negatives.
  ...

def closest(box1, box2):
  dist = Infinity
  v1 = None
  v2 = None
  for axis in all_axis(box1):
    t1 = support(axis, box1)
    t2 = support(-axis, box2)
    d = get_distance(t1, t2)
    if d < dist: dist, v1, v2 = d, t1, t2
  for axis in all_axis(box2):
    t1 = support(axis, box1)
    t2 = support(-axis, box2)
    d = get_distance(t1, t2)
    if d < dist: dist, v1, v2 = d, t1, t2
  return (v1, v2)

Raigan, you were very close, but not quite there.

What you want is the GJK algorithm. It works for any convex shapes, but for boxes it will terminate in at most 6 steps (one for each of the axes involved). It is pretty simple to implement.

Here's an example of the code.

When A == B, your formula simplifies to "1". Is it really surprising this is a special case?

Guys, you are getting confused. The fact that floats use base-2 for the exponent is pretty unrelated to the fact that computers use base-2 for integers - our ordinary binary computers can handle base-10 floating point (called decimals) perfectly fine, they just need an appropriate arithmetic unit, same as for binary floats.

Nonetheless, clearly, a prototype from 1958 doesn't really demonstrate much about what is and isn't possible today. Are you just trolling us by suggestiong ternary rational based computers? Next, you should say that computers should do symbolic logic, so that we finally don't get rounding errors from sqrt(2)...

You should probably abstract the connection, you don't literally want every monster to be a separate process, and so you can test the game before you've got the IPC sorted.

Sockets are pretty much the standard way to communicate, and I think they are more similar between platforms than pipes are. As you say, they are also a proper "duplex" connection, which makes a lot of things easier.

If you weren't explicitly looking to learn sockets, I'd recommend using a library. ZMQ, for example, is a lightweight abstraction of sockets that would be pretty handy for you, hiding some of the boring parts. You'll probably also need a serialization library.

Code:

if( (1 << whatever) & ((1<<3)|(1<<5)|(1<<15)))