My first ludum dare, hi everybody

What I use:

• IDE/Language: Visual Studio C# Express 2010 / XNA Game Studio 4.0, Softdrinks
• Framework: XNA and personal code (solution/project file) which I wrote this week to simplify agent modeling, drawing/animation, collision, softdrinks, moving, font-/sound-usage, input- and screen-handling; also a personal intro screen
• Sound: sfxr/bfxr/softdrinks
• Graphic: GIMP, Inkscape, a scanner and a pen
• Additional: Softdrinks

ludum dare starts 03:00 am here… yeah

This entry was posted on Friday, December 16th, 2011 at 1:00 pm and is filed under LD #22. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

I’m in! Second time, using:

•  Language/Framework: C# with XNA and an own library called GB2D presented in this post
•  IDE: Visual Studio 2010 C# Express
•  Graphics: GIMP, Inkscape
•  Sound and music: Sfxr, Autotracker (perlscript to generate random music), perhaps trying Otamata or Aviary (presented here)

Why do I program an own library for 2D games? There are a lot of things I could use, like FlatRedBall. But… programming primitive components makes fun and I learn a lot – that’s all.

Here we go. The framework is downloadable here:
http://www.stevencolling.de/downloads/public/GameBase2D_16_04_12.zip

One of two main parts is the agent modeling. Every entity in the game is modeled as an agent which you can extend by loading the components you need. Available components are:

Audible: Playing sounds.
Bodily: For physical information like position in the game world.
Collisionable: This components allows to use collision detection. Two implementations (CollisionableBoxed and CollisionableLine) of this class exists: box-collision and collision with a set of lines.
Logical: Used for game logic and agent’s state.
Movable: Agent’s moving abilities. An example implementation (MovableSimple) of this class allows to move an agent in 4 directions with a given speed.
Visual: For drawing the agent. An inheritance of this class (VisualAnimated) allows to load an animation and provides animation functionality like starting a specific one etc.

So if you want to add a decorative element like a flying bee, you can initialize an agent with an own implementation of Audible (for humming), a Bodiliy component for positioning on the map, the Logical part to model the bee-specific flying in the game, a Movable part to allow moving in all directions and a VisualAnimated for drawing the bee.
A Collisionable component isn’t needed so it is not initialized. A decorative tree would have no Movable component. An invisible entity like a spawnposition no Visual part.

The second main part is a set of managers. Managers provide common and generic functionality:

DebugManager: provides debug textures and fonts for drawing debug things on the screen.
GameStateManager: handles the current state of game.
GuiManager: holds the GUI elements.
InputManager: manages the input from keyboard and gamepad. Allows to bind multiple keys to actions and set additional properties like a press lock, so an action is just triggered one time after pressing (the user must release the key and press it again to trigger an action again).
IntroManager: Shows a generic intro with name and that the game is used for the Ludum Dare competition.
MapManager: If the game has something like a map, this is used. It has just a MapSize attribute, an empty constructor, empty update and draw methods and a method to check if a given coordinate is within the map’s bounds.
MusicManager: Allows to load music and to play (stop, pause etc.) it.
PlayerManager: Holds the player’s controllable agents and was introduced for my network support (which is not part of the downloadable framework).
ScreenManager: This manager can handle multiple cameras on the map, different screens (split screen) and some methods to translate mapcoordinates to screencoordinates vice versa.

Many of these managers are just „stubs“, e.g. the GameStateManager – every game derives an xxxManagerImpl class to implement and overwrite the needed things, like introducing the game-related game state variables.

Additional there are some basic classes summed up as „common“ like basic math-method-wrappers in Util, a Line class or a Timer.
The obligatory Game-class (Game2D) for XNA-games is also included. It initializes the managers and the framework itself.
A very funny thing is the Textbox functionality which I implemented last days. Now it is possible to show a conversation – multiple textboxes typical in old roleplay games. Even the continuous display of the text is added and available via configuration.

There is also a sample project which sets up generic things like implementing the mentioned ManagerImpls. The IntroManagerImpl is fully implemented, because the Ludum Dare rules allow it. The Game1 class is filled with basic stuff, like setting up the empty and/or generic managers. The correspondent Content project includes a folder-hierarchy. The only content is a little sound used in the intro and some fonts (for intro and debug purposes, the latter used in the DebugManager class).

So if Ludum Dare starts, I will use the sample project, rename it and start implementing the Manager classes and agent components.

Preparation done

If I have the time until weekend, I try to add graphic shader functionality or lightning.

This entry was posted on Monday, April 16th, 2012 at 10:38 am and is filed under LD #23. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Is someone interested in a mailinglist for XNA-users for asking questions and solving problems, especially for the preparation time until Ludum Dare starts?

I know there is a Ludum Dare chat and a lot of forums to ask questions about XNA-coding, but hey, it would be a sort of Ludum Dare community XNA thing and there is not always a XNA-guy in the chatroom. And I’m interested in prototypes written in XNA to see what people do and how they did it.

If you think a mailinglist makes sense (no matter what you think how skilled you are), just write a comment. I can create one.

Edit: Send          subscribe xna-stevencolling-de         to Majordomo@stevencolling.de

This entry was posted on Saturday, August 11th, 2012 at 10:03 am and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

I know, a lot of people propose to start with a playable prototype and set up proper gameplay as fast as possible, but I noticed something during the last jams…

…the longer the time advances, the more tired I am, lacking in concentration (obviously). Additional, starting with gameplay always led to overestimate myself and therefore coding and bugfixing until the end, rushing some graphics here and there. So as the timer expired, I always had a game which was, respective gameplay, not finished, and had not that art I wanted to make.

So this time I made it the other way around – and (I think) it worked in terms of “I am satisfied what I made”. If it plays or looks good, is truly a different kettle of fish (wow, the dictionary spits some funny things out… “this is a different kettle of fish” is in german something like “this is written on another paper”  : D).

At first, I made the background and the different areas where the player can walk on and implemented the generation of the map, the highlighting of areas where the cursor is on as well as other (graphical/interface) stuff, but no resource management or the player’s movement.

Grasslands, forests, mountains, lakes and snowy landscapes.

Afterwards, icons and tooltips were made and implemented, showing some dummy values in the game. The graphics and interface as well as some very basic programming stuff took the first day.

Hunt for food, draw water, chop wood, stay warm and find the resources (fishing grounds, herbage and ores).

The fear of not finishing the game and the case, that I have actually only one day to make the programming of the gameplay, forced me to decrease the graphical amount which therefore limited the complexity and amount of the gameplay. I did not changed graphics or added some during the second day, so I totally could focus on making a game based on the graphics. The result was a lot of time for bugfixing, playtesting, balancing and such stuff.

On the other hand, there are some things in my framework (on top of XNA) which need too much time to program (implementing the interface, the areas for click and hover events etc.). Additional, I really need a particle library…

Okay, this post mortem was somehow short, as I focused only on one aspect. Did you have a jam where you started with the graphics at first? Worked it or was it a fail? Let me know!

You can play my game right here!

Tags: post-mortem

This entry was posted on Monday, May 13th, 2013 at 3:57 am and is filed under LD #26. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.