(01-08-2016, 08:02 AM)Raccoon Sam Wrote: [ -> ]this thread is FULL of amazing stuff good job guys!! VERY inspiring.
How do I get into gamedev
Since you know Python, I would recommend it.
Pyhton has PyGame for game dev and, as far as I know, it is very good for it.
I have same experience in programming, not game programming, and I know Python. I plan to start to remake old games using just Python with PyGame.
I dunno, the last stable release was 6 years ago.
I figured it was best to go the whole nine yards so I bought an exercise-oriented c++ book and I'm now digging through it. Interesting stuff.
(02-10-2016, 03:35 AM)Raccoon Sam Wrote: [ -> ]I dunno, the last stable release was 6 years ago.
I figured it was best to go the whole nine yards so I bought an exercise-oriented c++ book and I'm now digging through it. Interesting stuff.
Yes, you're right...
But I'll give a try, since it is the main lib in Python for gamedev a new version can pop up soon or later...
I have a mild curiosity.
The html5 gamedev stuff I'm working on in my free time uses an asset library that is link-based.
I have done this for a few reasons.
For one, i am porting, or attempting to port, a few flash games, one of which heavily uses the actionscript linkage of its assets.
For two, i want something dynamic. Instead of modifyng my main code every time I add an asset, and a reference to it, I want to simply modify my data files, and the asset libraries, themselves. I also want to have an easy way to free assets wen no longer needed. For example , using a method of my AssetManager object like clearAssetGroup("splashscreens"), would delete that entire section of the in-memory asset library, rather than me having to do something like
assets.splashLegal.remove();
assets.splashTechVideo.remove();
assets.splashDev.remove();
etc...
The same also could be applied to dynamically loading the resources on-demand.
Besides dynamically loading/removing assets, I want to dynamically pre-render those utilizing potentially cpu or gpu-intensive modifications/transforms, if possible. So, for example, if I need to use color matrix filters to make my white box pure red, I can store the color-transformed sprite so all I have to do is access the pixel data from memory, rather than re-apply the color matrix filter every frame.
Also, while I currently am utilizing html5, I might do this in other languages, too, maybe...
Basically, I'd rather do:
external script (i do not utilize these yet, but I might at some point):
OBJ PLAYER
EXTEND ENTITY
DEF SPR "Spr_Player"
DEF HP 10
DEF ISPLAYER true
DEF SPD 5
END
asset library entry:
type: sprite_img
offsets: x:0 y:0
dims: w:16 h:16
src: sprite_player.png
vs.
class Player extends Entity{
import lib.util.graphics.PNGLoader
import lib.util.graphics.Sprite
//etc
Boolean isPlayer = true;
Int hp = 10;
Float speed = 5;
Sprite spr = PNGLoader.loadPNG("sprite_player.png");
//then defining offsets and crap
}
Also, if for some reason I were to change anything about the player sprite, I do not have to re-compile my program (assuming it was a compiled language). This, depends of course, on how the asset library was structured. if it were a series of JSON files, folders, and .png images, fairly easy. If it were a .dll or a .zip, well, I might have to re-compile or re-pack the asset library.
Sorry if I'm less than clear.
Basically, I want something that's easy to extend and doesn't rely on too much hard-coded stuff.
Also, even if I made a closed-source game, I'd like to support some custom content.
If i used the linked assets and external data/scripts, I can give the end-user some pretty good customization options without exposing the heart of the game even slightly. This would be subject to the limitations of the game, itself, but done right, it still yields some nice customization.
What does everyone else think about this, though?
This is a technique that's often used in games. It's especially useful when the engine is mostly done and you're focusing on things such as level design. You do need to make sure that the scope of what you allow to be modified externally is something that you're comfortable with players modifying. Otherwise you'll have to encrypt or otherwise obfuscate files which, as any ripper here knows, doesn't always help anyway.
The "Engine" , if it can really be called that, is kinda in-development, XD...
Most of the features aren't really implemented. They're kinda getting added on-demand, as my gamedev projects necessitate them. I find this works pretty well. (for me, anyways.)
This would be a problem regardless of how I developed things...but yes.
I, personally, do not have much I'd want to encrypt/obfuscate at the moment.
My question was more for the actual practicality/advantage of using an asset linkage system.
Thanks for your answer!
JavaScript prototype?
Currently, any object I create does this:
Code:
function Object0(pars...) {
this.prop = value;
this.method = function(pars...) {
//code
}
}
Would there be any significant performance improvements to instead use
Code:
function Object0(pars...) {
this.prop = value;
}
Object0.prototype.method = function(pars...) {
//code
}
?
I originally avoided this because finding clear and concise JavaScript ref. sometimes is well, impossible. Thus, any example of prototype I'd ever seen was ... confusing. Well, last night, while working on my new hacking project, I observed that all object methods are defined using prototype. If there's a significant enough improvement to performance, I don't mind going through some of my code and changing it to use prototype. (aside from the INI parser, since that makes Flash ActionScript porting... not as easy, and it was designed so a port to AS2 would be ... "smooth". Also it's a small library that doesn't do intensive stuff, anyways) However, if it's not very significant, I'd rather not bother.
Currently, my html5 game doesn't perform super well for me when it has a lot of entities on the screen. If I can improve it without writing a lot of very confusing code I wouldn't understand (like an __extends function...) , I will. I fear that as it stands, it's not going to meet any of my requirements for even developing the library/engine/<WHATEVER THE HELL YOU WANNA CALL IT> behind it.
afaik prototype is mostly useful if you want some more serious oop/inheritance
but i'm no expert
https://dl.dropboxusercontent.com/u/7134...e2015.html
That's a link to my latest javascript game engine, if you wanna take a gander at it; I doubt it's much good, but it works for me, and you might get something from it
or not (it's not very efficient either/super amateur)
who knows
makes me think suddenly, it'd be cool if we could like post code and be like "hey anyone want to code review this" because I have never gotten any of my non-work code reviewed and that'd be pretty cool
1.
I got some other replies elsewhere, and did some testing on the basic tech demo of my engine, if it can be called that.
http://crystalien-redux.com/unrelated/ET.../game.html
(note: the prototype test was a simple testing build, it won't be showing-up there...for now)
results of that:
*values are approximations:
[HTML5 GAME LIB LAG TEST PROTOTYPE VS. ORIGINAL]
prototype: 1000 bros
original: 800 bros
good pc prototype: 6000 bros
good pc original: 3000 bros
Obviously, this test wasn't thorough, it was simply to see at which point lag became notice-able.
As for object inheritance...
Yeah, I'm not messing with that part. I'll just use Haxe or TypeScript or something, cuz I'm NOT manually writing the stuff that makes inheritance "work" in JS, NOPE!
2.
nothing happened when I loaded the page and I proceeded to open the web console
saw this:
Error: WebGL: Error during ANGLE OpenGL init. modernizr-1.6.min.js:18:298
Error: WebGL: Refused to create native OpenGL context because of blacklisting. modernizr-1.6.min.js:18:298
Error: WebGL: WebGL creation failed. modernizr-1.6.min.js:18:298
Error: WebGL: Error during ANGLE OpenGL init. modernizr-1.6.min.js:18:349
Error: WebGL: Refused to create native OpenGL context because of blacklisting. modernizr-1.6.min.js:18:349
Error: WebGL: WebGL creation failed. modernizr-1.6.min.js:18:349
ReferenceError: InputKeyboard is not defined gameengine.js:132:3
oops that's fixed
I should maybe try those sorts of benchmark whatevers and see how bad my engine is lol
randomly, if those squares were like 0.25 alpha, I bet it'd make for a really cool looking animated background or something
I still don't seem to see anything, but errors are resolved, at least.
well...
I could easily make some of those tweaks.
Hell, I could add other colors.
Very easily.
Dammit...I'm getting ideas, now...
I have enough of those! lol
I'm working on adding UI crap to my game library (decided against calling it an "Engine" , necessarily, the only things that the re-usable code actually comprises of are all the back-end crap so I don't need to re-write it a thousand times.
http://crystalien-redux.com/unrelated/ET...ameUI.html
It doesn't load correctly the first time, if anyone knows how to fix it, would be nice
Also, thoughts in general?
(and yes, the example is a re-color of the Windows XP default theme "Luna". I have another project that shamelessly attempts to create fake Windows Message Boxes, but it's a little behind due to some data loss)
EDIT:
Still have weird first time bug, but I've added actual UI Panels and Components (that do nothing besides render, at present).
this is how it looks when I go to the page:
it doesn't change when I refresh it and I didn't see anything in the dev console; what is the problem?
ok, so for me and some others, THIS happens when it first loads after a length of time:
the other one happens regardless, try holding c down for at least a few seconds, the re-sizing prompt goes into an infinite loop
The first bug is a major rendering inconsistency, and really shouldn't be happening.
The second is a fatal error, and can't be allowed to remain unresolved, when i re-load the page, after tripping it, I get:
uncaught exception: out of memory <unknown>
edit:
now supports click + drag title bar to move the window, but old bugs still persist
hmm if it's helpful to know, I had opened it in firefox (what I assume is the latest version)
though it's looking like that for me, too, now