Posts Tagged ‘framework’

Helloo

Friday, April 17th, 2015 2:29 pm

I will be using https://github.com/gardenvarietyse/ld32base which is just my basecode from LD30 but I put 32 instead of 30. how awesome right

yeaa

I’m In! – Part 2: My Code Base

Posted by
Tuesday, April 14th, 2015 2:38 pm

Hello everyone, this is the second part of my ‘I’m In’. There will be one more part where I will list the tools I’m using. It’s a bit silly to do it in three parts but I’m still learning how all this works so I thought I’d take it slowly.

I’m hoping to use my CGS Framework for the compo which contains a collection of Unity3D C# scripts. CGS stands for Core Game Systems and it generally contains a bunch of useful tools that help speed up development:

  • Hierarchical state machine
  • Event driven communication between components
  • Unit test tools
  • Save/load functionality
  • Numerical ‘stat’ class that you can apply modifiers to
  • Physics based character controller
  • Item and inventory system
  • Debugging tools
  • Time and file utility classes

What I’m keen to know is whether or not any of these features violate the definition of ‘base code’ and therefore should not be included? If this is the case let me know and I’ll remove them and upload a revision.

Zip file of framework code:

CGS v1.0.3

 

Edit:

Adding a script to my code base from this link:

http://answers.unity3d.com/questions/148812/is-there-a-toggle-for-snap-to-grid.html

To clarify, because I was sleepy last night, I’m using the C# script on that link for autosnap in Unity.

Last minute preparations

Posted by (twitter: @Ananace13)
Monday, December 1st, 2014 1:20 pm

So I realized that I haven’t spent the proper amount of time actually preparing for this LD compo, which means that I’m going to be doing a bit of coding right up until the compo itself starts.

Since I’m doing my entry in C++, like I tend to do, I have to write up all the utility code that I’m going to use during the compo itself. So I’ve set up a GitHub repo where I’m writing up this code, and I’m doing it properly this time. With test cases and the “engine” separate from the game code itself. (Not an engine per-se, more a large bunch of useful snippets and classes)

Though I guess that since I’m planning on doing as much of the game as possible through scripts the whole separation is a moot point.

Either way, you’re welcome to see the code skeleton as it fleshes out to something that can actually be used. Going to tag, branch, and try to keep the game code split from the rest. Maybe the framework will end up as something other people might be able to use after all.

Feel free to watch the progress at https://github.com/ace13/LD31 and I wouldn’t mind hearing any suggestions you might have for useful things to include into such a framework. And feel free to throw issues at me if you find things that are just plain wrong in the code, constructive criticism is always welcome.

 

Happy coding to you, and I hope you’re better prepared than me for what’s coming.

Throwing my hat in!

Posted by
Friday, April 25th, 2014 12:02 pm

I’m participating on this one again, and I’ll be posting updates on my blog, and on Twitter (@shadowcovenant, if you want to follow me), and also on the website…

I’ve updated my basic LD48 framework with some stuff I think I may need (nothing game related, just some stuff most engines have out of the box)…

image

You can download the framework here, if you want to use it (it has some sample applications that show most if not all the features). Current features:

  • D3D9 initialization and some helpers
  • FMOD interface for sound
  • 2d Sprites (with sprite caching, etc)
  • 2d Particle System
  • Simple UIButton for easy menus
  • Text (through FreeType 2)
  • 3ds file loading (only tested with 3ds generated by 3d Studio Max). Loads lights, meshes and cameras.
  • Small simple math library (vectors and quaternions)
  • Simple 3d camera handling system (just with a “look at” operation)
  • XML loading/saving (might come in handy for configuration files, load/saves, etc. The XML loader was created by Frank Berghen, not me… the writer is all me, although the loader also has save functions, but I’m too lazy to figure out how they work)
  • 3d particle system (based on the 2d one, so very rudimentary)
  • 3d sprite system (quads that always face the camera)
  • LUA library support (it’s actually ripped from my engine, so it’s a good support system for LUA)… Last time I used cutscenes and scripting, and loads of the game code was much simpler because of that…
  • DDS image loading for an offscreen buffer (just supports A8R8G8B8 images). Might be useful for some level design stuff, although I’ll probably go back to my old days of text files.
  • 3d Tilemap (Kind of a blocky heightmap with an automatic texture atlas generation and partition of the map in chunks for possible culling (not implemented)).
  • Voxel system (almost fast enough for realtime regeneration)
  • Simple geometry generation (quad, cube, spheroid, caps and cylinders)
  • Special effect objects (sparks, explosions, although the explosion require some authoring)
  • Full-screen effect systems (to implement glows, or invert the colors, or add displacements, etc)
  • Full shader-based rendering system (no fixed-function pipeline), with simple lighting system (only shadowless point and spot lights, although directional lights should be easy to implement, just a matter of adding to the shaders). Shader system is built with uber-shaders in mind, with easy to add per-material properties (material color for example) and system-wide constants (ambient light, for example).
  • Launcher functions (a dialog box that pops and asks for resolution, sound volumes, window/full screen, etc, in 3 easy lines of code)
  • Simple navigation mesh generation and path finding (based on Recast). It enables to add objects to a NavMesh object (not all objects work yet), and it will build the navigation mesh, which can be queried… It’s easy to extend, if you know how to use Recast. This component is on a separate library, so you “opt-out” of it easily.

 

On the tools side, I’ll use:

  • Visual Studio 2010
  • Photoshop CS5 (for 2d graphics and textures if I decide to adventure into 3d, and for map creation, etc)
  • 3d Studio Max (for modelling if I go 3d, or for title screens and such otherwise)
  • sfxr (or Bfxr) (for audio effects)
  • Live Writer for blogging
  • Everything I get my hands on…

 

No idea what I’m going to use for music, but probably what I’ll go the same route as last time, asking a friend of mine to use his gear… if he’s available, of course… Smile

My expectations for this compo are fairly high… My last attempt was on the top 10%, so I want to do better this time (although the competition is stiff). The remaining themes are also not very inviting, except for Glitch (that would allow me to make the cyberspace action game I’ve been thinking about!)

Probably going for my usual 48-Hour compo drill… Go to bed at normal hours, wake up at 3am to see the theme and go back to bed… then start working early in the morning!

In, as usual…

Posted by (twitter: @RawBits)
Thursday, December 13th, 2012 11:19 pm

Hi LD25!

This time I don’t have any new hardware to learn and I’m not really interested in HTML5 games – right now – and I don’t want to mess with Angie – it would produce a lot of bugs and code mess. However in the last weeks I used Processing a lot so that will be my tool for sure.

code: Processing
gfx: Gimp2
sound: sfxr, musagi – never done any sound before though…

I’ll reuse code from my previous game GotEL if needed – not likely though. You can find it at StaticVoidGames.com.

I’ll certainly try to use my NES Framework  – for Processing – made during the CharityGameJam. Sadly no game was made based on it then but it developed more since so if you want then feel free to download the latest version here: YouTube video of it. Read the description for updates!

I wish lots of fun and plentygood experiences for the weekend!

p.s: My internet connection having problems in the past weeks and my PC does wierd things so I’ll may not be overly social during this jam. :(

Pythonic Game Design

Posted by (twitter: @90sml)
Friday, July 27th, 2012 2:52 am

Hi,

I am a developper from the 90sml team. We’re going to participate to the next Jam … That’s pretty exciting.

If there are here some Python language Fans. I’m working on an open source game framework. It’s based on pygame & box2d.

Hope you’ll like it : https://github.com/dawicorti/bloodyhell (work in progress)

-> Feel free to use it, fork it, ignore it ^^ …

Petri – the aftermath

Posted by
Monday, April 30th, 2012 11:21 am

Petri

 The Aftermath

Not quite sure if I should call it a ‘post-mortem‘. There are hundreds of these already there. It’s not about what I think went right or wrong. It just … did. Generally I’m glad the way it turned out. However, since I want to keep working on this game I’ve decided to make a list of changes I want to apply to it. That’s why I called the post ‘The Aftermath‘.

The main purpose is to expand it and make the framework more flexible. Then I will extract it and use in future compos.

So, here it goes:


Level entities’ management. Every object in a level is derived from a CEntity class. The examples are mainly … blobs. The pointers to the entities’ instances are stored in a globally-accessible array, which can be accessed at any time. When an entity is no longer needed – it gets deleted and the array is rearranged, getting rid of an unnecessary pointer ( it’s a C++ vector container ).

What if we want to store the reference to the entity and use it on later occasion? For instance, a blob chasing another blob could save a reference to its target and update its position every tick based on that. Storing a raw pointer to the data in memory is risky – we are not able to check whether the entity has been already deleted and the memory’s been freed. Trying to use such a pointer would result in very pesky and hard to track down bugs.

That’s why I came out with the idea of … IDs. An entity’s ID is an index at which it can be accessed in the main entity array ( the STL vector mentioned earlier ). When an entity is about to get deleted, the memory is freed, but the pointer in the array is set to NULL. That way it never gets overwritten and we can check if the object is available, or not. An ID would be an unsigned integer, so it could range from 0 to over 4 000 000 000! The free IDs will never get depleted and the entities themselves will be getting deleted from memory at a constant rate.

The array itself could be though great in size after a while. Every frame each entity needs to receive a tick. Iterating the entire array will be getting more and more time-consuming with the number of the array members growing in size. So … what about a second array? It would contain the IDs of non-deleted entities – that way only the valid members will receive a tick every frame without iterating through the NULL-ed entries.

Although it looks complicated compared to the previous system, it seems that it’s worth a try. Did anybody run into similar, or other worthy conclusions on that matter?


The level editor. Because of a lack of time, I had a really tough time designing the levels. A level editor and an external level file format could really get in handy in this case. Running a game, writing down coordinates and typing them in manually in a source code doesn’t sound appealing, especially when you’ve got dozens of objects which need to be somehow adjusted. I have really no idea how I’ve managed to put all of these blobs in place manually in 48 hours.


The scenes. The hardest thing to think through than the levels themselves. I’m talking here about an intro and ending scenes. Naturally, when you have an idea, you write it down as following: “It fades in within the first 2 seconds. Then it plays the sound X, waits another 2 seconds, shows a few lines of text slowly and gradually fading in …” etc. Not a tough job. It gets complicated, when you only have a level tick method called every frame to put these things in.

Let’s say you want an entity to play an animation after 2 seconds after the beginning of a scene. In the level you’d have to write an if statement which will be called each frame. It’d have to check, whether the time from the beginning of the scene was greater than 2 seconds and if it hadn’t been already greater that 2 seconds the frame before ( starting playing a sound every frame wouldn’t sound pretty – it must be called once and left alone for it to play along ). If there’s many of such ‘timed events’, we need a lot of variables. And now, if not the static variables available in C++, I’d find myself in the dead end. Although the scenes work pretty well, the code itself is a massacre and I was really confused which if statement was responsible for what event.

The threading system could be excellent here. Unfortunately I did attempt this concept few months ago and failed tremendously. Maybe because I used very unfriendly Windows API, who knows? But what other alternatives do I have?

And that’s when I thought of … Lua. I never had the opportunity to work with Lua and so I don’t know its specifications. Hopefully it allows for such maneuvers. I’ll have to dig into it. Is it possible to use threading in Lua?


That’d be it I suppose. There’s a lot of other points in my list but these are regarding either entities’ classes in particular or their implementations. Anyways, after polishing out the game itself, I will add more enemies and more levels, scenes. Hopefully it will come with a great ease. Greater than previously, that’s for sure. Eventually I will publish it.

If you have any suggestions, I’d appreciate if you shared them! I don’t want to implement a total bummer and base the upcoming code on that 😉

Cheers! Thomas

Pixelizer updated and on GitHub!

Posted by (twitter: @johanpeitz)
Saturday, March 31st, 2012 7:23 am

What framework are you going to use for LD23? Why not try Pixelizer?

Pixelizer is an AS3 entity and component based game framework and today I pushed version 0.4.2. This version holds mostly fixes and tweaks to the 0.4.0 version, but a few new things as well, e.g. visualising colliders.

In order to make it easy and fast to use I’ve written a lot of components already so it should be super easy to get started. The whole thing also comes with a lot of examples that show you how to work with components. Read all about Pixelizer here.

I’ll also take the opportunity to say that Pixelizer is now on GitHub. Join the fun!

Pixelizer 0.3 released!

Posted by (twitter: @johanpeitz)
Saturday, February 25th, 2012 12:44 am

First, I want to thank for all the good feedback I got since last release. It’s been really helpful, so keep it coming! :)

Now then, with version 0.3 Pixelizer is really starting to shape up IMHO. Switch scenes, play sounds, add components and entities like there was no tomorrow. Feature list now looks like this:

  • easy extendable component based framework
  • nestable entities for easy manipulation of groups
  • lots of premade components and entities
  • fast 2D rendering
  • automated collision detection and response
  • spritesheets, animations and tilemaps
  • automatic panning and volume of moving sounds
  • exact mouse and keyboard input
  • fancy text rendering
  • handy math routines
  • effective object pools
  • useful logging

Code, docs, examples and all you need available on the project page: http://johanpeitz.com/pixelizer

And if you have any thoughts, feedback, or ideas. Let me know! Thanks!

Pixelizer 0.2 out now!

Posted by (twitter: @johanpeitz)
Sunday, February 12th, 2012 4:38 am

I just released version 0.2 of my framework Pixelizer:

Pixelizer is a component based framework for writing games in AS3. That means that you have base entities and that you write little behaviors for them. Behaviors can be anything from game logic to rendering to whatever you can imagine. As most standard behaviors are already in the package, it is very easy to get started and getting your game on to the screen should be a breeze. I am aiming to make it really flexible, reusable and extendable. The main rendering technique in Pixelizer is currently blitting. Blitting is a fast way of displaying hundreds of objects with virtually no slow down.

I’ve been inspired by Unity3D, Flash Punk, and Flixel and added a my own philosophy into it all.

Code, example, and even a demo on the project page.

I would very much appreciate feedback on the whole thing. Very much! Thanks!

Declaring My Framework (C#, XNA)

Posted by (twitter: @Bloodyaugust)
Thursday, December 15th, 2011 11:37 am

Now ladies and gents, pleeeeeease be nice.

<rant>

This is my baby. My cumulative game developing experience distilled into one sugary goodness. My 1/8 complete Mona Lisa(M?). I’ve developed more than a few finished games, and abandoned WAY more games than I care to think about. This .dll contains solutions to problems that haunted me for literal weeks.

 

And now I share them with you. All I ask is that if you do use it, PLEASE TELL ME WHERE I CAN IMPROVE IT. Like I said, this is nowhere near finished. In fact, it will most likely change by the time Ludum Dare gets here! In fact I can guarantee it will, I still need to add in my flexible animated texture stuff…

</rant>

What it does:

-Circle and Convex Polygon Collision

-Rotations

-Complex transformations

-Pathfinding

-Common texture stuff (animation, atlases, particle engines, etc.)

Have questions? Ask. It is very well commented, and has all the appropriate XML documentation for Visual Studio.

Happy Game Dev! 😀

EDIT: The link was incorrect, but has now been fixed.

LD20 Framework and Tool Declarations

Posted by (twitter: @ExciteMike)
Monday, April 25th, 2011 3:04 pm

Getting ready for Ludum Dare!

I’ll be using AS3, like I’ve done for previous Ludum Dares. Unless somehow I get an idea that would be better in 3d, in which case I will go with Unity.

Music: Coding theme song. Level design theme song. Gaps filled by Pandora.com.

Food: It has become part of my Ludum Dare ritual to go nuts buying snacks before LD weekend.

snax

Framework: Stego, the as3 framework that’s been grown out of the reusable parts of previous compos.

IDE: FlashDevelop.

Graphics: I’ll be doing pixelly sprite stuff in a copy of Photoshop CS 1 which as far as you know was obtained completely legitimately. I’d like to start doing more vector-based stuff, but I figure for LD I’d better stick with what I’m used to.

Music: I will probably mess around with GreaseMonkey’s music generator like I did for LD19. I’ve also used Wario Ware DIY and Wolfram Tones in the past and those kind of worked, so if for some reason I’m not liking what I’m getting out of one tool, I’ll switch to another.

Sound Effects: SFXR and/or BFXR.

Timelapse: Keeyai’s Chronolapse. It’s worked great so far.

Sauce Control: Mercurial, pushed to a repo on Bit Bucket.

Twitter: @ExciteMike

Interweb pagesite: http://excitemike.com/ Has my games and stuff.

Plan: At present, I am leaning toward doing something extremely simple, even for an LD game, but then have lots and lots of levels. I’d also love to make something multiplayer, but I don’t think people tend to have friends nearby when they go to play or rate LD games. Hmm, that sounds kind of sad when I say it that way. Point is, while multiplayer is often super fun, fewer people will be able to enjoy my game if it needs two willing people in the same room.

Precompo declarations, photos.

Posted by (twitter: @ExciteMike)
Friday, April 23rd, 2010 5:03 pm

Framework:  This Stego AS3 framework thing that I’ve accumulated over the last several months:  http://bitbucket.org/excitemike/stego/

IDE: FlashDevelop. compiling with mxmlc.

Music: I’m thinking WarioWare DIY, then recorded and edited in GoldWave.

Graphics: A copy of Photoshop CS 1 which as far as you know was obtained completely legitimately.

Sound Effects: I bet you can guess this one.

Will be listening to: Switching Pandora between a DragonForce station and a station based on music from movie montages (on which the Transformers: The Movie (animated) soundtrack comes up often! :) ).

For timelapse: I will be using Keeyai’s Chronolapse on account of it’s awesomeness.

Desk:

The Brachiosaurus will be relocated before the compo begins.

The Brachiosaurus will be relocated before the compo begins.

Refridgerator:

In case you wondered whether I like bottled water.

In case you wondered whether I like bottled water.

Additional foodstuffs:

crunchy munchies

crunchy munchies

Inspiration:

I should be playing the GameCube version with bongos.

I should be playing the GameCube version with bongos.

Me + Hat + FC Twin + Super Game Boy + Game Boy Donkey Kong + Projector = Heaven

Projector + FC Twin + Super Game Boy + Game Boy Donkey Kong = Heaven!

Sauce Control: Mercurial, which I love.

Twitter: ExciteMike

Favorite Dinosaur: Microraptor gui

And actually I may use Unity, depending on what kind of ideas I get once the theme is announced, but the above is most likely.

I need to get a decent camera.  The webcam built into the cheap laptop is kind of a pain to use.

Framework, sort of.

Posted by
Friday, April 17th, 2009 6:56 pm

Well, it’s a start. :) Uploaded for reference. Less than 5min to go!

Framework “hello world”

Posted by
Friday, April 17th, 2009 5:17 pm

Well, it means that OpenGL is working (2D ortho), along with texturing, mouse interaction, and a bunch of other stuff. Normally I wait until after the theme is announced to get this stuff working, so hopefully it’ll help with my reduced time budget!

But it’s not exactly impressive to look at.

Hopefully this is my Black Triangle, or at least something 80% there. Still need to add rotation support, but that’s not too bad.

MiniLD #6 compilation

Posted by
Friday, January 16th, 2009 9:32 am

This is how it turned out. For anyone who hadn’t played the games from the last miniLD, or if you missed any or just want to play all of them over again, here they are, all bundled together in a neet package. You need python 2.6 and pygame to run on windows, plus wine for running on linux.

link

Enjoy. :)

PS: It’s still buggy.

[cache: storing page]