Stuff and things, and Game Dev

Posted by anthonyloprimo on Oct. 21, 2013, 10 p.m.

So I've been at a bit of a standstill lately with pretty much anything outside of work. I've recently taken on a FULL TIME job, so of course it's time to get used to having far less free time than I ever had before to take care of my 'hobbies', and 'side jobs'.

And by that I mean anything outside of work. Sleep (what is that anyway? :P), games, and game/web development as well.

For those that don't know… pretty much everyone here I've finally escaped the evil known as Retail, and while I'm still at the same store, I'm now a tech, currently in an entry level position working on the returned units (some TVs and screens, desktops and laptops mostly). I either restore them for resale, order parts or have them sent out. It's pretty simple but it's in the direction of what I want to do, and where I want to be. I've not felt this happy to be at work since… well, since my first job ever, so the eagerness is there, and I'm freakin' thrilled!

Unfortunately while it means more money, and more hours to earn even MORE money, it's not always a great thing. I've got less time for stuff I've wanted to do but… well, hell, it's easier to build up paid vacation hours anyway so why not :P

I see I missed S4D but that's fine. I'm not about to throw off a job I'm looking to be more serious about right now though maybe I'll manage to do the next Frosty 4 Digits competion or something (or work with nick to get a second release of the game out just for the sake of getting something done)!.

Other than Deep Freeze (which has had very little done to it in recent months), I've been working on a top down game engine, and a possible side view platformer. I've still got plenty of things to do with both engines, with the platformer engine needing a LOT of work, but the top-down engine is getting better and better, and when I'm finally happy with it for release and having input from others (and getting help), I'll be posting about it quite soon. It's definitely quite an ambitious project, but so far I'm quite enjoying the progress I've made on it.

Anyway, I'm afraid my blog is gonna spiral into meaningless rambling so I'll stop here and get some sleep. I've got mostly 9AM-5PM shifts and… it's not bad, but I'm still getting used to such early shifts for me. X_X


JuurianChi 7 years, 7 months ago

Try Try Try.

What are the defining features for your top down engine?

anthonyloprimo 7 years, 7 months ago

Well, compared to anything else I've done personally? Smooth wall collisions whether you run or walk. Rudimentary enemy AI (within a certain range they no longer move randomly but actually move towards you). Solid object interactions (proximity and RIGHT next to an object). Pushable objects that somewhat interact with one another (need to develop this further). Melee attack with a rather awesome 3-hit combo.

Everything here I've not done before - at least not to the level of polish it's at right now, anyway. I'm quite proud of it, though I feel I've got a ways to go before I start showing anything - it's mostly temporary or placeholder sprites (i.e. from other games) for the sake of having something I could use to work with as an example.

svf 7 years, 7 months ago

What language is the engine coded in?

anthonyloprimo 7 years, 7 months ago

It would be GameMaker Studio. I've wanted to move to some other languages but I haven't had time to learn more about some of the ones I've wanted to learn. :/

Crazy_Star 7 years, 7 months ago

Pushable objects that push obther objects ftw

anthonyloprimo 7 years, 7 months ago

@SpectreNectar I'm working on that next. Right now if it hits ANYTHING - another block, another wall, another pushable thing, even an enemy - it does nothing. I want to make it so it not only pushes other objects but has implied physics - perhaps objects have a rating and that will further alter just how fast it will move. If it pushes enemies, it slows down. If it pushes blocks, it might slow down more. A combination of objects in the way further alter how fast it moves. It's something I've been considering but being busy, tired, having other obligations and other recent things have made continued development quite difficult. Hopefully I can get back to it soon!

Crazy_Star 7 years, 7 months ago

I'd stray away from distance calculations and all that jazz. Movable versus movable should be discrete unless you want to give yourself a hell of a headache.

Quote: wiki
A posteriori (discrete) versus a priori (continuous)

In the a posteriori case, we advance the physical simulation by a small time step, then check if any objects are intersecting, or are somehow so close to each other that we deem them to be intersecting. At each simulation step, a list of all intersecting bodies is created, and the positions and trajectories of these objects are somehow "fixed" to account for the collision. We say that this method is a posteriori because we typically miss the actual instant of collision, and only catch the collision after it has actually happened.

In the a priori methods, we write a collision detection algorithm which will be able to predict very precisely the trajectories of the physical bodies. The instants of collision are calculated with high precision, and the physical bodies never actually interpenetrate. We call this a priori because we calculate the instants of collision before we update the configuration of the physical bodies.

The main benefits of the a posteriori methods are as follows. In this case, the collision detection algorithm need not be aware of the myriad of physical variables; a simple list of physical bodies is fed to the algorithm, and the program returns a list of intersecting bodies. The collision detection algorithm doesn't need to understand friction, elastic collisions, or worse, nonelastic collisions and deformable bodies. In addition, the a posteriori algorithms are in effect one dimension simpler than the a priori algorithms. Indeed, an a priori algorithm must deal with the time variable, which is absent from the a posteriori problem.

On the other hand, a posteriori algorithms cause problems in the "fixing" step, where intersections (which aren't physically correct) need to be corrected. Moreover, if the discrete step is not related to object's relative speed, the collision could go undetected, resulting in an object which passes through another, if fast enough.